DeepWiki MCP Server

DeepWiki ingests public GitHub repositories and produces an AI-generated wiki — a hierarchical table of contents, long-form topic pages synthesised from the codebase + README + comments, and an LLM Q&A endpoint grounded in the same index. This bundle exposes that index over MCP. No authentication is required and there is no per-call cost surface to the agent; rate and concurrency limits are set by the upstream service.

Repository scope (read this first)

• All operations take a repoName in owner/repo form, lowercase, exactly as it appears in the GitHub URL (e.g. facebook/react, vercel/next.js).
• Only public GitHub repositories are queryable. Private repos and non-GitHub hosts (GitLab, Bitbucket) are out of scope.
• A repo is queryable only after DeepWiki has indexed it. Popular OSS projects are pre-indexed; smaller or recently-pushed repos may not be. The not-found error tells the user how to trigger indexing — surface that URL verbatim, do not retry blindly.

Workflow

The three capabilities form a deliberate funnel — start broad, narrow only when needed:

1. Structure first. When the user asks anything about a repo you don't already understand, fetch the topic outline. The response is a numbered Markdown table of contents (e.g. 1 Overview, 4.2 Work Loop and Rendering Phases). It tells you what the wiki actually covers and gives you the section vocabulary the contents and Q&A endpoints will recognise.
2. Read contents when the user wants the prose of the wiki (architectural overviews, system descriptions, how subsystems fit together). The response is long-form Markdown — useful for summarisation, citation, or feeding back into another tool. If the question is broad ("explain X"), this is usually the right surface.
3. Ask when the user has a specific question whose answer is not directly a section heading ("why does X use Y?", "where is Z implemented?", "how do I do A?"). The Q&A endpoint runs an LLM grounded in the indexed wiki and returns a synthesised answer with cross-references — strictly better than reading the full contents into context just to find one fact.

Concept-level disambiguation: structure = navigation, contents = read, ask = inference. Pick the highest-leverage one for the question; do not call all three.

Response shape

• Structure: Markdown bullet outline with dotted numbering. Reliable for parsing section titles or building a follow-up ask prompt that names the section.
• Contents: Free-form Markdown wiki body. Can be substantial (thousands of tokens for large repos) — prefer ask if you only need a fact.
• Ask: Markdown answer plus inline citations to wiki sections. Treat citations as DeepWiki section references, not GitHub permalinks.

Operational gotchas

• Unindexed repo error: the response is literally Error fetching wiki for <repo>: Repository not found. Visit https://deepwiki.com/<repo> to index it. Pass that URL through to the user — DeepWiki indexes a repo on first visit, and there is no MCP-side trigger. Do not loop retrying.
• Multi-repo Q&A is fragile. The Q&A schema accepts an array of repos (up to 10) but routinely times out on more than one repo because each repo adds an indexing/grounding pass. Default to one repo per question. If the user genuinely needs cross-repo synthesis, ask each repo separately and merge the answers in your own context — that is faster and more reliable than batching.
• Case sensitivity: GitHub itself is case-insensitive in URLs but DeepWiki canonicalises to lowercase. Normalise owner/repo to lowercase before calling to avoid spurious not-found errors.
• Freshness lag: the index trails the repo's main branch. For questions about brand-new commits or PRs, DeepWiki is not a substitute for reading the source directly.
• No write surface. All three tools are read-only; there is nothing to mutate, no quota counter the agent needs to manage.