Which integrations are available for this server?

Connects to the GitHub Search API for natural-language repository resolution, allowing the server to identify repositories and resolve owners/names from descriptive keywords. Integrates with codewiki.google to search for repositories, fetch AI-generated wiki documentation, and answer questions about open-source projects using the Google RPC API.

codewiki-mcp

by izzzzzi

Overview Schema Related Servers Score Discussions

TypeScript

Remote

📚 codewiki-mcp

MCP server for codewiki.google — search, fetch docs, and ask questions about any open-source repo

Release npm version npm downloads License: MIT TypeScript Node.js

🇷🇺 Русский | 🇬🇧 English

MCP server that connects any AI assistant to codewiki.google — AI-generated wiki documentation for open-source repositories.

📖 Overview

codewiki-mcp is a Model Context Protocol server that gives AI assistants access to codewiki.google — a service that generates comprehensive wiki documentation for any GitHub repository. Search repos, fetch full docs, or ask natural-language questions — all through MCP.

Related MCP server: mediawiki-mcp-server

✨ Features

Feature	Description
🔍 Search Repos	Find repositories indexed by codewiki.google
📄 Fetch Wiki Docs	Get full markdown or structured pages for any repo
💬 Ask Questions	Natural-language Q&A with conversation history
🧠 NLP Repo Resolution	Type naturally — wink-nlp extracts keywords and resolves to `owner/repo`
📡 Multiple Transports	stdio (default), Streamable HTTP, SSE
🔄 Retry with Backoff	Automatic retries with exponential backoff on 5xx errors
🐳 Docker Support	Multi-stage Alpine build
📊 Response Metadata	Byte count and elapsed time on every response

🚀 Quick Start

Using npx (no install)

npx -y codewiki-mcp@latest

From source

git clone https://github.com/izzzzzi/codewiki-mcp.git
cd codewiki-mcp
npm install
npm run build

Transports

# stdio (default)
node dist/cli.js

# Streamable HTTP
node dist/cli.js --http --port 3000

# SSE
node dist/cli.js --sse --port 3001

🐳 Docker

docker build -t codewiki-mcp .

# stdio
docker run -it --rm codewiki-mcp

# HTTP
docker run -p 3000:3000 codewiki-mcp --http

# with environment variables
docker run -p 3000:3000 \
  -e CODEWIKI_REQUEST_TIMEOUT=60000 \
  -e CODEWIKI_MAX_RETRIES=5 \
  -e GITHUB_TOKEN=ghp_your_token \
  codewiki-mcp --http

🔧 MCP Client Configuration

Add to .cursor/mcp.json:

{
  "mcpServers": {
    "codewiki-mcp": {
      "command": "npx",
      "args": ["-y", "codewiki-mcp@latest"]
    }
  }
}

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "codewiki-mcp": {
      "command": "npx",
      "args": ["-y", "codewiki-mcp@latest"]
    }
  }
}

claude mcp add codewiki-mcp -- npx -y codewiki-mcp@latest

Add to your Windsurf MCP config:

{
  "mcpServers": {
    "codewiki-mcp": {
      "command": "npx",
      "args": ["-y", "codewiki-mcp@latest"]
    }
  }
}

Add to .vscode/mcp.json:

{
  "servers": {
    "codewiki-mcp": {
      "command": "npx",
      "args": ["-y", "codewiki-mcp@latest"]
    }
  }
}

{
  "mcpServers": {
    "codewiki-mcp": {
      "command": "node",
      "args": ["/path/to/codewiki-mcp/dist/cli.js"]
    }
  }
}

💡 Usage

Prompts you can use in any MCP-compatible client:

codewiki fetch how routing works in Next.js

codewiki search state management libraries

codewiki ask how does React fiber reconciler work?

Fetch complete documentation:

codewiki fetch vercel/next.js
codewiki fetch https://github.com/fastify/fastify

Get structured pages:

codewiki fetch pages tailwindlabs/tailwindcss

Ask with natural language:

codewiki ask fastify how to add authentication?

🛠️ MCP Tools

🔍 codewiki_search_repos

Search repositories indexed by codewiki.google.

Parameter	Type	Required	Default	Description
`query`	string	✅	—	Search query
`limit`	number	—	10	Max results (1–50)

📄 codewiki_fetch_repo

Fetch generated wiki content for a repository.

