Connect AI agents to your wiki

Wikai exposes your wiki as a remote Model Context Protocol (MCP) server, so the AI agents you already use — Claude Code, Cursor, or agents you build yourself — can search and read your pages as grounded context while they work. Access is read-only by default(write is opt-in per token) and scoped to exactly one workspace, and no LLM runs on our side: your agent's model does the reasoning, Wikai just serves the knowledge.

The server lives at a single endpoint:

https://wikai.wiki/api/mcp

Read access is included on every plan — Free workspaces can mint one active read-only token, so your agents can search and read your wiki from day one. Read + write tokens (agents creating pages) and unlimited tokens are part of the Pro and Ultra plans — see wikai.wiki/upgrade.

Anyone in the workspace can create their own tokens in the app: open the user menu (your avatar, top right), choose API tokens, and click Generate token. Copy the token right away — for security it is shown only once, and we store just a hash of it. Make your own token rather than sharing someone else's: pages your agent creates are attributed to the person who made the token.

Tokens look like wk_... and can be revoked from the same menu at any time. Revocation is immediate: the next request with a revoked token gets a 401. The workspace owner sees every token in the workspace, can revoke any of them, and can turn off token creation for members.

Each token has a scope, chosen when you generate it:

• Read-only (default) — the agent can search and read the wiki, nothing more.
• Read + write — the agent can also create new pages. Grant this only to agents you trust to add to your knowledge base. (Minting write tokens is part of Pro and Ultra.)

Every MCP-capable client works the same way: point it at the endpoint and send your token as a bearer token in the Authorization header. Replace wk_YOUR_TOKEN in the examples below with your real token.

Claude Code

One command in your project or with --scope user for all projects:

claude mcp add --transport http wikai https://wikai.wiki/api/mcp \
  --header "Authorization: Bearer wk_YOUR_TOKEN"

Cursor

Add the server to .cursor/mcp.json in your project (or ~/.cursor/mcp.json globally):

{
  "mcpServers": {
    "wikai": {
      "url": "https://wikai.wiki/api/mcp",
      "headers": {
        "Authorization": "Bearer wk_YOUR_TOKEN"
      }
    }
  }
}

Claude API (agents you build)

The Messages API's MCP connector lets Claude call your wiki directly, without you hosting any MCP plumbing. Declare the server in mcp_servers and reference it from an mcp_toolset entry in tools:

{
  "model": "claude-opus-4-8",
  "max_tokens": 16000,
  "mcp_servers": [
    {
      "type": "url",
      "url": "https://wikai.wiki/api/mcp",
      "name": "wikai",
      "authorization_token": "wk_YOUR_TOKEN"
    }
  ],
  "tools": [
    { "type": "mcp_toolset", "mcp_server_name": "wikai" }
  ],
  "messages": [
    { "role": "user", "content": "What is our incident response process?" }
  ]
}

The MCP connector is in beta and requires the beta header anthropic-beta: mcp-client-2025-11-20 (in the SDKs, pass betas: ["mcp-client-2025-11-20"] on client.beta.messages.create).

Any MCP SDK or client

The server speaks the standard MCP Streamable HTTP transport — connect any MCP SDK to https://wikai.wiki/api/mcp and send the Authorization: Bearer wk_... header on every request. The server is stateless: each JSON-RPC message is a single POST, there is no session to maintain, and there is no SSE notification stream (GET returns 405).

If you're making raw HTTP requests rather than using an SDK, note that the transport spec requires every POST to accept both response types — send Accept: application/json, text/event-stream or the server responds with a 406.

Every token, read-only or write, gets these read tools:

• search_wiki(query)— find pages relevant to a question; returns each match's id, title, space, freshness, and a snippet.
• get_page(id) — read one page in full, as markdown.
• list_pages() — an id/title/space overview of every page in the wiki, useful for orientation.
• list_spaces()— the wiki's spaces and folder paths, so an agent can see how it's organized before placing a page.

The typical read flow is search → read: the agent calls search_wiki to find candidates, then get_page on the ones that matter.

A read + write token additionally gets one write tool — read-only tokens never even see it in tools/list:

• create_page(title, content_markdown, space?, folder_path?) — create a new page from markdown. Optionally place it in a space (by name) and a folder path within it (e.g. "Engineering/Runbooks"); any missing space or folder is created for you. The page is owned by the person who generated the token, and marked as agent-authored so your team can see where it came from.

Writes are create-only in this version — there are no update, move, or delete tools, so an agent can add to the wiki but can't change or remove existing pages.

• A token grants access to its workspace— read, or read + write depending on its scope. Treat it like a password: keep it in a secret manager or your client's config, never in a repository.
• Workspace-scoped. Each token is bound to exactly one workspace and can never read another.
• Hashed at rest, shown once.We store only a hash of your token, so it can't be recovered later — generate a new one if it's lost.
• Immediate revocation. Revoking a token in the API tokens menu cuts off access on the very next request.
• Writes are opt-in and create-only.Only read + write tokens can create pages; there are no edit, move, or delete tools, so existing pages can't be changed or removed through MCP. New pages are attributed to the token's owner.
• Rate limits per token. 60 requests per minute overall, and a tighter 10 page-creations per minute; either limit returns a 429 with a Retry-Afterheader. New pages are capped at ~100 KB of markdown each.
• No server-side LLM.MCP requests never invoke a model on Wikai's side — your agent's model does the reasoning, we only serve retrieval.