Which integrations are available for this server?

Allows automatic synchronization of the wiki repository via GitHub webhooks, triggering a fast-forward git pull on push events. Allows automatic synchronization of the wiki repository via GitLab webhooks, triggering a fast-forward git pull on push events.

How do I use wiki-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@wiki-mcp Search the wiki for 'transformer architecture'" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

wiki-mcp

by Paolo-Formici

Overview Schema Source Related Servers Score Discussions Admin

Python

Hybrid

wiki-mcp

A fast, read-only Model Context Protocol (MCP) server for Karpathy-style LLM Markdown wikis.

Supports both Local Mode (stdio) and Remote Mode (Streamable HTTP, MCP 2.x standard) backed by a Git repository with automatic webhook synchronization.

The 3 Read-Only Tools

read_orientation(): Reads SCHEMA.md, index.md, and the last 30 lines of log.md in a single roundtrip.
search_wiki(query, tag=None): Fast full-text and taxonomy-tag search across curated wiki directories (concepts/, entities/, comparisons/, queries/).
get_page(slug_or_path): Safely reads any wiki page, cleanly parsing frontmatter YAML and markdown body.

Zero file mutation or deletion tools are exposed, guaranteeing your wiki's integrity.

Related MCP server: wikicapsule

Running in Local Mode (stdio)

Run directly against your local wiki using uv:

uv run --directory /Users/paolo/Projects/wiki-mcp wiki-mcp --wiki-dir /path/to/wiki

Local Client Config (`mcp_config.json`):

{
  "mcpServers": {
    "dev-wiki": {
      "command": "uv",
      "args": [
        "run",
        "--directory",
        "/Users/paolo/Projects/wiki-mcp",
        "wiki-mcp",
        "--wiki-dir",
        "/path/to/wiki"
      ]
    }
  }
}

Running in Remote Mode (Streamable HTTP)

In Remote Mode, wiki-mcp runs as a centralized daemon on a server or Docker container. It clones/pulls the wiki Git repo on startup and listens for incoming IDE connections and GitHub/GitLab webhooks.

CLI Launch

uv run --directory /Users/paolo/Projects/wiki-mcp wiki-mcp   --remote   --host 0.0.0.0   --port 8000   --wiki-dir /data/wiki   --git-url "https://github.com/your-org/dev-wiki.git"   --auth-token "team-secret-token"   --webhook-secret "webhook-hmac-secret"

Environment Variables

Variable	Description	Default
`REMOTE_MODE`	Set to `true` or `1` for HTTP mode	`false`
`HOST`	Bind address	`0.0.0.0`
`PORT`	HTTP port	`8000`
`WIKI_PATH`	Local filesystem path to cache/clone wiki	Current directory
`WIKI_GIT_URL`	Git remote URL to clone if path is empty	`None`
`AUTH_TOKEN`	Bearer token required for `/mcp` endpoints	`None` (open)
`WIKI_WEBHOOK_SECRET`	Secret for verifying GitHub/GitLab webhooks	`None` (open)
`LOG_LEVEL`	Logging level (`DEBUG`, `INFO`, `WARNING`, `ERROR`)	`INFO`

Remote Endpoints

POST /mcp: The core MCP Streamable HTTP endpoint. If AUTH_TOKEN is configured, requests must supply Authorization: Bearer <AUTH_TOKEN>.
GET /health: Public liveness and readiness probe for load balancers. Returns {"status": "healthy", "commit": "..."}.
POST /webhook: Inbound webhook for GitHub (X-Hub-Signature-256) and GitLab (X-Gitlab-Token). Automatically triggers git pull --ff-only on the local mirror.

Docker Deployment

Docker Compose

docker compose up -d

Docker Run

docker run -d \
  -p 8000:8000 \
  -v wiki-data:/data/wiki \
  -e WIKI_GIT_URL="https://github.com/your-org/dev-wiki.git" \
  -e AUTH_TOKEN="team-secret-token" \
  -e WIKI_WEBHOOK_SECRET="webhook-hmac-secret" \
  wiki-mcp:latest

Developer Client Setup (Remote)

Developers on your team point their IDE (Antigravity IDE, Cursor, Claude Desktop) to your centralized instance:

{
  "mcpServers": {
    "team-wiki": {
      "url": "https://wiki.internal.company.com/mcp",
      "headers": {
        "Authorization": "Bearer team-secret-token"
      }
    }
  }
}

Principles & Architecture

12-Factor XI (Logs): Treats logs as unbuffered structured JSON event streams to stdout.
12-Factor III (Config): Configuration driven strictly by environment variables.
Gall's Law & YAGNI: Starts from a simple, reliable core (shallow Git clone + FastMCP + webhook) without unnecessary database or caching bloat.
Wiki Principles (Ward Cunningham): Convergence over locking, soft security via read-only access, and transparent observability via Git commit history and log.md.

Available Tools

3 tools

get_pageA

Returns the content and parsed YAML frontmatter of any page. Accepts direct paths (e.g. 'concepts/transformer.md') or simple slugs ('transformer').

ParametersJSON Schema