Parameter	Type	Required	Default	Description
`repo`	string	✅	—	`owner/repo`, GitHub URL, or natural-language query
`mode`	string	—	`"aggregate"`	`"aggregate"` — full markdown; `"pages"` — structured JSON

💬 codewiki_ask_repo

Ask a natural-language question about a repository.

Parameter	Type	Required	Default	Description
`repo`	string	✅	—	Repository identifier (same formats as fetch)
`question`	string	✅	—	Question about the repo
`history`	array	—	`[]`	Conversation history `[{role, content}]` (max 20)

📊 Response Format

{
  "query": "fastify",
  "count": 1,
  "items": [
    {
      "fullName": "fastify/fastify",
      "url": "https://github.com/fastify/fastify",
      "description": "Fast and low overhead web framework",
      "avatarUrl": "https://avatars.githubusercontent.com/u/24939....",
      "extraScore": 555
    }
  ],
  "meta": {
    "totalBytes": 12500,
    "totalElapsedMs": 450
  }
}

{
  "repo": "fastify/fastify",
  "commit": "abc123",
  "canonicalUrl": "https://github.com/fastify/fastify",
  "pages": [
    {
      "title": "Overview",
      "level": 1,
      "anchor": "#overview",
      "markdown": "# Overview\n\nFastify is a web framework...",
      "diagramCount": 1
    }
  ],
  "meta": {
    "totalBytes": 25000,
    "totalElapsedMs": 1200
  }
}

{
  "answer": "Fastify uses a plugin-based architecture where...",
  "meta": {
    "totalBytes": 8500,
    "totalElapsedMs": 2300
  }
}

{
  "error": {
    "code": "RPC_FAIL",
    "message": "CodeWiki RPC VSX6ub failed with status 404",
    "rpcId": "VSX6ub",
    "statusCode": 404
  }
}

Error codes: VALIDATION, RPC_FAIL, TIMEOUT, NLP_RESOLVE_FAIL

⚙️ How It Works

Data Flow

AI Assistant → MCP protocol → codewiki-mcp → HTTPS → codewiki.google
                                                            ↓
AI Assistant ← MCP protocol ← codewiki-mcp ← JSON  ← Google RPC API

Google Batchexecute RPC

codewiki.google uses Google's internal batchexecute RPC format (not REST, not GraphQL). The client:

Builds a POST request with f.req=... body
Sends it to /_/BoqAngularSdlcAgentsUi/data/batchexecute
Receives a response with XSSI prefix )]}'\n
Parses wrb.fr frames and extracts the typed payload

Each tool maps to an RPC ID:

Tool	RPC ID
🔍 Search	`vyWDAf`
📄 Fetch	`VSX6ub`
💬 Ask	`EgIxfe`

🧠 NLP Repo Resolution

Users can type natural language instead of owner/repo:

"the fastify web framework"
  → wink-nlp extracts keyword "fastify" (POS tag: NOUN/PROPN)
  → GitHub Search API: GET /search/repositories?q=fastify&sort=stars
  → top result: "fastify/fastify"
  → normalizeRepoInput("fastify/fastify") → URL for codewiki

🔄 Retry with Exponential Backoff

Attempt	Delay
0	immediate
1	250ms
2	500ms
3	1000ms

4xx errors (client errors) are never retried.

🖥️ CLI

codewiki-mcp [options]

Options:
  --http           Streamable HTTP transport
  --sse            SSE transport
  --port <number>  Port for HTTP/SSE (default: 3000)
  --endpoint <str> URL endpoint (default: /mcp)
  --help, -h       Show help

⚡ Configuration

Environment variables:

Variable	Default	Description
`CODEWIKI_BASE_URL`	`https://codewiki.google`	Base URL
`CODEWIKI_REQUEST_TIMEOUT`	`30000`	Request timeout (ms)
`CODEWIKI_MAX_RETRIES`	`3`	Max retries
`CODEWIKI_RETRY_DELAY`	`250`	Base retry delay (ms)
`GITHUB_TOKEN`	—	GitHub token for NLP repo resolution

You can also create a .env file in the project root:

CODEWIKI_REQUEST_TIMEOUT=60000
CODEWIKI_MAX_RETRIES=5
GITHUB_TOKEN=ghp_your_token

📁 Project Structure

