TempoGraph
Server Quality Checklist
Latest release: v0.7.4
- Disambiguation5/5
Each tool has a clearly distinct purpose with detailed descriptions. Even related tools like overview, focus, and prepare_context target different scopes (high-level, task-specific, recommended for coding). Potential overlaps are minimal and well-explained.
Naming Consistency3/5Tool names follow a lowercase_underscore pattern but mix verb_noun (index_repo, watch_repo) with noun phrases (architecture, hotspots, dead_code). Inconsistent but still readable and meaningful.
Tool Count4/524 tools is on the higher end but appropriate given the breadth of analysis features (orientation, risk, dependencies, search, etc.). Each tool addresses a specific need without feeling redundant.
Completeness4/5The tool set covers most aspects of codebase analysis: orientation, search, risk, dependencies, patterns, change impact, and workflow recommendations. Missing only rare edge cases, but core workflows are well-supported.
Average 4.1/5 across 24 of 24 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.0.
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.
This server has been verified by its author.
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
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses the token range (~500-700) and explains merge behavior for exclude_dirs. Missing details on whether indexing is persistent, destructive, or requires permissions. Partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, front-loaded with purpose and quick overview. Parameters are explained in a bullet-style format. No redundant sentences; efficient use of space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers return value and basic behavior but omits idempotency, cost (time/resources), and permission requirements. Given complexity (indexing tool) and lack of annotations, some gaps remain, but the token estimate and output format details help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, requiring description to compensate. Description adds meaning for 'exclude_dirs' (merge with config) and 'output_format' (text vs json response). 'repo_path' is left to schema (default /demo) with no additional context. Incomplete but helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Build the semantic index and return a full orientation.' It specifies what it does and gives a list of outputs (project type, stats, top files, etc.). It distinguishes itself as the initial session setup tool, but does not explicitly compare to siblings like 'embed_repo' or 'file_map'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Run this once at session start,' providing a clear when-to-use instruction. However, it does not mention when not to use it or suggest alternative tools (e.g., 'search_semantic' after indexing), limiting guidance on tool selection.
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?
With no annotations, description only states the action; lacks disclosure of side effects, failure conditions (e.g., if not watched), or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with purpose, efficiently details the single parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple stop action but lacks guidance on return values (output schema exists) and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema by specifying 'absolute path to the repository root' for repo_path, but could offer more detail on format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Stop watching a repository for file changes,' with a specific verb and resource, and distinguishes from sibling tools like watch_repo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage to stop watching but provides no explicit guidance on prerequisites, when not to use, or alternatives (e.g., watch_repo).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of disclosing behavior. It mentions token budgeting and output formats but does not explicitly state that the operation is read-only, or detail authorization needs or side effects. It partially describes output but lacks full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line purpose, followed by a clear list of parameters with brief explanations, and useful examples. Every sentence adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and an existing output schema, the description covers the tool's purpose, parameters, and provides examples. It is nearly complete, though it could mention prerequisites (e.g., if the repo needs to be watched) and clarify the default repo_path.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description provides essential meaning for most parameters: query, max_tokens, exclude_dirs, output_format. The repo_path parameter is not explained, but it has a default. The description adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'get[s] task-scoped context' and lists the types of information returned (symbols, callers/callees, complexity warnings, related files). It distinguishes itself from siblings by its task-focused scope, though it doesn't explicitly differentiate from similar tools like 'diff_context' or 'prepare_context'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples (e.g., 'authentication middleware') and implies it should be used when working on a specific task. However, it does not mention when not to use it or alternatives among the sibling tools, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral aspects. It indicates read-only statistics collection but does not explicitly state non-destructive behavior or any prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, starting with the tool's purpose, followed by a usage hint, then parameter details. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description covers input and purpose well. However, 'each mode' is ambiguous and could be clarified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for two of three parameters (exclude_dirs and output_format) beyond the schema. The repo_path parameter is left implicit but is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides counts (file, symbol, edge, line) and estimated token costs. This distinguishes it from some siblings, but not explicitly from similar tools like 'overview'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use to plan your token budget' implies a usage scenario, but there is no explicit when-not-to-use or comparison to alternative tools.
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?
No annotations provided; description does not state that tool is read-only or safe, nor any potential side effects or requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Short, front-loaded description with three sentences plus parameter explanations; no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main purpose and two parameters; output schema exists but not shown. Missing repo_path explanation and behavioral transparency, but otherwise adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Explains exclude_dirs and output_format in description, but repo_path is left unexplained despite being a key parameter. Schema coverage is 0%, so description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states circular imports and layer structure analysis; distinguishes from siblings like architecture or blast_radius by focusing on dependency graph and refactoring use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use before refactoring to understand the dependency graph', but does not mention when not to use it or compare to alternatives like architecture or blast_radius.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It mentions error conditions (NOT_GIT_REPO) and default values, but does not discuss authorization, rate limits, or whether the operation is read-only. This is adequate but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose first, then parameter explanations. It is front-loaded with the core concept. While slightly lengthy, every sentence adds value. A bit more conciseness could be achieved, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main functionality and key parameters, but leaves out two parameters (repo_path, exclude_dirs). The presence of an output schema partially compensates for return value documentation. Given the tool's complexity (6 parameters, no annotations), the description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains changed_files, scope, max_tokens, and output_format with clear semantics and defaults. However, it omits repo_path and exclude_dirs, two of six parameters. Since schema description coverage is 0%, the description should cover all parameters; the omission is a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Impact analysis for changed files' with two distinct input methods (comma-separated paths or git auto-detection). This differentiates it from sibling tools like dependencies or dead_code that focus on static analysis, making the 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use changed_files vs scope, noting that changed_files overrides scope and scope requires a git repository. It also warns about the NOT_GIT_REPO error. However, it does not explicitly compare with sibling tools, which would elevate the score.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether the tool is read-only, destructive, or any rate limits or permissions needed. It only briefly explains parameters, which is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and usage, followed by parameter explanations. It is relatively concise but has room for tighter integration of the parameter list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple feedback tool, the description adequately covers when and how to call it, and explains parameters. The existence of an output schema means return values are documented elsewhere, so the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description must compensate. It adds meaning by listing and explaining three parameters (mode, helpful, note) with short descriptions. This provides useful semantics that the schema lacks, though it does not cover every detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Report whether tempograph output was helpful for your current task.' The verb 'report' and resource 'tempograph output' are specific. It distinguishes from sibling tools by noting it is called after using any tempograph tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call after using any tempograph tool,' providing clear usage context. However, it does not mention when not to use it or alternative tools, which would elevate the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions Rust-backed performance and incremental DB updates, but lacks details on side effects, permissions, resource usage, long-running nature, or how to stop watching (requires 'unwatch_repo').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences for purpose and two lines for parameters, front-loaded with the main action, concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and parameters, but omits output format, error behavior, and whether the watch runs indefinitely or requires termination. Sibling 'unwatch_repo' suggests start/stop pattern, which is not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description adds value by explaining 'repo_path' and 'exclude_dirs' meanings, compensating for the schema's lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Start watching') and resource ('repository for file changes'), clearly distinguishes from siblings like 'unwatch_repo', and states the effect (incrementally updates graph DB).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for watching a repo for file changes, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it compare with alternatives like 'index_repo' or 'unwatch_repo'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses token-saving behavior for include_low and clarifies parameter effects. However, it does not state that the tool is read-only or describe potential side effects (though likely none). The explanation of low-confidence symbols adds transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear lead sentence and bullet-point parameter explanations. It is concise but includes necessary detail. Minor redundancy in the parameter list could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values need not be documented. The description covers all parameters and provides usage details. It lacks mention of edge cases (e.g., empty repo, no dead code found) but is largely complete for a code analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates by explaining each parameter's purpose, default, format, and effect (e.g., max_tokens for context overflow, exclude_dirs for directory prefixes, output_format choices, include_low token savings). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Find exported symbols never referenced by other files.' It elaborates on cleanup targets (unused exports, orphaned functions, dead interfaces) and mentions Python __all__ support, making the purpose unambiguous and distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like dependencies or blast_radius. The description focuses on parameter usage but does not provide context-specific recommendations or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses local CPU execution, no API keys, incremental updates, and pip requirement. Adds significant behavioral context beyond default read/write assumptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: four short sentences covering purpose, prerequisite, model details, and behavior. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, sequence, and model behavior well, but fails to document two of three parameters (exclude_dirs, output_format). Output schema exists, so return info not required, but parameter gap reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. Only repo_path is mentioned (in a minimal way), while exclude_dirs and output_format are completely undocumented. Insufficient for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it generates embeddings for semantic search across symbols. Explicitly ties to index_repo and hybrid search, distinguishing it from sibling tools like index_repo and search_semantic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Tells user to run after index_repo and mentions idempotent behavior (only missing vectors). Lacks explicit when-not or alternative tools, 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not explicitly state that the tool is read-only or disclose any behavioral traits such as rate limits or side effects. The description focuses on what it finds but not on what it does behaviorally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose first, then usage guidance, then parameter details. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and no annotations, the description covers the main purpose, usage, and most parameters. The output format is mentioned, and the output schema exists so return values need not be detailed. Minor omission is the repo_path parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description explains three of four parameters (top_n, exclude_dirs, output_format) with useful details like defaults and formats. The repo_path parameter is not explained, which is a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's purpose: 'Find the riskiest symbols: highest coupling, complexity, and cross-file callers.' This is a specific verb+resource combination that distinguishes it from siblings like 'dependencies' or 'dead_code'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: 'Use before modifying unfamiliar code to know what to be careful around.' While it doesn't explicitly mention alternatives or when not to use, the guidance is adequate for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full burden. It describes the tool's output (file tree, symbols, sizes) but does not explicitly state it is read-only or safe, nor discuss error handling or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose lead, usage alternative hint, and parameter details. It is mostly concise, though parameter details could arguably be in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers the tool's purpose, usage, and key parameters. It mentions output content and format options, making it sufficient for a file mapping tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains max_symbols_per_file, max_tokens, exclude_dirs, and output_format in plain language, adding meaning beyond schema titles. Repo_path is not described, but is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it produces a file tree with top symbols per file for orientation and understanding project structure. It distinguishes from siblings by advising to use overview for cheaper orientation or focus for task-specific context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use this tool vs alternatives, mentioning overview and focus. However, it does not include restrictions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides adequate behavioral info: pattern matching, fallback, typical token length. However, it does not explicitly state read-only nature or side effects, though lookup is inherently read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with purpose. The list of patterns aids understanding, though it could be more structured (e.g., bullet points). No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (codebase lookup) and presence of an output schema, the description covers key behavior (patterns, fallback, token length). It lacks details on error cases or handling of no matches, but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description carries the burden. It explains 'question' (natural language question) and 'output_format' (text/json), but does not explain 'repo_path' or 'exclude_dirs'. This partial coverage meets baseline but does not fully compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Answer a specific question about the codebase.' It provides concrete examples of understand patterns (e.g., 'where is X defined?', 'what calls X?'), distinguishing it from sibling tools like `search_semantic` or `symbols`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use the tool: for specific questions with known patterns. It mentions fallback to fuzzy symbol search, implying alternatives, but does not explicitly state when not to use it or list sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool combines modes with a token budget and supports output formats. It does not mention side effects, authentication requirements, or read-only nature. The token-budget detail adds value but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear opening sentence, bullet list of built-in kits, and examples. It is slightly verbose but front-loaded effectively. Every sentence adds value, though some redundancy exists in listing examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. It covers parameter usage, built-in kits, and examples. Missing is guidance on error cases (e.g., invalid kit name) and how custom kits are defined, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'kit', 'query', 'max_tokens', 'exclude_dirs', and 'output_format' parameters with context and examples. However, 'repo_path' is only listed in the schema with a default and no explanation, leaving a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run a composable kit — a named multi-mode workflow'. It distinguishes from sibling tools by positioning it as a workflow combiner rather than a single mode. Built-in kits and examples reinforce specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (to run predefined workflows) and includes an option 'list' to discover kits. However, it does not explicitly state when not to use it or suggest alternatives like individual mode tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains the hybrid approach using FTS5, vector similarity, and RRF. It also notes the need for pre-computed embeddings. It does not disclose failure modes or fallback behavior if embeddings are missing, but overall provides good behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with paragraphs, an example, and a prerequisite note. It is efficient but could be slightly tighter. Every sentence adds value, though the two-line example could be integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists (unseen), so return values are covered. The description covers the core use case, method, and prerequisites. However, it lacks guidance on excluded directories and output formatting, and does not address edge cases like missing embeddings. Still, it is generally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It meaningfully describes three of five parameters (repo_path, query, limit) but omits exclude_dirs and output_format. The described parameters add clear semantic value beyond the schema, but the missing ones are a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs hybrid semantic + structural search across all symbols in a codebase. It distinguishes itself from exact name matching with a vivid example, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (to find symbols by meaning) and provides a prerequisite (run `python3 -m tempograph <repo> --embed` first). However, it does not contrast with sibling tools nor specify conditions where this tool is not suitable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations require full burden on description; it reveals parameter priority, required-parameter condition, and output options. However, it lacks details on authorization or rate limits, though these are less critical for a read-only analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses bullet points and parameter lists effectively, is free of fluff, and front-loads the core purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers purpose, usage scenarios, parameter dependencies, and output format. It could mention response size or async behavior, but existing output schema supplements return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description explains file_path and query well, and mentions output_format, but leaves repo_path and exclude_dirs unexplained. This is partial compensation for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'What breaks if you change this file or symbol?' and details specific impact types (importers, external callers, etc.), making the tool's purpose unambiguous and distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use file_path vs query and prefers query for large files, but does not compare with sibling tools like 'dependencies' or 'cochange_context'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 it uses git history, analyzes recent commits controlled by n_commits, and outputs results in text or JSON. It does not mention performance or mutation (it's read-only), but the behavior is adequately described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-line purpose, a brief explanation, and a bullet-like list of parameter details. Every sentence adds value, and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description appropriately avoids explaining return values. It covers the tool's concept and most parameters. It is complete enough for effective use, though the missing repo_path parameter reduces completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains file_path (with example), n_commits (default 200), and output_format (text/json). However, it completely omits the repo_path parameter, leaving that undocumented. This gap reduces the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds files that historically co-change with a given file (logical coupling). It uses a specific verb-resource pair ('co-change' and 'context') and distinguishes itself from siblings like 'dependencies' by focusing on historical co-change patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage advice: 'useful for discovering hidden dependencies' with an example condition. While it doesn't explicitly compare to sibling tools, the context is clear enough for an agent to infer when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses dependency on tempo package and the error if missing, but omits details on permissions, side effects, or read-only nature. With no annotations, the description adds moderate behavioral context but is not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and front-loaded with the core purpose. Every sentence contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the tool's purpose, parameters, usage note, and output options. With an output schema present, it need not detail return values. Minor gaps include not explaining 'best modes' or linking to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description explains task_type (with list and empty case) and output_format (default and options). Repo_path is not explicitly explained but is self-explanatory from its name and default. Overall, it adds meaningful value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a data-driven context strategy recommendation, lists specific outputs (best modes, token cost, success rate), and enumerates known task types, making the purpose distinct and unambiguous 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.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit instructions: leaving task_type empty shows all strategies, requires tempo package, and mentions output_format options. However, it lacks explicit differentiation from alternatives like 'suggest_next' or 'get_patterns'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the analytical process (Markov chains, first-order vs second-order) and example outputs, but since no annotations are provided, it does not disclose whether the tool is read-only or requires specific permissions, though it is implied to be non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear statement, technical details, example, and parameter explanations. It is appropriately sized, though slightly verbose in parts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the algorithm and usage well but lacks explicit description of the output format and prerequisites (e.g., indexed repo). Given the presence of an output schema, the description could still clarify the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for three of four parameters: repo_path as absolute path, current_tool as the tool just called, and prev_tool as optional for second-order prediction. Output_format is not described, but defaults cover it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool suggests the next most useful tool based on learned session patterns and distinguishes it from siblings by explaining second-order Markov accuracy, supported by an example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the prev_tool parameter for better accuracy and gives an example, but does not explicitly state when to avoid this tool or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies a read-only operation (no side effects mentioned), but does not explicitly state non-destructiveness, auth needs, or rate limits. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured with a clear opening, bullet-pointed parameters, and example calls. No redundant sentences; every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations, the description covers purpose, when to use, parameter semantics, and examples. An output schema exists, so return values are handled. Complete for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining each parameter's purpose (query filter, max_tokens cap, exclude_dirs, output_format). Examples illustrate usage, adding value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'coding patterns and conventions' for the codebase, with a specific verb ('Get') and resource. It distinguishes itself from siblings like 'lookup' and 'symbols' by focusing on patterns and conventions rather than code search or symbols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use 'before writing new code to ensure you follow the project's existing conventions.' Examples show typical queries (plugin, render). Lacks explicit 'when not to use' or alternative sibling tool references, 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses that the tool groups files, shows import/call edges, and supports text or JSON output. It implies a read-only analysis, though it doesn't explicitly state non-destructive behavior or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief, well-structured with separate parameter explanations, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity and presence of output schema, the description is sufficient. It covers core functionality and parameters, though it could mention prerequisites or scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning for 'exclude_dirs' (comma-separated prefixes) and 'output_format' (text or JSON). 'repo_path' is not explained beyond default, but overall it compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it produces a high-level architecture view with modules, roles, and inter-module dependencies. It distinguishes from siblings like 'dependencies' and 'file_map' by focusing on macro-level organization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states 'Use for understanding how the codebase is organized at a macro level.' Does not provide when-not-to-use or explicit alternatives, but the use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that output can be very large and that max_tokens caps output to prevent overflow. It clearly states the tool indexes all symbols in the repo. A score of 4 is appropriate; it could explicitly state read-only behavior, but it's implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise paragraphs: purpose first, then usage warning and alternatives, then parameter details. Front-loaded with key info, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (scans entire repo), presence of output schema (no need to explain returns), and sibling tools, the description is complete. It covers warnings, output format options, and parameter details adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains max_tokens ('cap output, default 8000'), exclude_dirs ('comma-separated directory prefixes to skip'), and output_format ('text or json'). repo_path is self-explanatory with default '/demo'. This adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Full symbol index — every function, class, component, hook, type in the repo with signatures, locations, and relationships.' This is a specific verb+resource combination and distinguishes from siblings 'focus' and 'lookup' mentioned as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'For scoped queries, use focus or lookup instead — they're much cheaper.' Also warns about large output and default max_tokens, providing clear when-to-use and when-not-to-use guidance.
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?
No annotations provided, but the description exhaustively covers behavior: token budgeting, mode selection, skip conditions for baseline predictions, precision filter effects, and fallback logic for definition_first.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough but somewhat lengthy, though well-structured with clear sections and bullet points. It front-loads the main purpose, but benchmark details could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 params, no annotations), the description covers all relevant aspects: usage, parameter details, behavioral nuances, and return format (text vs JSON). The output schema exists, so return values are not missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description elaborates on every parameter except repo_path (which has a default). It explains task types, max_tokens, exclude_dirs, baseline_predicted_files with skip logic, precision_filter with benchmark data, definition_first behavior, and output_format options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for coding tasks, specifying it provides token-budgeted context with files, symbols, and hotspots. It distinguishes itself from manually calling multiple tools like index_repo, focus, and blast_radius.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this instead of calling index_repo → focus → blast_radius manually.' It also details two modes for different task types and conditions for baseline_predicted_files, precision_filter, etc.
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?
No annotations provided, but description discloses output content (project type, languages, complex files, dependencies, circular import warnings), token estimate (~500), and format options. It implies read-only behavior without 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences for purpose, then parameter descriptions in a clean bullet-like format. No redundancies, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, output schema exists), the description covers all needed aspects: what it does, parameters, output hints, and next-step guidance. Nothing critical missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have meaningful descriptions: repo_path with example, exclude_dirs with format and example, output_format with default and option. Schema coverage is 0%, so description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool provides repo orientation (project type, languages, files, dependencies, warnings) and distinguishes from siblings like prepare_context by guiding the agent to use it for understanding structure and then call prepare_context for coding tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (understand codebase structure) and when not (for coding tasks, use prepare_context instead) with a clear alternative mentioned.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/Elmoaid/TempoGraph'
If you have feedback or need assistance with the MCP directory API, please join our Discord server