Name	Required	Description	Default
`slug_or_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, and the description does not disclose error handling, potential side effects, or behaviors like unresolved paths. It only states what is returned, omitting any limitations or failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, concise, and structured effectively with examples. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description adequately states the return value (content and frontmatter) and input format. Without an output schema, it could detail the structure of the return, but for a simple read operation it is reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides only a parameter name without description. The description adds meaningful context by explaining that the parameter accepts direct paths or simple slugs, with examples, fully covering the single parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns page content and parsed YAML frontmatter, with explicit examples of accepted inputs. This is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains how to specify pages but does not indicate when to use this tool over the sibling tools (read_orientation, search_wiki). No comparative guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_orientationA

Reads SCHEMA.md, index.md, and the last 30 lines of log.md in a single call for instant agent orientation.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description fully discloses that the tool only reads files, with no side effects or destructive operations. This transparency is sufficient given no annotations are present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, tight sentence that conveys all necessary information without any fluff. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the tool's action and purpose but does not mention the return format or structure. Since it reads specific files, the output is implied, but a brief note about the return could enhance completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so there is nothing to explain. The description correctly omits parameter details, and the schema coverage is vacuously complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (Reads) and the specific resources (SCHEMA.md, index.md, log.md), leaving no ambiguity about the tool's function. It also includes the purpose 'for instant agent orientation', which adds context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it ('for instant agent orientation') but does not explicitly contrast with sibling tools. However, since the siblings (search_wiki, get_page) serve different purposes, the usage context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_wikiB

Searches content and frontmatter across concepts/, entities/, comparisons/, and queries/. Optionally filters results by taxonomy tag.

ParametersJSON Schema

Name	Required	Description	Default
`tag`	No
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of explaining behavior. It discloses that the tool performs a search across content and frontmatter and can filter by tag, which implies a read-only operation, but it does not explicitly mention side effects, error behavior, or whether results are limited or paginated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with no redundant wording. It front-loads the main purpose and appends the optional filter, making it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the basic search behavior and optional tag filter, but it omits details about result ordering, limits, or exact matching. Since an output schema is indicated, return-value details may be available elsewhere, but the description lacks guidance on how this tool relates to the sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning beyond the bare schema by explaining that 'query' searches content/frontmatter and that 'tag' filters results. This clarifies both parameters, though it does not elaborate on expected formats or edge cases.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool searches content and frontmatter across four specific directories and optionally filters by taxonomy tag. It is specific about the resource and action, though it does not explicitly contrast itself with the sibling tools read_orientation and get_page.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is provided about when to use search_wiki instead of the sibling tools. The verb 'searches' implies a different use case from reading a specific page, but the description does not state this or offer any alternative selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesv0.2.0Sep 8, 2026
- First observedget_page
- First observedread_orientation
- First observedsearch_wiki

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Scored 2026-09-08 00:35 across 3 tools

Disambiguation5/5

The three tools have clearly distinct purposes: orientation (read_orientation), discovery (search_wiki), and retrieval (get_page). There is no ambiguity about which tool to call for a given need, even though search_wiki and get_page both return page content, they serve different stages of a workflow.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case: read_orientation, search_wiki, get_page. The naming is predictable and aligns with the action each tool performs.

Tool Count3/5

With only 3 tools, the server is on the thin side but not extreme. It covers basic reading and searching operations, but for a wiki server one might expect additional tools like listing or writing, making the count feel slightly limited for the domain.

Completeness2/5

The tool surface lacks any write operations (create, update, delete) and does not provide a straightforward way to list all pages without parsing the index. This is a significant gap for a wiki, as agents cannot modify or manage content, only read and search.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

EcoCarbonWiki A
dev.carbonitex.ecogame
Read-only MCP for the Eco game wiki: search, Markdown pages, and wiki_* lookups. No keys, no writes.
Documentation Access Search Games & Gamification
101
hiveWikiOAuth
ai.hivewiki
Shared project wiki for AI agents: read and write pages, next actions, and activity logs over MCP.
Knowledge & Memory Note Taking Project Management
2
OrchestKit Docs MCP A
io.github.yonatangross
Read-only MCP server for the OrchestKit docs: full-text search + Markdown fetch. No auth.
Documentation Access Search
23186
saagarpatel.dev Portfolio A
io.github.saagpatel
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Search Documentation Access
82

Related MCP Servers

WikiStrata
Documentation Access Search Knowledge & Memory
kogarashi86
A
license
B
quality
D
maintenance
Enables querying and interacting with a Markdown wiki generated from Confluence pages, with search and MCP server for LLM access.
Updated 5 months ago (2026-04-20 04:05 UTC)
10
4
MIT
wikicapsule
Knowledge & Memory Search RAG Systems
pisigmac
A
license
Not graded
quality
B
maintenance
Turns a git-backed markdown directory into an MCP-compatible knowledge server, enabling any MCP client to read, search, ingest, and maintain a persistent wiki that compounds across sessions.
Updated 2 months ago (2026-06-27 10:42 UTC)
MIT
mcp-server-llm-wiki
Knowledge & Memory Documentation Access Note Taking
itlostandfound
A
license
Not graded
quality
A
maintenance
A generic MCP server that turns a directory of Markdown wiki pages into a network-reachable knowledge base, queryable and updatable by any MCP-compatible client.
Updated 2 months ago (2026-07-19 00:39 UTC)
MIT
ai-wiki-mcp
Note Taking File Systems
jhonnold
F
license
Not graded
quality
B
maintenance
Provides structured search, schema-validated writes, and linting for a markdown knowledge base, enabling agents to operate the wiki over a single streamable-HTTP MCP endpoint.
Updated a month ago (2026-08-07 01:36 UTC)
1
-

wiki-mcp

The 3 Read-Only Tools

Running in Local Mode (stdio)

Local Client Config (mcp_config.json):

Running in Remote Mode (Streamable HTTP)

CLI Launch

Environment Variables

Remote Endpoints

Docker Deployment

Docker Compose

Docker Run

Developer Client Setup (Remote)

Principles & Architecture

Available Tools

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Local Client Config (`mcp_config.json`):