src/
├── cli.ts                  # CLI entry point
├── server.ts               # Transport setup (stdio/HTTP/SSE)
├── index.ts                # Library re-exports
├── schemas.ts              # Zod input schemas
├── lib/
│   ├── codewikiClient.ts   # API client with retry + metadata
│   ├── batchexecute.ts     # Google RPC response parser
│   ├── repo.ts             # Repo normalization + NLP resolution
│   ├── extractKeyword.ts   # NLP keyword extraction (wink-nlp)
│   ├── resolveRepo.ts      # GitHub Search API resolver
│   ├── errors.ts           # CodeWikiError + formatMcpError
│   └── config.ts           # Env-based configuration
└── tools/
    ├── searchRepos.ts      # codewiki_search_repos
    ├── fetchRepo.ts        # codewiki_fetch_repo
    └── askRepo.ts          # codewiki_ask_repo

❓ Troubleshooting

chmod +x ./node_modules/.bin/codewiki-mcp

# Check if port is in use
lsof -i :3000

For large repositories, increase the timeout:

CODEWIKI_REQUEST_TIMEOUT=60000 node dist/cli.js

If natural-language input doesn't resolve, use explicit format:

# Instead of "the fastify framework"
fastify/fastify
# or
https://github.com/fastify/fastify

Set GITHUB_TOKEN to avoid GitHub API rate limits for unauthenticated requests.

🧑‍💻 Development

npm run dev          # stdio with tsx
npm run dev:http     # HTTP with tsx
npm run dev:sse      # SSE with tsx
npm run typecheck    # type check
npm run test         # run tests
npm run test:watch   # tests in watch mode
npm run build        # compile to dist/

🤝 Contributing

Contributions are welcome! Please:

Fork the repository
Create a feature branch (git checkout -b feat/my-feature)
Use Conventional Commits for commit messages
Run npm run typecheck && npm run test before submitting
Open a Pull Request

📄 License

MIT © codewiki-mcp contributors

Available Tools

3 tools

codewiki_ask_repoC

Ask a natural-language question about a repository indexed in codewiki.google

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`question`	Yes
`history`	No

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It implies a query operation but doesn't describe response format, error handling, rate limits, authentication needs, or whether it's read-only or mutative. For a tool with three parameters and no structured safety hints, this is a significant gap in transparency.

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, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, with every part contributing to understanding the core purpose, making it highly concise and well-structured.

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

Completeness2/5

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

Given the complexity (three parameters, no output schema, no annotations), the description is incomplete. It doesn't cover parameter semantics, behavioral traits, or output expectations, leaving the agent with insufficient context to use the tool effectively beyond a basic understanding of its purpose.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate but fails to do so. It doesn't explain the meaning or usage of 'repo', 'question', or 'history' parameters beyond their names. The description adds no semantic value beyond what's inferable from parameter names, leaving key details like repository format or history structure undocumented.

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 the action ('Ask a natural-language question') and the target resource ('about a repository indexed in codewiki.google'), which distinguishes it from sibling tools like 'codewiki_fetch_repo' and 'codewiki_search_repos' that likely perform different operations. However, it doesn't specify what kind of information can be asked about (e.g., code, documentation, structure), making it slightly less specific than a perfect score.

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 provides no guidance on when to use this tool versus alternatives like 'codewiki_fetch_repo' or 'codewiki_search_repos'. It doesn't mention prerequisites (e.g., the repository must be indexed), exclusions, or contextual cues for selection, leaving the agent to infer usage based on tool names alone.

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

codewiki_fetch_repoC

Fetch generated wiki content for a repository from codewiki.google

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`mode`	No		aggregate

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions fetching content but doesn't cover critical aspects like authentication needs, rate limits, error handling, or the format of returned content. This leaves significant gaps in understanding the tool's behavior.

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, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core action and resource, making it highly concise and well-structured.

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

Completeness2/5

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

Given the complexity (2 parameters, no annotations, no output schema), the description is incomplete. It fails to address key contextual elements like what the output looks like, how errors are handled, or prerequisites for use, making it inadequate for a tool that fetches content without structured support.

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

Parameters3/5

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

The description adds no parameter semantics beyond the input schema, which has 0% description coverage. It doesn't explain what 'repo' represents (e.g., repository name or URL) or the difference between 'aggregate' and 'pages' modes. However, with two parameters and no output schema, the baseline is 3 as the description doesn't compensate for the schema's lack of details.

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 the action ('Fetch') and resource ('generated wiki content for a repository from codewiki.google'), making the purpose evident. However, it doesn't differentiate from sibling tools like codewiki_ask_repo or codewiki_search_repos, which likely have different functions (e.g., querying vs. searching).

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 guidance is provided on when to use this tool versus alternatives. The description lacks context about scenarios where fetching wiki content is appropriate compared to asking questions about the repo or searching for repos, leaving the agent without usage direction.

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

