Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@codegraph-summary 搜索'交易查询'相关代码"
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.
CodeGraph 中文语义摘要工具 — 为代码符号生成中文业务摘要，支持语义搜索和 PRD 关联分析。
将代码知识图谱与 LLM 结合，让你用中文业务术语搜索代码、理解系统架构、追踪需求覆盖。
一键初始化 — codegraph-summary init 自动构建索引 + 生成摘要
中文语义搜索 — 用 "交易查询"、"清退流程" 等业务术语搜索代码
FTS5 trigram — 高质量中文子串匹配，无需分词器
图谱扩展 — 搜索结果展示调用链（谁调用了它、它调用了谁）
PRD 关联 — 导入需求文档，自动关联到代码实现
多协议 LLM — 支持 Anthropic / OpenAI 兼容 API
启发式降级 — 无 LLM API Key 时仍可生成基础摘要
三种接口 — CLI / HTTP API / MCP Server
Related MCP server: MCP Indexer
npm install -g codegraph-summary需要先安装 CodeGraph：
npm install -g @colbymchenry/codegraphcd your-project
codegraph-summary init这会自动完成：
构建 CodeGraph 代码索引（如果不存在）
用 LLM 为所有导出符号生成中文摘要
在项目根目录创建 .env 文件：
SUMMARY_LLM_API_KEY=your-api-key
SUMMARY_LLM_BASE_URL=https://api.anthropic.com
SUMMARY_LLM_MODEL=claude-sonnet-4-20250514
SUMMARY_LLM_API_TYPE=anthropic不配置 API Key 也能用（启发式模式，用函数签名作为摘要）。
codegraph-summary search "交易查询" -p /path/to/projectcodegraph-summary status -p /path/to/projectcodegraph-summary init -f
codegraph-summary generate -f -p /path/to/project# 导入 PRD 文档（支持 .md / .docx / .pdf / .txt）
codegraph-summary prd-import ./docs/prd.md -p /path/to/project
# 用需求描述搜索代码
codegraph-summary prd-search "用户清退流程" -p /path/to/project
# 查看需求覆盖率
codegraph-summary prd-coverage -p /path/to/projectcodegraph-summary mcp在 Claude Code 的 MCP 配置中添加即可让 AI 助手直接搜索代码摘要。
codegraph-summary serve --port 3000变量 | 说明 | 默认值 |
| LLM API Key | (空，启发式模式) |
| LLM API 地址 | (空) |
| 模型名称 | (空) |
|
|
|
| 每批符号数量 |
|
| 并发请求数 |
|
| 向量服务地址（可选） | (空) |
| 自定义 codegraph 路径 | (自动查找) |
Node.js >= 22.5.0
CodeGraph (用于代码索引)
PDF 支持需要 poppler-utils（macOS: brew install poppler）
DOCX 支持需要 unzip 命令
MIT
分析 PRD 需求的代码覆盖率，找出没有对应实现的需求片段（离散节点）。
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | No | 项目路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only analysis but does not explicitly state whether the tool is safe (non-destructive), what permissions are needed, or any other behavioral traits like rate limits or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key purpose. It is appropriately sized with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description leaves significant gaps: the agent doesn't know what the output looks like, how results are structured, or how to interpret 'discrete nodes'. For a tool analyzing coverage, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter (projectPath), with a schema description ('项目路径'). The tool description does not add extra meaning beyond the schema, meeting the baseline for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it analyzes code coverage of PRD requirements and finds uncovered fragments, using a specific verb ('分析') and resource ('PRD需求的代码覆盖率'). Differentiates from sibling tools like prd_import and prd_search which handle other PRD operations. However, '离散节点' (discrete nodes) may be ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like prd_search or summary_generate. No prerequisites or exclusions mentioned, leaving the agent to infer appropriate usage without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
导入 PRD/需求文档，按章节切分后与代码符号建立关联。支持 markdown 格式。需要向量库配置。
| Name | Required | Description | Default |
|---|---|---|---|
| prdPath | Yes | PRD 文档路径 | |
| minScore | No | 最低关联相似度（默认 0.7） | |
| projectPath | No | 项目路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool splits chapters and associates with code symbols, and requires a vector library. However, it fails to mention whether the operation is destructive, what permissions are needed, rate limits, or side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three short sentences that are front-loaded with the main action. Each sentence adds value: action, format support, prerequisite. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and no output schema, the description should explain return values or error conditions. It does not. The prerequisite (vector library) is mentioned but not what happens if unmet. The description is too brief to be complete for a non-trivial tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already described. The description adds that markdown format is supported and vector library is required, which provides context beyond the schema. However, it does not elaborate on parameter specifics like the meaning of minScore or projectPath beyond what the schema already says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports PRD/requirements documents, splits them by chapters, and associates with code symbols. It also specifies markdown support. However, it does not explicitly differentiate from siblings like prd_search or prd_coverage, which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It only mentions a prerequisite (vector library configuration). There is no discussion of exclusion cases, context, or when other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
【需求定位代码】当问题涉及"需求实现"、"功能在哪"、"这个需求怎么做的"时，必须调用此工具。输入需求描述文字，直接返回实现该需求的函数/组件及文件路径，基于 PRD 文档与代码的预关联索引。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 最大返回数量（默认 10） | |
| query | Yes | 需求描述文字 | |
| projectPath | No | 项目路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses that the tool returns functions/components and file paths based on a pre-associated index, implying a read-only operation. However, it lacks details on side effects, rate limits, or behavior when no results are found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, being a single sentence that front-loads the usage trigger. It is efficient but could be structured into clearer segments (e.g., separating when to use from output description). No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return values (functions/components and file paths) and the underlying mechanism (pre-associated index). It covers the basic usage scenario, but lacks details on pagination, error handling, or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema: it elaborates on 'query' as '需求描述文字' (requirement description text) but does not provide further context for 'limit' or 'projectPath'. No significant added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to search for code implementations (functions/components) and file paths based on a requirement description. It gives specific trigger phrases like '需求实现' (requirement implementation) and distinguishes from sibling tools by explicitly stating it must be used for such queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('当问题涉及...时，必须调用此工具'), providing clear context for invocation. However, it does not mention when not to use it or explicitly compare with alternatives, though sibling names are provided in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
为当前项目的导出符号生成或更新中文摘要。首次运行全量生成，后续运行增量更新。需要 LLM API 配置（SUMMARY_LLM_API_KEY 等环境变量）。
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | 强制全量重新生成 | |
| projectPath | No | 项目路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description supplies behavioral info: full vs incremental updates and environment variable requirements. However, it does not disclose whether updates override existing summaries, auth details, or rate limits, leaving some gaps for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first sentence states the core purpose, and the second adds usage guidance and prerequisites. No superfluous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two optional parameters, no output schema, and no nested objects, the description adequately covers behavior and prerequisites. It could mention integration with sibling tools like summary_search, but the existing detail is sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters described in the schema. The tool description adds minor context (force triggers full regeneration, projectPath optional) but does not significantly extend beyond the schema, meeting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates or updates Chinese summaries for exported symbols, using specific verbs and resource. It distinguishes itself from sibling tools like summary_search and summary_status, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: first run performs full generation, subsequent runs are incremental updates, and it requires LLM API configuration. It does not explicitly state when not to use the tool or list alternatives, but the context is adequate for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
【首选工具】搜索代码时必须首先调用此工具。输入中文业务术语或需求描述（如"清退转正常"、"交易溯源"、"订单状态机"），直接返回对应的函数/组件名称、文件路径和中文功能说明。比 grep 和 codegraph_explore 更快更准，因为它基于预生成的中文语义索引，一次调用即可定位目标代码，无需逐文件搜索。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 最大返回数量（默认 10） | |
| query | Yes | 中文业务术语或描述 | |
| projectPath | No | 项目路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the tool as a search based on a pre-generated index, implying read-only behavior, but does not explicitly state it has no side effects or require permissions. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is somewhat verbose but front-loaded with key information: preferred tool, use case, input format, output, and comparison. No superfluous sentences, though could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description explains input, output, and why it's preferred. It lacks error handling or restrictions, but for a search tool this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by clarifying the query parameter (Chinese business terms) and explaining the tool's behavior relative to the input, which goes beyond the schema's brief descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches code using Chinese business terms, returning function/component names, file paths, and descriptions. It distinguishes itself from general grep and codegraph_explore, and implicitly from siblings by being the primary search tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends calling this tool first for code search with Chinese terms. Compares favorably to grep and codegraph_explore but does not mention when to use siblings like prd_search or summary_generate. Still provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查看当前项目的摘要生成状态：覆盖率、PRD 关联情况。
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | No | 项目路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It indicates a read operation (viewing status) but does not disclose potential side effects, authentication requirements, or error handling (e.g., what happens if the project path is invalid). The description is minimal in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary purpose. Every word contributes to understanding the tool's function without extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description covers the main output (coverage and PRD association). However, it lacks details on the return format or any additional behavioral context, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a single parameter described as '项目路径' (project path). The description adds no additional semantic value beyond the schema. Since schema coverage is high, baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: viewing summary generation status including coverage and PRD association. It distinguishes itself from sibling tools like summary_generate and prd_import by focusing on status retrieval rather than generation or import.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking status but does not provide direct guidance on when to use this tool versus alternatives such as summary_generate or prd_search. No explicit exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0prd_coverageprd_importprd_searchsummary_generatesummary_searchsummary_statusEach tool has a distinct purpose: generating summaries, importing PRDs, searching via PRD or summaries, analyzing coverage, and checking status. No overlap.
Tool names follow a clear domain_action pattern: 'summary_generate', 'prd_import', 'prd_search', etc. Consistent prefixing and verb usage.
6 tools is well-scoped for the server's purpose of code summary and PRD management. Not excessive or insufficient.
Covers core workflows: generation, import, search, coverage, status. Minor gap: no explicit tool for deleting or updating individual summaries, but incremental generation works around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Versioned documentation registry and semantic search for AI tools and coding assistants.
Project memory, semantic code search, and grounded agent context.
Codebase intelligence for agents: 152 structured artifacts across 21 programs, one call.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lix30684-stack/codegraph-summary'
If you have feedback or need assistance with the MCP directory API, please join our Discord server