让你的 AI 助手深入理解任何代码库
一个独立的 MCP 服务器，可将代码分析数据公开给 Gemini、Claude、Cursor、Windsurf、VS Code Copilot — 并在对话之间提供持久化的 AI 记忆。
Your Code → CodeAtlas Analyze → MCP Server → AI Understands Everything
│
10 powerful tools:
• Search functions & classes
• Trace feature flows
• Generate architecture diagrams
• Persistent memory across conversations使用 CodeAtlas 前： AI 盲目地进行 grep 搜索，在每次对话中都会忘记你的项目。 使用 CodeAtlas 后： AI 可以立即了解你的架构、依赖关系，并记住上下文。
Related MCP server: code-intel MCP Server
安装 CodeAtlas 扩展，然后：
Ctrl+Shift+P → CodeAtlas: Analyze Project{
"mcpServers": {
"codeatlas": {
"command": "npx",
"args": ["-y", "@giauphan/codeatlas-mcp"]
}
}
}{
"mcpServers": {
"codeatlas": {
"command": "npx",
"args": ["-y", "@giauphan/codeatlas-mcp"]
}
}
}{
"mcp": {
"servers": {
"codeatlas": {
"command": "npx",
"args": ["-y", "@giauphan/codeatlas-mcp"]
}
}
}
}{
"mcpServers": {
"codeatlas": {
"command": "npx",
"args": ["-y", "@giauphan/codeatlas-mcp"]
}
}
}claude mcp add codeatlas -- npx -y @giauphan/codeatlas-mcp{
"mcpServers": {
"codeatlas": {
"command": "npx",
"args": ["-y", "@giauphan/codeatlas-mcp"]
}
}
}完成！ 你的 AI 现在可以使用所有 10 个 CodeAtlas 工具了。
工具 | 描述 | 使用示例 |
| 列出所有已分析的项目 | “我有哪些项目？” |
| 获取模块、类、函数 | “向我展示所有类” |
| 导入/调用/包含关系 | “UserService 依赖什么？” |
| 代码质量与安全分析 | “有什么安全问题吗？” |
| 按名称模糊搜索实体 | “查找登录函数” |
| 特定文件中的所有实体 | “auth.ts 里有什么？” |
工具 | 描述 | 使用示例 |
| Mermaid 架构图（模块导入） | “向我展示系统架构” |
| Mermaid 执行流程图（调用链） | “支付功能是如何工作的？” |
工具 | 描述 | 使用示例 |
| 将上下文保存到 | “记住我们修改了什么” |
| 在代码库中追踪功能 | “哪些文件涉及身份验证？” |
AI 助手在对话之间会忘记一切。CodeAtlas 解决了这个问题：
Conversation 1 → AI analyzes code → sync_system_memory
│
.agents/memory/
├── system-map.md ← Architecture diagram
├── modules.json ← All entities
├── conventions.md ← Code patterns
├── business-rules.json ← Domain logic
├── feature-flows.json ← Feature traces
└── change-log.json ← Change history
│
Conversation 2 → AI reads memory → full context restored instantly ✨当你运行 Analyze Project 时，CodeAtlas 会为你的 AI IDE 自动创建规则文件：
生成的文件 | 适用对象 |
| 所有 AI 助手 |
| Cursor |
| Claude Code |
| Windsurf |
这些文件会告诉你的 AI：
在每次对话开始时读取 .agents/memory/
在进行更改前使用 MCP 工具
在完成更改后调用 sync_system_memory
语言 | 特性 |
TypeScript / JavaScript | 完整 AST：导入、类、函数、变量、调用、实现 |
Python | 类、函数、变量、导入、调用 |
PHP | 类、接口、特性 (traits)、枚举、函数、属性 |
Blade Templates |
|
npm install -g @giauphan/codeatlas-mcp然后在你的 MCP 配置中使用 "command": "codeatlas-mcp"（无需 args）。
变量 | 描述 |
| 强制指定项目目录 |
默认情况下，服务器会自动发现
~/下所有带有.codeatlas/analysis.json的项目。
git clone https://github.com/giauphan/codeatlas-mcp.git
cd codeatlas-mcp
npm install
npm run build
npm test # 6 tests
npm start # Start MCP serverCodeAtlas 扩展 — 带有交互式代码图的 VS Code 扩展
MCP 协议 — 模型上下文协议标准
MIT — 个人和商业用途免费。
Generate a Mermaid diagram showing the EXECUTION FLOW of a feature. Unlike generate_system_flow (which shows module imports), this traces the actual call chain: entry point → controller → service → model → database. Given a keyword, it finds all related functions and classes, then builds a flowchart or sequence diagram showing how they call each other at runtime. This is the best tool for understanding HOW a feature works step-by-step.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Project name or path | |
| keyword | Yes | Feature keyword to trace (e.g. 'login', 'payment', 'upload', 'auth') | |
| diagramType | No | Type of Mermaid diagram: 'flowchart' (default) shows call graph, 'sequence' shows step-by-step execution order | |
| depth | No | How many call hops to follow (default: 3) | |
| maxNodes | No | Maximum nodes in diagram (default: 40) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains that the tool traces the actual call chain and builds diagrams, but does not mention any side effects or resource usage. However, it does not contradict annotations and provides sufficient transparency for a generation 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, consisting of three sentences that front-load the main purpose, then differentiate from a sibling, and finally give additional context. 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's complexity (5 parameters, no output schema), the description explains the tool's output type (Mermaid diagram) and key parameters. It lacks details on return format or examples but is sufficient for understanding the tool's role.
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 descriptions for all five parameters. The tool description adds minimal additional meaning beyond the schema (e.g., general flow description but not specific to parameters). Therefore, a 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 clearly states the tool generates a Mermaid diagram of execution flow, distinguishing it from the sibling 'generate_system_flow' which shows module imports. It specifies the call chain tracing and the types of diagrams, leaving no ambiguity about the tool's purpose.
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 contrasts this tool with 'generate_system_flow', indicating when to use this one (for understanding how a feature works step-by-step). It also mentions it is best for this purpose, providing clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Auto-generate a Mermaid flowchart diagram showing how modules, classes, and functions connect in the system. Returns a Mermaid diagram string that AI can read to understand the full system flow without reading every file.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Project name or path | |
| scope | No | Scope of the diagram: 'full' shows all entities, 'modules-only' shows only module relationships (recommended for large projects), 'feature' requires the 'feature' param | |
| feature | No | Feature keyword to focus the diagram on (e.g. 'auth', 'crawl', 'payment'). Only used when scope='feature' | |
| maxNodes | No | Maximum nodes in diagram (default: 60). Reduce for large projects |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the tool is auto-generating and returns a diagram string, but lacks details on whether it is read-only, performance implications, accuracy, or limitations (e.g., dynamic connections). The basic behavior is conveyed, but not comprehensively.
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 that front-load the core purpose and output. It is efficient with no wasted words, though a slightly more structured breakdown of when each scope is appropriate could improve comprehension.
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?
With 4 well-documented parameters and no output schema, the description is adequate for basic usage but lacks critical guidance on sibling tool differentiation and behavioral context (e.g., read-only nature). It is incomplete for nuanced decision-making.
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% description coverage for all 4 parameters, so the schema already explains them adequately. The description adds no additional meaning beyond what the schema provides, meeting the baseline for high 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 the tool auto-generates a Mermaid flowchart showing module/class/function connections, specifying the output type. However, it does not explicitly differentiate from sibling 'generate_feature_flow_diagram', relying on the name and scope inference.
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 use for understanding system flow without reading files, but gives no explicit guidance on when to use this vs. alternatives like 'generate_feature_flow_diagram' or 'get_dependencies'. No exclusion criteria 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.
Get import/call/containment/implements relationships between entities. Shows how modules, classes, and functions are connected.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Project name or path | |
| source | No | Filter by source entity name | |
| target | No | Filter by target entity name | |
| relationship | No | Filter by relationship type | |
| limit | No | Max results (default: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should compensate but does not disclose behavioral traits (e.g., database load, pagination, error handling). It only states the function, missing side effects or performance considerations.
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?
Two sentences with no fluff. First sentence gives the core action, second adds detail. Appropriate length for the tool's complexity.
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 5 parameters, many siblings, no output schema, and no annotations, the description is too minimal. It doesn't explain return format, defaults, or edge cases, leaving an AI agent with insufficient context.
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 parameters are already described. The description adds context about entity types (modules, classes, functions) but does not enhance parameter meaning beyond schema defaults.
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 retrieves specific dependency types (import, call, containment, implements) for entities like modules, classes, and functions. It differentiates from siblings like trace_feature_flow, which focus on user behavior flows.
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 trace_feature_flow or search_entities. The description does not specify context, prerequisites, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all entities (classes, functions, variables) defined in a specific file.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Project name or path | |
| filePath | Yes | File path (partial match, e.g. 'User.php' or 'src/models') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must cover behavior. It only states the purpose without disclosing error handling, performance, or safety aspects. No mention of read-only nature or potential 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?
Single sentence with 12 words, directly conveying the tool's function without redundancy. Every word adds value.
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?
Lacks output schema and does not describe return format or content details. Agent cannot infer whether results include entity types, locations, or other metadata needed for downstream tasks.
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 the schema already documents both parameters. The description adds no additional meaning beyond what the schema provides, meeting the baseline.
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 retrieves entities (classes, functions, variables) from a specific file. It provides a specific verb and resource, but does not differentiate from siblings like get_project_structure or search_entities.
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 get_dependencies or search_entities. Missing context on prerequisites or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get AI-generated code insights including refactoring suggestions, security issues, and maintainability analysis.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only lists output types. It fails to disclose whether it is read-only, requires authentication, or any potential side effects. No behavioral traits are mentioned.
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?
A single sentence that is clear and front-loaded with the main action. 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?
For a simple tool with no params and no output schema, the description covers the core purpose. However, it lacks context about when to invoke it and any constraints, making it adequate but not complete.
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?
Input schema has zero parameters, so schema coverage is 100%. The description adds value by explaining what the tool returns, which is sufficient for a no-parameter tool. Baseline 4 applies.
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: retrieving AI-generated code insights covering refactoring, security, and maintainability. It is specific and differs from sibling tools like get_dependencies or get_file_entities.
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. The description does not indicate prerequisites, limitations, or scenarios where 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.
Get all modules, classes, functions, and variables in the analyzed project. Returns entity type, name, file path, and line number.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Project name or path (auto-detects if omitted) | |
| type | No | Filter by entity type | |
| limit | No | Max results to return (default: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral transparency burden. It only mentions what is returned, omitting behavioral traits such as performance, pagination behavior, or any side effects. This is minimal 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 (18 words) that front-loads the main purpose without any fluff or redundant 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?
For a query tool with 3 optional parameters and no output schema, the description covers the core purpose and returned fields, but omits details like the default behavior of the 'limit' parameter or how auto-detection works for 'project'. Still sufficiently complete.
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 schema already documents all parameters. The description does not add additional meaning beyond the schema, meeting the baseline of 3.
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 verb 'Get' and the resource 'modules, classes, functions, and variables in the analyzed project', specifying the returned fields (entity type, name, file path, line number), making it clear and distinct from sibling tools.
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 does not provide guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. Usage is implied by the description but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all projects that have been analyzed by CodeAtlas. Returns project names, paths, and last analysis time.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly implies a read operation (list) and returns data. No hidden behaviors are suggested, and there is no contradiction with annotations.
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?
A single, front-loaded sentence with no wasted words. Every part is essential and immediately conveys the tool's purpose and output.
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 (no parameters, no output schema), the description fully covers what an agent needs: what it lists and what is returned. No gaps remain.
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 zero parameters, so description doesn't need to explain them. Baseline for 0 parameters is 4, and the description adds no unnecessary parameter info.
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 uses a specific verb ('List') and resource ('projects that have been analyzed by CodeAtlas'), clearly distinguishing it from sibling tools like 'get_project_structure' which targets a single project.
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 clearly states the tool lists all analyzed projects, providing clear context for when to use it. However, it does not explicitly exclude other tools or mention alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for functions, classes, modules, or variables by name. Supports fuzzy matching.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Project name or path | |
| query | Yes | Search query (case-insensitive, partial match) | |
| type | No | Filter by entity type |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It mentions fuzzy matching but does not disclose other traits like whether it is read-only, pagination, or response format.
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?
Two short sentences, no redundant information. Efficiently conveys the core purpose and key feature (fuzzy matching).
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?
Adequate for a search tool with well-described schema, but lacks information about output format, result limits, or interaction with sibling tools. Could be more complete.
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?
All parameters are already described in the input schema (100% coverage). The description adds only 'fuzzy matching' context, which is not parameter-specific. 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 clearly states it searches for entities (functions, classes, modules, variables) by name with fuzzy matching. However, it does not differentiate from sibling tools like get_file_entities, which may also search for entities.
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. Does not mention prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update the .agents/memory/ folder with auto-generated system documentation. This folder serves as AI's 'long-term memory' — it persists between conversations. After calling this, AI in any future conversation can read these files to understand the full system flow without re-analyzing. Call this after completing any code changes.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Project name or path | |
| businessRule | No | Optional: A new business rule to add to the memory (e.g. 'VIP users get free shipping') | |
| changeDescription | No | Optional: Description of what was just changed (for the changelog) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It explains persistence and future readability but does not disclose overwrite behavior, specific files generated, or any side effects. Adequate but not comprehensive.
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?
Two concise sentences front-load the main action and purpose, with no extraneous information. Every sentence adds value.
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 3 optional parameters, no output schema, and no annotations, the description covers the tool's purpose, usage timing, and persistence benefit. Could mention generated file types but overall complete.
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. Description adds no additional parameter meaning beyond the schema's descriptions (project, businessRule, changeDescription).
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?
Clearly states 'Create or update the .agents/memory/ folder with auto-generated system documentation,' specifying verb, resource, and purpose. Distinct from sibling tools like generate_feature_flow_diagram, which focus on diagrams rather than persistent memory.
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 advises 'Call this after completing any code changes' and explains the folder serves as AI long-term memory persisting between conversations. Lacks explicit when-not-to-use or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trace the complete flow of a feature through the codebase. Given a keyword (e.g. 'login', 'payment', 'crawl'), finds all related files, classes, and functions, then orders them by dependency chain to show the execution flow. This helps AI understand which files to read when working on a feature.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Project name or path | |
| keyword | Yes | Feature keyword to trace (e.g. 'auth', 'crawl', 'payment', 'upload') | |
| depth | No | How many hops to follow from matching nodes (default: 2) |
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 finds files, classes, and functions and orders them by dependency chain. However, it does not mention limitations (e.g., project syncing requirements, performance constraints, or edge cases). It is 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?
The description is three sentences, each earning its place: first states purpose, second elaborates on mechanism, third gives usage context. No fluff or repetition.
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 the output format: 'finds all related files, classes, and functions, then orders them by dependency chain.' It also contextualizes the tool's role in understanding features. Missing a bit about return structure, but sufficient for a trace 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 description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema—for example, 'keyword' examples are already in the schema description. No extra semantic value is provided.
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: 'Trace the complete flow of a feature through the codebase.' It specifies the action (trace), resource (feature flow), and scope (complete flow, ordering by dependency chain). This differentiates it from siblings like get_dependencies (just dependencies) or generate_feature_flow_diagram (likely visualization).
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 explicit examples of keywords ('auth', 'crawl', etc.) and states the benefit: 'helps AI understand which files to read when working on a feature.' However, it lacks explicit when-not-to-use guidance or comparisons to sibling tools, making it slightly less comprehensive.
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.
v1.6.0generate_feature_flow_diagramgenerate_system_flowget_dependencies1 field changedInput schema / properties / relationship / enumPrevious value: -[
- "all",
- "import",
- "call",
- "contains"
-]New value: +[
+ "all",
+ "import",
+ "call",
+ "contains",
+ "implements"
+]sync_system_memorytrace_feature_flowv1.2.4get_dependenciesget_file_entitiesget_insightsget_project_structurelist_projectssearch_entitiesScored across 10 tools
Most tools have distinct purposes. However, `generate_feature_flow_diagram` and `trace_feature_flow` both trace feature flow by keyword, differing only in output format (diagram vs. ordered list). Descriptions help differentiate, but an agent might still select the wrong one for a given need.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., `generate_feature_flow_diagram`, `get_dependencies`, `list_projects`). No mixed conventions or vague verbs.
With 10 tools, the set covers the domain of code analysis and documentation well. Each tool serves a distinct, necessary function without redundancy or bloat.
The tool surface covers core CRUD-like operations for projects and entities, plus advanced analysis (flows, insights, memory sync). Minor gaps exist, such as no tool for editing entities or comparing versions, but core workflows are supported.
Codebase graphs, caller impact analysis, and recorded project context for AI coding agents.
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
Project memory, semantic code search, and grounded agent context.
