Wikantik

Platform

MCP for AI agents: your wiki as a tool surface

Wikantik exposes two native Model Context Protocol servers over Streamable HTTP — one for reading and retrieval, one for curation and analytics — so your AI agents can query, cite, and manage your knowledge base without scraping HTML or parsing sitemaps.

What is MCP, and why does it matter for a wiki?

The Model Context Protocol is a standard that lets AI agents call tools on a server and get structured, actionable results — no web scraping, no parsing prose, no guessing at content structure. When your knowledge base exposes an MCP server, an agent can ask "what does this wiki say about hybrid retrieval?" and get a cited answer rather than a wall of search-result URLs to follow.

Most wikis have no agent interface at all. Agents that need to cite knowledge have to scrape the rendered HTML, hope the layout is consistent, and strip the navigation from the content. Wikantik was designed with this problem in mind from the start.

The two servers: read versus curate

Wikantik ships two distinct MCP servers, each with a different trust boundary:

/knowledge-mcp — 18 read-only tools

The /knowledge-mcp endpoint is the safe, read-only interface for retrieval agents, coding assistants, and any other tool that needs to find and cite your content. Its 18 tools cover:

  • Hybrid retrieval (BM25 + dense embeddings + knowledge-graph rerank)
  • Knowledge Graph traversal — follow entity relationships, discover hubs
  • Page Graph navigation — structural spine queries, cluster membership, canonical ID lookup
  • Agent-grade page projection — token-budgeted content with derived agent hints
  • Batched markdown reads via read_pages (up to 20 pages per call) for cluster-spanning research
  • Read-only ontology access — a SPARQL endpoint (sparql_query) and T-Box discovery (get_ontology) over the wikantik: RDF model

Access is controlled by KnowledgeMcpAccessFilter — bearer token or API key required. The same page-level ACLs that protect the web UI apply here.

/wikantik-admin-mcp — 25 write and analytics tools

The /wikantik-admin-mcp endpoint is for curator agents and admin workflows. Its 25 tools add:

  • Page creation, update, and metadata management
  • Knowledge Graph curation (propose nodes, edges, approve or reject extractions)
  • Admin-bypass reads — query_nodes and search_knowledge mirrors that skip the inclusion filter so curators see freshly-created entities before their source page is admitted
  • list_orphaned_kg_nodes — find degree-0 Knowledge Graph entities at scale
  • Verification, audit, and wiki health analytics

The same bearer-token auth scheme applies. You decide which agents get admin access.

These tool counts reflect a fully-configured deployment with the Knowledge Graph enabled (as on the live Wikantik instance): 18 tools on /knowledge-mcp and 25 tools on /wikantik-admin-mcp; minimal installs with the Knowledge Graph disabled register fewer. The design principle is compound operations — fewer, higher-level tool calls rather than chatty per-field round trips. See the Good MCP Design article for the reasoning.

How an agent uses it

In a typical retrieval session, an agent receives a user question, calls the /knowledge-mcp search tool with a natural-language query, gets back a ranked list of pages with content snippets and metadata, selects the most relevant pages, fetches their full content via read_pages if needed, and returns a cited answer. The entire loop completes in a handful of tool calls rather than dozens of HTTP fetches.

For a curator agent publishing a cluster of articles, the flow looks like: draft content, call /wikantik-admin-mcp batch write tools to create multiple pages in one call, verify the cluster with the verify_pages tool, and get a structured per-page report back without further round trips.

Beyond MCP: OpenAPI tools and raw content

Not every client speaks MCP. For OpenWebUI-compatible or other non-MCP clients, Wikantik also exposes an OpenAPI 3.1 tool server at /tools/* with two tools: search_wiki and get_page. These cover the most common retrieval use case for clients that prefer REST-style JSON tool definitions.

For RAG pipelines and crawlers that want raw content, every page is accessible at /wiki/{slug}?format=md (Markdown) or /wiki/{slug}?format=json (structured JSON). The /api/changes?since= endpoint provides an incremental change feed so sync pipelines only fetch pages that have actually changed.

Frequently asked questions

Which MCP clients work with Wikantik?

Any client that speaks the Model Context Protocol over Streamable HTTP will work — Claude Desktop, Claude Code, and compatible agent frameworks. For clients that use OpenAPI rather than MCP, the /tools/* endpoint exposes search_wiki and get_page as standard JSON tools.

Is the MCP server read-only?

The /knowledge-mcp server is strictly read-only — 18 retrieval and navigation tools with no write surface. The /wikantik-admin-mcp server adds 25 write and analytics tools for curators who need to create, update, and audit content. You choose which server to expose to which agent.

How is MCP access controlled?

Both MCP servers sit behind access filters (KnowledgeMcpAccessFilter and McpAccessFilter) that require a bearer token or API key. No token, no tool calls. The same page-level ACLs that protect the web UI are enforced on retrieval results.

Explore the live wiki → Talk to us