codewiki_search_reposC

Search repositories indexed by codewiki.google

ParametersJSON Schema

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

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action ('Search repositories') without details on permissions, rate limits, response format, or error handling. For a search tool with zero annotation coverage, this is a significant gap in transparency.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.

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

Completeness2/5

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

Given the complexity of a search operation with 2 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, parameter meanings, and expected outputs, making it insufficient for an agent to use the tool effectively without additional context.

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

Parameters2/5

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

Schema description coverage is 0%, meaning parameters 'query' and 'limit' are undocumented in the schema. The description adds no information about what 'query' should contain (e.g., search terms, filters) or how 'limit' affects results, failing to compensate for the coverage gap.

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 the verb ('Search') and resource ('repositories indexed by codewiki.google'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like codewiki_ask_repo or codewiki_fetch_repo, which likely have different purposes (e.g., querying vs. fetching specific repos).

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 guidance is provided on when to use this tool versus alternatives. The description doesn't mention sibling tools or contexts where this search function is preferred over other repository-related operations, leaving the agent without usage direction.

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. Dates show when Glama detected each change.

3 tool updatesv1.1.1Mar 9, 2026
- First observedcodewiki_ask_repo
- First observedcodewiki_fetch_repo
- First observedcodewiki_search_repos

Install Server

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

TDQS

B3.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: 'ask_repo' handles natural-language queries, 'fetch_repo' retrieves wiki content, and 'search_repos' finds indexed repositories. The descriptions make it easy to differentiate between querying, fetching, and searching functions.

Naming Consistency5/5

All tools follow a perfect 'codewiki_verb_noun' pattern with consistent snake_case formatting. The prefix 'codewiki_' is uniformly applied, and verbs ('ask', 'fetch', 'search') are distinct and appropriately paired with nouns ('repo' or 'repos').

Tool Count3/5

With only 3 tools, the set feels thin for a server focused on repository wiki interactions. While the tools cover basic operations, the scope might benefit from additional tools for updates, deletions, or more granular queries to handle common workflows more comprehensively.

Completeness4/5

The tools provide good coverage for core operations: searching repositories, fetching content, and asking questions. However, there are minor gaps such as lacking update or deletion tools for wiki content, which could limit agent capabilities in full lifecycle management scenarios.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

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

docs
dev.continue
An MCP server for docs.continue.dev
Documentation Access Developer Tools Search
2
gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5361
opencode
io.github.doc2mcp
MCP server for opencode documentation, generated by doc2mcp.
Documentation Access Developer Tools
24
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102

Related MCP Servers

mediawiki-mcp-server
Search Documentation Access Open Data
shiquda
F
license
B
quality
C
maintenance
A MCP server that allows you to search and retrieve content on any wiki site using MediaWiki with LLMs 🤖. wikipedia.org, fandom.com, wiki.gg and more sites using Mediawiki are supported!
Updated a year ago (2025-07-13 01:40 UTC)
2
26
-
mediawiki-mcp-server
Content Management Systems Search Developer Tools
olgasafonova
A
license
A
quality
A
maintenance
MCP server for MediaWiki wikis. Search, read, edit, and manage wiki content from AI assistants. Includes formatting, link checking, revision history, and markdown conversion.
Updated 6 days ago (2026-08-31 15:58 UTC)
43
20
MIT
wikijs-mcp-server
Content Management Systems Documentation Access
markus-michalski
A
license
Not graded
quality
C
maintenance
MCP server for Wiki.js integration, enabling AI assistants to create, read, update, delete, search, and move wiki pages via natural language.
Updated 25 days ago (2026-08-12 07:22 UTC)
1
MIT
wiki-loop-mcp
Knowledge & Memory RAG Systems
Prometheus-AGS
A
license
Not graded
quality
B
maintenance
MCP server that provides tools to add to, search, and manage a wiki knowledge base, enabling AI chat tools to contribute and retrieve information from the wiki via natural language prompts.
Updated 2 months ago (2026-06-30 21:58 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/izzzzzi/codewiki-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server