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 conversationsCodeAtlas導入前: 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 | クラス、インターフェース、トレイト、列挙型、関数、プロパティ |
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 Extension — インタラクティブなコードグラフを備えたVS Code拡張機能
MCP Protocol — Model Context Protocol標準
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.
Search indexed code, trace dependencies, assess change impact, and recall repository memory.
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.
