Verleihen Sie Ihrem KI-Assistenten ein tiefes Verständnis jeder Codebasis
Ein eigenständiger MCP-Server, der Code-Analysedaten für Gemini, Claude, Cursor, Windsurf, VS Code Copilot bereitstellt — mit persistentem KI-Gedächtnis zwischen Konversationen.
Your Code → CodeAtlas Analyze → MCP Server → AI Understands Everything
│
10 powerful tools:
• Search functions & classes
• Trace feature flows
• Generate architecture diagrams
• Persistent memory across conversationsVor CodeAtlas: Die KI durchsucht den Code blind und vergisst Ihr Projekt bei jeder neuen Konversation. Nach CodeAtlas: Die KI kennt sofort Ihre Architektur, Abhängigkeiten und behält den Kontext bei.
Related MCP server: code-intel MCP Server
Installieren Sie die CodeAtlas-Erweiterung und führen Sie dann Folgendes aus:
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"]
}
}
}Fertig! Ihre KI kann nun alle 10 CodeAtlas-Tools verwenden.
Tool | Beschreibung | Anwendungsbeispiel |
| Alle analysierten Projekte auflisten | "Welche Projekte habe ich?" |
| Module, Klassen, Funktionen abrufen | "Zeige mir alle Klassen" |
| Import-/Aufruf-/Enthaltungsbeziehungen | "Wovon hängt UserService ab?" |
| Code-Qualitäts- & Sicherheitsanalyse | "Gibt es Sicherheitsprobleme?" |
| Entitäten per Fuzzy-Suche finden | "Finde die Login-Funktion" |
| Alle Entitäten in einer bestimmten Datei | "Was ist in auth.ts enthalten?" |
Tool | Beschreibung | Anwendungsbeispiel |
| Mermaid-Architekturdiagramm (Modulimporte) | "Zeige mir die Systemarchitektur" |
| Mermaid-Ausführungsflussdiagramm (Aufrufketten) | "Wie funktioniert die Zahlungsfunktion?" |
Tool | Beschreibung | Anwendungsbeispiel |
| Kontext in | "Merke dir, was wir geändert haben" |
| Feature durch die Codebasis verfolgen | "Welche Dateien sind an der Authentifizierung beteiligt?" |
KI-Assistenten vergessen alles zwischen Konversationen. CodeAtlas behebt dies:
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 ✨Wenn Sie Analyze Project ausführen, erstellt CodeAtlas automatisch Regeldateien für Ihre KI-IDE:
Generierte Datei | Für |
| Alle KI-Assistenten |
| Cursor |
| Claude Code |
| Windsurf |
Diese weisen Ihre KI an:
Zu Beginn jeder Konversation .agents/memory/ zu lesen
MCP-Tools zu verwenden, bevor Änderungen vorgenommen werden
sync_system_memory nach Abschluss von Änderungen aufzurufen
Sprache | Funktionen |
TypeScript / JavaScript | Vollständiger AST: Importe, Klassen, Funktionen, Variablen, Aufrufe, Implementierungen |
Python | Klassen, Funktionen, Variablen, Importe, Aufrufe |
PHP | Klassen, Interfaces, Traits, Enums, Funktionen, Eigenschaften |
Blade Templates |
|
npm install -g @giauphan/codeatlas-mcpVerwenden Sie dann "command": "codeatlas-mcp" in Ihrer MCP-Konfiguration (keine args erforderlich).
Variable | Beschreibung |
| Erzwingt ein bestimmtes Projektverzeichnis |
Standardmäßig erkennt der Server automatisch alle Projekte mit
.codeatlas/analysis.jsonunter~/.
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-Erweiterung — VS Code-Erweiterung mit interaktivem Code-Graphen
MCP-Protokoll — Standard für das Model Context Protocol
MIT — Kostenlos für den persönlichen und kommerziellen Gebrauch.
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.
