codebase-memory-mcp

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes, but search_graph and search_code both serve code search, and index_status vs check_index_coverage have related coverage-reporting functions. The detailed descriptions help mitigate ambiguity, so only a couple of pairs could potentially be confused.
Naming Consistency4/5
The naming generally follows a verb_noun pattern (e.g., search_graph, query_graph, trace_path, delete_project). However, index_status is a noun phrase rather than verb-first, and manage_adr is somewhat vague, creating minor deviations from the dominant pattern.
Tool Count5/5
With 15 tools, the server is at the upper end of the ideal range but every tool addresses a distinct need for code intelligence: indexing, search, graph querying, tracing, impact analysis, and project management. The count feels well-scoped for the broad domain.
Completeness4/5
The server covers the full lifecycle for code indexing and querying: create (index_repository), read (search_graph, get_code_snippet, query_graph), update (ingest_traces, index_repository re-index), and delete (delete_project). Minor gaps include no dedicated tool for reading ADRs (only create/update) and no explicit fine-grained re-index command, but these are workable via existing tools.
Average 3.6/5 across 15 of 15 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 787 of 885 community issues answered or closed in the last 6 months
- 1251 commits in the last 12 weeks
- Last stable release on August 19, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations provide no positive safety hints (readOnlyHint, idempotentHint, destructiveHint all false). The description tells us the tool modifies the knowledge graph but omits side effects, idempotency, whether existing traces are replaced or merged, or any required prior state. Since the description adds little beyond what the annotations already imply (a write operation), transparency is low.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and not bloated, but it is under-specified. 'Ingest runtime traces to enhance the knowledge graph' is concise yet lacks the contextual substance needed for effective tool selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the two-parameter input with nested objects and no output schema, the description is far from complete. It does not explain trace structure, project identification, expected effects, or how this tool relates to index_repository or trace_path. The absence of return-value details further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention the 'traces' or 'project' parameters at all. It offers no guidance on what format the trace objects should take or how the project parameter is used, leaving the agent to infer meaning solely from parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('ingest'), resource ('runtime traces'), and intended effect ('enhance the knowledge graph'). It distinguishes the tool from pure read/search siblings like search_graph or query_graph, though it does not explicitly differentiate from the closely related index_repository, which also enhances the graph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as index_repository or trace_path. The phrase 'runtime traces' implies a use case, but there are no explicit when/when-not conditions, prerequisites, or links to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations include destructiveHint=true, which directly contradicts the description's 'Get' implying a read-only operation. The description does not disclose any destructive behavior, creating an annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and object, and the parenthetical adds relevant detail without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and, given the contradictory annotations and undocumented parameter, insufficient for correct invocation. It hints at the return content but lacks guidance on the 'project' parameter and does not address the destructive hint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required 'project' parameter with zero description coverage. The tool description does not explain what 'project' refers to or how it affects the schema retrieval, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (get), resource (knowledge graph schema), and scope (node labels, edge types), distinguishing it from sibling tools like search_graph or get_code_snippet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or conditions. The description simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive and idempotent, but the description adds no extra behavioral context—such as whether the deletion is permanent, what exactly gets removed, or side effects. It merely repeats the action without disclosing anything beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief and front-loaded, fitting for a simple tool. It wastes no words, though it could arguably add useful details in the same or slightly more space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a destructive operation with no output schema and a single undocumented parameter, the description is insufficient. It lacks usage guidance, parameter explanation, and behavioral detail, leaving the agent under-informed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'project' parameter with 0% description coverage, and the tool description does not clarify what a valid value looks like (e.g., name, ID, path). The word 'project' is repeated without adding semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (a project from the index). It is specific and distinguishes itself from sibling tools such as list_projects and index_repository by naming the deletion effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, prerequisites, or consequences. The description simply restates the action without context about appropriate scenarios or caveats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, so the agent knows it is a destructive operation. But the description adds little behavioral detail, failing to disclose that 'update' replaces the entire ADR document or that get/sections are read-only modes. This underdiscloses the tool's full behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence with no wasted words. While it is under-specified for the tool's complexity, that is a completeness issue, not a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is insufficient for a tool with three parameters, an enum, no output schema, and destructive behavior. It omits the get/sections modes, the full-replacement semantic of update, and any usage context. The schema provides some help, but the description should give a more complete overview.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 67% of parameters (mode and content), which is decent. The tool description adds no additional parameter semantics, so the baseline of 3 applies; it does not compensate for the undocumented 'project' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as managing Architecture Decision Records with the verbs 'Create or update', which is specific and distinguishes it from sibling tools like get_architecture. However, it omits the 'get' and 'sections' modes present in the schema, making the purpose statement incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of scenarios, prerequisites, or exclusions, leaving the agent to infer usage from the schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description consistently describes a read-only analysis operation ('Map', 'Resolves', 'runs... traversal', 'RESPONSE') with no mention of any side effects. This directly contradicts the annotations readOnlyHint=false and destructiveHint=true, which imply a destructive, non-read-only operation. Since the description gives no clue about what might be destructive, it is a serious annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but entirely purposeful. It starts with a clear purpose statement and then packs essential behavioral details—output shape, exact counts, seed exclusion, and JSON format behavior—without redundant phrasing or filler. Every clause adds value for a tool with this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description thoroughly covers the output model, including base/merge_base SHA, changed_files, impacted tree rows, rollup, exact counts, and seed exclusion. However, it omits any mention of the destructive side effect implied by annotations, and it does not explain the required project parameter or the base_branch semantics. Given the annotation mismatch, the description is not fully complete for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 63%, and most parameters (depth, limit, scope, format, direction) are already documented in the schema. The description adds useful detail about format='json' returning the same model and explains the response structure, but it does not clarify remaining parameters like project, since, or base_branch beyond the schema. Overall, it supplements the schema without fully compensating for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Map a git diff to its BLAST RADIUS', a specific verb-plus-resource statement that clearly identifies the tool's purpose. It further explains the process of resolving changed files to symbols and performing a multi-source graph traversal, distinguishing it from sibling graph/search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on how to use the tool via the scope parameter (files vs impact) and direction parameter (inbound/outbound/both), but it does not explicitly name sibling tools as alternatives or state when not to use this tool. This is clear context without explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the annotations. It presents this as a read-only metadata check ("Check authoritative indexing-coverage metadata", "Returns coverage status") and even notes the signal is best-effort and not a completeness guarantee. However, annotations declare destructiveHint: true and openWorldHint: false. The destructive flag implies side effects, and openWorldHint false contradicts the "not a completeness guarantee" caveat. These are serious inconsistencies that undermine trust.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized into four sentences. It front-loads the core purpose, then provides usage guidance, return-value summary, caveat, and runtime requirement. Every sentence adds unique value without redundant filler, and the length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 params, no output schema), the description covers most operational needs: how to use, when to use, what is returned, and a critical caveat. It even names a specific status value (indexed_no_recorded_gap). However, it omits explanation of pagination (scope_limit/scope_offset) and the meaning of project, and the annotation contradictions weaken overall contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40% (paths and scopes have descriptions, project/scope_limit/scope_offset do not). The description adds important context about paths and scopes, such as requiring at least one and runtime rejection if both omitted. However, it does not explain project, scope_limit, or scope_offset, leaving pagination and required project identification undocumented. It partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: "Check authoritative indexing-coverage metadata for exact repository-relative paths and bounded path scopes." It identifies the specific verb (check), resource (indexing-coverage metadata), and scope (paths/scopes), which distinguishes it from sibling tools like search_graph or index_repository.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong usage guidance: "Use this after graph discovery for every cited or operated-on file" and "use scopes before negative/exhaustive claims because fully skipped files cannot appear in normal graph results." It explains when to use scopes vs paths, but does not explicitly name alternative tools or state when not to use this tool, so it falls just 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, establishing the safety profile. The description adds no additional behavioral context such as output format, pagination, or potential side effects, so it contributes nothing beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the exact function without any extraneous words. It is concise and well-structured for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the presence of thorough annotations, and the self-explanatory name, the description is mostly complete. However, without an output schema, it does not specify the shape or content of the returned list, which leaves a minor gap for an agent expecting detailed output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and zero required fields, so the input schema is empty. According to the rubric, a tool with no parameters receives a baseline of 4. The description appropriately indicates no parameters are needed, and nothing further is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all indexed projects' uses a specific verb and resource, clearly indicating it enumerates projects that have been indexed. It distinguishes itself from sibling tools like index_repository (which creates an index) and search_graph (which queries), leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to choose this tool over alternatives. It does not mention use cases, prerequisites, or exclusions that would help an agent decide between list_projects and other tools such as index_status or check_index_coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description describes a read-only analysis tool, but annotations mark destructiveHint:true and readOnlyHint:false. This is a direct contradiction, as the description never mentions any destructive or mutating behavior. Per the rubric, this scores 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds value: it front-loads the core purpose, then efficiently explains defaults, aspects, clusters, and path scoping. There is no filler; the length is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the most important behaviors: defaults, aspect selection, cluster specifics, path scoping, and cycles. Given the tool's complexity and lack of output schema, it could benefit from describing typical return structure, but it provides enough detail for a high-level overview tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the schema: it explains the default behavior when no aspects are provided, the semantics of each aspect (especially clusters with its algorithm and output fields), optional path scoping, and the opt-in nature of cycles. This far exceeds the brief schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get high-level architecture overview,' a specific verb+resource statement. It clearly explains the tool's purpose and contrasts with siblings by focusing on architecture analysis rather than graph queries or code snippets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an architecture overview is needed and details how to request aspects, but it does not explicitly state when to use this tool over alternatives or provide exclusions. The context is clear but lacks direct alternative differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation contradiction: The description claims 'This is a read tool' (implying safe, non-destructive) while annotations set readOnlyHint=false and destructiveHint=true. This directly contradicts the description's behavioral claim.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet dense, with the purpose front-loaded, followed by a critical workflow instruction and an important caveat. Every sentence earns its place without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main workflow, ambiguous-name handling, and the coverage_note partial-indexing signal. However, it omits details about include_neighbors behavior and return format, and the destructive annotation contradiction undermines completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, but the description adds meaning for qualified_name by explaining it can be a full qualified name or short name and that ambiguity yields suggestions. However, it says nothing about project or include_neighbors, which are undocumented in the schema and require clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Read source code for a function/class/symbol' — a specific verb and resource. It explicitly distinguishes itself from search tools ('This is a read tool, not a search tool') and references the sibling workflow with search_graph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage instructions: 'First call search_graph to find the exact qualified_name, then pass it here.' Also gives when-not-to-use guidance ('not a search tool') and a fallback recommendation to use grep when coverage_note is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a purely read-only search operation with no destructive or mutating effects. However, the annotations set `destructiveHint: true` and `readOnlyHint: false`, directly contradicting the described behavior. This is a serious inconsistency that misleads the agent about potential side effects, warranting a score of 1 per the annotation contradiction rule.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is densely packed with essential information without redundancy. It is logically structured from the core mechanism, to modes, to truncation/pagination, with every sentence contributing predictive value. Despite its length, it remains concise and front-loaded with the most critical traits.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description thoroughly explains return-related details including `total_grep_matches`, `total_results`, and `source_truncated`, along with mode-specific output differences. It also covers edge cases like truncation, the lack of an offset, and the alternative `get_code_snippet` for complete source. For a complex tool, this is remarkably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description significantly enriches schema parameters by explaining mode semantics (compact/full/files and their use cases), limit & truncation behavior, and the `source_truncated` flag. It also clarifies that `context` only applies in compact mode and elaborates on `path_filter` and `file_pattern` beyond their schema descriptions. With 63% schema coverage, the description compensates well for any gaps, though `pattern` and `project` remain minimally described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as 'Graph-augmented code search' with a specific verb+resource combination. It distinguishes itself from siblings by detailing grep-based text pattern matching plus knowledge graph enrichment, and explicitly contrasts with get_code_snippet for retrieving complete source, making its unique purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use each mode (compact for token efficiency, full for source windows, files for just paths) and recommends `get_code_snippet` when complete symbols are needed. It also advises using `path_filter` to scope results and explains how to handle truncation. While it doesn't explicitly contrast with sibling search tools like search_graph, the context and alternatives are well stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation Contradiction. The annotations declare destructiveHint: true and readOnlyHint: false, while the description details a pure query/traversal operation (trace paths, follow edges, return rows) with zero mention of writes, deletions, or side effects. The description contradicts the destructive flag outright, and although it discloses rich response behavior, the metadata mismatch is disqualifying.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense single block but front-loads the core purpose and every sentence contributes (modes, usage, response format, totals, pagination, json parity). It could benefit from line breaks to improve scannability, but there is no filler or redundancy for a tool of this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly bears the burden of explaining return values, and it does thoroughly: prefix grouping, hop format, transitive totals, flat risk/args tables, truncation/next, and JSON equivalence. Gaps remain, such as the behavior of the undocumented edge_types parameter, direction semantics in data_flow mode, and depth bounds, so it is not fully complete for a 13-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 62%, and the description adds meaningful semantics beyond the schema: it explains the prefix-grouped tree model, that callees_total/callers_total are transitive within depth, that test files are excluded unless include_tests, and that cursor must be passed back for pagination. It does not illuminate vague params like edge_types or direction, but it substantially enriches the meaning of mode, depth, limit, cursor, and format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Trace paths through the code graph.' It then enumerates three distinct modes (calls, data_flow, cross_service) with concrete behaviors, and the 'INSTEAD OF grep' note separates it from sibling tools like search_code. This is precise and distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use INSTEAD OF grep for callers, dependencies, impact analysis, or data flow tracing' is explicit when-to-use guidance with a clear exclusion of the grep-like alternative. It gives the agent a decision rule for tool selection without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly explains the behavior of the coverage report and its limitations, but annotations declare destructiveHint: true while the description clearly describes a read-only status operation ('Get the indexing status'). This direct contradiction makes the tool's safety profile ambiguous, earning a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Despite its length, every sentence delivers substantive information about the report's contents, caveats, and usage. The structure is logical and uses clear punctuation to separate concepts like 'parse_partial', 'skipped', and 'not_indexed'. No wasteful repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description provides a comprehensive explanation of the returned status report: counts, paths, git context, and detailed explanations of coverage categories. It also covers edge cases, limitations, and next steps, making it highly complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics for the 'verbose' parameter ('Include the git context block... only needed when debugging where an index lives'), explaining its default omission. The 'project' parameter is self-explanatory from the tool's purpose. With 50% schema coverage, the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the indexing status of a project' and details the exact information returned (node/edge counts, root path, git context, coverage report). It also distinguishes from sibling tools by mentioning query_graph for structural queries over misses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this before trusting graph completeness on a file', instructs to 'ALSO grep it' if a file is listed, and directs structural queries to query_graph with graph='missed'. It also clarifies that 'not_indexed' files are intentional exclusions and how to include them via re-indexing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint: true and readOnlyHint: false, but the description describes a pure search tool with no mention of any destructive side effects or mutation. This is a contradiction between the description's implied read-only nature and the annotation's destructive flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured: it front-loads the core purpose, then details search modes, response format, and pagination. Every sentence carries useful information, and the structure aids comprehension for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 17 parameters and no output schema, the description fully explains the response tree model, column meanings, edge types, and pagination with total/has_more. It also gives practical guidance on narrowing results. This is complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 41%, but the description compensates by explaining query's BM25 ranking and camelCase splitting, name_pattern regex, semantic_query as an array, fields usage, format options, and pagination semantics. This adds substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches the code knowledge graph for functions, classes, routes, and variables. It distinguishes itself from grep/glob and explicitly mentions using trace_path for callers, making the purpose and scope unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use INSTEAD of grep/glob...' and later states 'These are NOT caller/callee counts — use trace_path for callers.' This gives both when-to-use and when-not-to-use guidance, plus advice to narrow via label/file_pattern/min_degree.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond annotations by explaining coverage reporting (skipped, parse_partial, excluded), best-effort nature of flags, where complete lists reside (logfile, index_status, query_graph), and what counts as a failure vs. by-design exclusion. This adds rich behavioral context that annotations (idempotentHint, readOnlyHint) do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence adds value—covering main action, special mode, coverage interpretation, and exclusion semantics. It is organized with clear labels ('COVERAGE:', 'excluded') and front-loads the primary verb. Slightly verbose, but not wasteful given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully compensates by detailing what the response contains (skipped/parse_partial lists, logfile path), how to query missed items, and what constitutes deliberate exclusion. It addresses failure modes, best-effort caveats, and cross-project prerequisites, making it complete for a complex indexing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description enhances parameter meaning: it explains the cross-repo-intelligence prerequisite for target_projects, clarifies mode behavior beyond enum values, and describes persistence artifact usage. It stops short of defining every param's exact syntax but meaningfully supplements the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb+resource: 'Index a repository into the knowledge graph.' It also details a special mode ('cross-repo-intelligence') with its distinct purpose, distinguishing this ingestion tool from query/read siblings like search_graph or index_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the cross-repo-intelligence mode (requires target_projects, needs fresh indexes on target projects). It also implies general indexing workflow by describing mode variants and prerequisites, though it doesn't explicitly contrast with alternatives like detect_changes or check_index_coverage for refresh scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond annotations: the 100k row ceiling, node complexity properties (cyclomatic, cognitive, nested-loop depth, etc.), hot-path signals, and the semantics of the missed graph with its caveat about completeness. This is rich operational detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured and every sentence contributes value: purpose, response shape, row limit, complexity properties, missed graph semantics, and examples. It uses headers and a readable flow, making it dense but not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description is highly complete. It covers usage scenarios, limitations, alternative tools, graph variants, example queries, and the returned 'total' count. There is no output schema, but the description gives enough context with query examples and response details to guide invocation effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, and the description significantly enriches the graph parameter by explaining the missed graph structure and its purpose, and clarifies max_rows behavior (no offset, 100k ceiling). It also provides an example Cypher query demonstrating parameter usage, which adds depth beyond the schema fields, though some parameter-level detail (like query validation) is absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a Cypher query against the knowledge graph for complex multi-hop patterns, aggregations, and cross-service analysis. It distinguishes itself from sibling search_graph by explicitly mentioning pagination alternatives and different use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance: complex patterns, aggregations, cross-service analysis. It also gives clear alternatives: use search_graph for paginated browsing or when row limits are exceeded, and explains when to use the missed graph. The 100k row ceiling is mentioned with mitigation instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![codebase-memory-mcp MCP server](https://glama.ai/mcp/servers/DeusData/codebase-memory-mcp/badges/card.svg)](https://glama.ai/mcp/servers/DeusData/codebase-memory-mcp)

Score Badge

Copy to your README.md:

[![codebase-memory-mcp MCP server](https://glama.ai/mcp/servers/DeusData/codebase-memory-mcp/badges/score.svg)](https://glama.ai/mcp/servers/DeusData/codebase-memory-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/DeusData/codebase-memory-mcp'

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