What is an MCP wiki server?

If your wiki is an MCP server, an AI agent can search it, read pages, and write back to it the same way it calls any other tool — over a typed protocol, with scoped permissions, no screen-scraping and no brittle browser automation. That's the whole idea. This post explains the Model Context Protocol briefly, why a wiki exposing one matters, and how tela does it.

MCP in one paragraph

The Model Context Protocol (MCP) is an open standard for connecting AI assistants to external systems. A server exposes tools (callable functions with typed inputs/outputs), resources (readable documents), and prompts; a host (Claude, an IDE agent, your own orchestrator) discovers those tools at runtime and calls them. It's the "USB-C port" framing people use: one protocol, many integrations, instead of a bespoke adapter per app. The transport is JSON-RPC, usually over stdio or streamable HTTP.

Why a wiki being an MCP server matters

Most teams' knowledge lives in a wiki, and most AI workflows need that knowledge. Without MCP, you bridge the two badly:

• Copy-paste. A human pastes a page into a chat. Stale the moment it's pasted, and the agent can't write anything back.
• Scraping / RAG-over-HTML. You crawl the rendered site, embed it, and hope the chunks are clean. You inherit navigation chrome, lose structure, and there's still no write path.
• A separate integration per agent. Every tool grows its own connector.

An MCP wiki server collapses all of that into one surface. The agent gets:

1. Read as a first-class client — search and fetch canonical content (markdown, not scraped HTML), with the page's real structure intact.
2. Write as a first-class client — create and update pages, leave comments, move things. The agent contributes to the knowledge base instead of only consuming it.
3. Permissions that are actually enforced — scopes are checked server-side per tool, not assumed because "the agent has a login."

The shift is from docs as a place humans read to docs as a system agents participate in. Plenty of doc and wiki tools are adding MCP — this isn't unique to tela. What follows is how tela specifically wired it.

How tela implements it

tela is a markdown-native team wiki (Go + Postgres backend, React/Milkdown frontend) with the MCP server built into the backend — not a side process that remodels your data. pages.body is canonical markdown forever, so the bytes an agent reads over MCP are the same bytes the editor renders and the same bytes you'd sync to disk. There's no separate "AI copy" to drift.

Concretely:

• One HTTP endpoint: https://telawiki.com/api/mcp. Modern hosts speak to it directly over HTTP. For stdio-only hosts there's a thin proxy, tela-mcp on npm, that forwards the same protocol with your access token as a bearer header — a dumb pipe, not a second implementation, so the tool surface can't drift between the two paths.
• The MCP tools call the same core functions the REST API does. A create_page over MCP runs the identical code path as creating a page in the UI. Same validation, same search indexing, same audit.
• Scoped writes. Read tools and write tools are gated separately; a read-only token can search and fetch but not mutate.
• Search is real search. Agents get the same ranked Postgres full-text search and semantic (vector) search the app uses — not a naive substring match.
• Self-hostable, and the MCP access is unmetered. Self-host the open-source build, or use the free cloud tier — agent calls aren't billed per-token by tela.

A concrete workflow

Say an agent is asked to "document the new webhook retry behavior and link it from the integrations overview." Over tela's MCP it would:

search("webhook retry")
  → finds the Integrations Overview page + a stale "Webhooks" page

get_page(id)        # read the current canonical markdown
update_page(id, …)  # rewrite the Webhooks page with the new behavior
create_page(…)      # or add a focused "Webhook retries" page
add_comment(id, …)  # flag the overview page for a human to review the link

Every one of those is a typed tool call returning structured output — tela wraps row-returning results in a named envelope like { "page": … } — so the agent isn't parsing prose to figure out whether the write succeeded.

When you'd want this

• You run agents that should answer from your real docs, not a frozen snapshot.
• You want agents to keep docs current — fixing drift, filling gaps — under enforced permissions.
• You care about owning the data: self-hosted, canonical markdown, exportable, no lock-in to a proprietary block format.

An MCP wiki server isn't a chatbot bolted onto a wiki. It's the wiki itself becoming something agents can read from and write to natively. If you want to try it, point an MCP-capable host at https://telawiki.com/api/mcp (or install tela-mcp) and give it a read-only token to start.