trace-mcp

Server Quality Checklist

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

Latest release: v1.47.1
Disambiguation3/5
Many tools have overlapping purposes (e.g., get_dead_code vs get_dead_exports vs self_audit; get_complexity_report vs get_complexity_trend vs get_symbol_complexity_trend; multiple session analytics tools). Detailed descriptions help distinguish them, but the sheer number of similar variants increases the chance of misselection.
Naming Consistency4/5
Tool names follow a mostly consistent lowercase snake_case verb_noun pattern (get_*, check_*, scan_*, detect_*). Minor deviations like 'search', 'batch', 'reindex', and 'plan_turn' break the pattern slightly, but overall it is predictable and readable.
Tool Count1/5
With 55 tools, this is far beyond the typical well-scoped range of 3-15. Many tools are highly specialized variants (e.g., get_complexity_report vs get_complexity_trend vs get_symbol_complexity_trend; get_session_analytics vs get_usage_trends vs get_session_stats). This is an extreme number that will overwhelm agents.
Completeness4/5
The domain (code intelligence and analysis) is extensively covered: indexing, search, symbol retrieval, dead code, complexity, coupling, security, tech debt, decision graph, and session analytics. Minor gaps exist—such as the mentioned but missing 'add_decision' and 'get_wake_up' tools—but most workflows are fully supported.
Average 4.6/5 across 55 of 55 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 38 of 42 community issues answered or closed in the last 6 months
- 316 commits in the last 12 weeks
- Last stable release on August 17, 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Contradicts annotations: description says 'Live agent write' but annotations have readOnlyHint=true. Also mentions confidence routing, dedup, and rate-limit, but contradiction overrides.
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?
Concise, front-loaded with key purpose, then behavioral details and return format. No wasted words.
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?
Covers routing, dedup, rate-limit, and return format. Lacks specifics on rate limit but sufficient for an agent to use.
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 100%, so baseline 3. Description adds minimal parameter-specific value beyond what's in 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?
Clearly states it writes decisions into the knowledge graph in real time, and distinguishes from add_decision and mine_sessions with specific 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?
Explicitly says when to use (during session for real-time capture) and provides alternatives for manual high-confidence writes (add_decision) and post-hoc extraction (mine_sessions).
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?
Annotations already indicate read-only, idempotent, non-destructive. Description adds that it returns only the symbol (not whole file), but does not elaborate on edge cases like git verification or parameter conflicts.
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?
Two short sentences plus return format. No fluff, every sentence serves a purpose.
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?
Covers main purpose and return structure but omits details about parameter interaction (both symbol_id and fqn are required in schema contrary to 'or' in description). Could better explain how tool resolves conflicts.
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 100% with parameter descriptions. The description only reiterates that lookup is by symbol_id or FQN, adding no new 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 looks up a symbol by symbol_id or FQN and returns source code. It distinguishes from alternative tools like 'Read' and 'get_context_bundle' by specifying scope and 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use instead of 'Read' for specific symbols, and prefer 'get_context_bundle' for multiple symbols. Does not include explicit 'when not to use' but covers key alternatives.
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?
Annotations already provide readOnlyHint and idempotentHint. The description adds behavioral context: data sources (manifests), what is detected, and the output structure. It does not contradict 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 sentence with a bullet list, extremely concise and front-loaded. Every word is necessary, no redundancy beyond the redundant 'Read-only' which is acceptable.
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 no parameters and no output schema, the description provides a complete picture: what the tool does, how it works, and what it returns. Combined with annotations, an AI agent can fully understand and invoke the 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?
The input schema has zero parameters, so schema description coverage is 100%. The description does not need to add parameter semantics, but it clarifies the output shape, which is valuable.
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 produces a 'technology profile' by detecting frameworks from manifests, showing which are covered by trace-mcp plugins, and highlighting coverage gaps. It specifies the return structure as JSON with 'detected, covered, gaps', making the purpose distinct from sibling report tools.
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 explicit guidance on when to use this tool versus alternatives like get_complexity_report or get_optimization_report. The description implies usage for checking plugin coverage, but does not differentiate conditions or provide exclusion criteria.
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 discloses that the tool mutates the decision store and is idempotent, aligning with annotations (idempotentHint=true, destructiveHint=false). It details force, incremental cursor, and threshold behavior. However, it omits edge cases like invalid project_root or error states.
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 dense and informative, front-loaded with the main purpose. At ~150 words, it covers key aspects efficiently, though it could be slightly more streamlined by grouping related details.
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 7 parameters and no output schema, the description covers purpose, strategies, skipping, cursor, mutation, idempotency, and return format. It lacks error handling or performance details but is largely complete for an experienced user.
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?
All 7 parameters have schema descriptions (100% coverage). The description adds value by explaining strategy enum details, incremental_cursor semantics, and threshold interactions, but these are supplementary to 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 the verb 'Mine' and the resource 'session logs', specifying the types of information extracted (architectural decisions, tech choices, etc.). It distinguishes this tool from siblings like search_sessions by focusing on mining for decisions and preferences.
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 explains when to use each strategy (regex, llm, hybrid) with trade-offs (cost, recall), and notes fallback behavior. It also mentions skipping already-mined sessions unless force=true. However, it lacks explicit when-not-to-use guidance or alternatives beyond the three strategies.
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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that it delegates to other tools, returns results for all calls, and specifies the return JSON format. No contradictions; adds useful behavioral context beyond 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?
Three clear sentences, each adding value: purpose, usage guidance, and return format. Front-loaded with the core action. No fluff; every sentence earns its place.
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 no output schema, description specifies return format (JSON with batch_results and total). Covers purpose, usage, safety (read-only), and output structure. Could mention result-order preservation or error handling, but adequate for a batching tool with good annotations.
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 100% with descriptions for 'calls', 'tool', and 'args'. Description adds usage context and return format but doesn't elaborate on parameter details beyond schema. Baseline 3 is appropriate as description adds marginal value.
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?
Clearly states 'Execute multiple trace-mcp tools in a single MCP request' (verb+resource) and distinguishes from individual get_* or search tools. The benefit (reducing round-trips) is explicitly mentioned, making it specific and differentiated 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: 'Use to reduce round-trips when you need several independent queries' with examples (e.g., get_outline for 3 files, or search + get_symbol together). It implies when to use (multiple independent queries) but could explicitly exclude dependent queries; still clear overall.
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?
Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds value by detailing the return structure (JSON with modules, grade, score, factors, recommendations) and explicitly stating 'Read-only', reinforcing safety. Lacks details on caching or refresh impact beyond schema.
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?
Description is very concise, using 4-5 short sentences that front-load the core purpose, include the output format, and provide usage guidance without redundancy or waste.
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 no output schema, description provides the return format and lists constituent factors. It omits details about score scaling, recommendation derivation, or prerequisites (e.g., index state), but these are not critical for an AI agent to use the tool correctly.
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?
Input schema already describes both parameters (module, refresh) with clear descriptions. The tool description does not add new meaning beyond what the schema provides, so it meets baseline but adds no extra value for parameter understanding.
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?
Description clearly states it provides a per-module tech debt score combining multiple factors (complexity, coupling, test coverage, git churn) and includes actionable recommendations. This distinguishes it from sibling tools that focus on individual metrics.
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?
Explicitly recommends use for architecture review and prioritizing cleanup, providing clear context. However, it does not specify when not to use it or directly name alternatives, though the sibling list implies single-factor tools for different needs.
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?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint. The description reinforces 'Read-only, no side effects' and adds the use case and return format details, adding value beyond 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?
Three sentences front-loading purpose and safety. The first sentence is strong. The read-only statement is redundant with annotations but still acceptable. Efficient overall.
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 no parameters and no output schema, the description covers essential information: what the tool does, its safety profile, when to use it, and what it returns. Sufficient for a simple health check 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?
No parameters exist, so schema coverage is 100%. The description correctly mentions no parameters, meeting the baseline. No additional parameter semantics needed.
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 verb 'Get' and resource 'index health', and specifies sub-aspects (status, statistics, health, pipeline progress). It distinguishes from sibling tools like get_project_health by focusing on the index.
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?
Explicitly says 'Use to verify the index is ready before running queries,' providing clear context for when to use. Lacks explicit when-not-to-use or alternatives, but the statement is sufficient for typical scenarios.
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?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds that it returns JSON with specific fields, which is useful behavioral context beyond annotations. No contradictions.
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 two short sentences, front-loaded with purpose, and every word adds value. No wasted text. Perfectly concise.
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 no parameters and clear annotations, the description fully covers the tool's behavior and return value. No gaps for an information tool of this simplicity.
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?
No parameters exist, and schema coverage is 100% (empty). Baseline is 4 per rules for 0 params. The description does not need to add parameter info, and it correctly omits it.
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 explicitly states the tool shows active preset, available presets, and registered tools. It also specifies the return JSON structure, making the purpose very clear. Among many sibling get_* tools, this uniquely focuses on session configuration and presets.
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?
No explicit guidance on when to use or avoid this tool. While the purpose is clear, there is no mention of alternatives or contexts where this tool is preferred over other info tools. Usage is implied but not stated.
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?
Description aligns with annotations (read-only, safe) and adds cost context ('much cheaper'). Annotations already cover the safety profile, so description adds marginal value.
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?
Two sentences pack purpose, usage, alternative, and return format. No fluff; every sentence earns its place.
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?
For a simple tool with one optional parameter and no output schema, the description is complete: covers purpose, return format, usage guidance, and alternative. No gaps.
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 covers the only parameter 'max_sessions' fully with description and constraints. Description does not add further parameter details. Baseline 3 due to high schema coverage (100%).
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 verb 'shows' and resource 'recent past sessions', listing specific content (files, tools, dead-end searches). It distinguishes from sibling tool 'get_wake_up' by mentioning an alternative 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when to use ('Call at session start'), why it's beneficial ('cheaper than re-exploring'), and an alternative ('use get_wake_up instead'). Also notes read-only nature.
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 fully discloses behavior beyond annotations: the two-pass workflow (preview then apply), engine selection logic (auto defaults), and pattern matching characteristics (AST patterns ignore strings/comments). It also mentions the return JSON shape. Annotations already declare destructiveHint=true, and the description reinforces this with explicit warning.
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 single paragraph of ~100 words, front-loaded with purpose. It covers key points concisely but lacks clear section breaks. Every sentence adds value; no unnecessary words.
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 (8 params, 3 required, no output schema), the description is remarkably complete. It explains engine behavior, workflow, return type, and provides explicit warnings. No critical information is missing.
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 100% with thorough descriptions for all 8 parameters. The description adds high-level context (e.g., engine default behavior, dry-run workflow) but does not significantly enhance individual parameter semantics beyond what the schema already provides. Baseline 3 is appropriate.
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: 'Structural (AST-aware) or regex find-and-replace across files.' It distinguishes between AST and regex engines with specific examples, and the verb 'apply_codemod' aligns with the action. Compared to siblings, this tool is uniquely for find-and-replace operations.
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 usage guidance: dry-run by default, preview first, set dry_run=false to apply. It warns about destructiveness and advises previewing. It explains when to use AST vs regex patterns. However, it doesn't explicitly list when not to use this tool or mention specific alternatives.
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?
Annotations already indicate readOnly and idempotent. The description adds that it is read-only (consistent) and describes the output structure ('Returns JSON: { risk, level, factors, mitigations }') and the factors considered. This adds useful context beyond what annotations provide.
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 two sentences plus a brief output summary, front-loaded with the core purpose. No redundant words, every sentence adds value.
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?
For a tool with no output schema, the description enumerates the output fields and factors. It explains the scope (quick risk check) and the inputs. It is sufficiently complete for an agent to understand what it returns and how to use it.
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 100% with both parameters described. The description does not add significant new meaning beyond the schema, simply mentioning file or symbol. Baseline 3 is appropriate.
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 predicts risk level (low/medium/high/critical) with factors and mitigations, and distinguishes from siblings like get_change_impact by mentioning it combines blast radius, complexity, etc. It is specific and actionable.
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 tells when to use ('quick risk check') and when not to ('for full impact report use get_change_impact'), providing a clear alternative. This helps the agent decide which tool to invoke.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds 'Read-only' (redundant) and describes the bidirectional nature and return JSON shape, offering behavioral context beyond 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?
Three concise sentences: purpose, usage guidance, then safety and output format. No wasted words, well-structured.
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?
Covers purpose, usage, safety, and output shape. Lacks explanation of behavior when both symbol_id and fqn are provided, but overall sufficient for an agent to select and invoke the tool correctly.
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 has 100% parameter description coverage. The description does not add extra parameter details beyond the schema, so baseline 3 is appropriate.
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 builds a bidirectional call graph centered on a symbol, specifying both incoming and outgoing calls. It also contrasts with sibling tool find_usages, 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using this tool for understanding control flow through a function and directs to find_usages for flat references. Provides clear context for when to use and when not.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false. The description adds value by explicitly stating 'Read-only, no side effects, safe for secrets' and explaining the redacted mode and return format, going beyond 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 efficiently structured: first sentence states purpose, then clarifies limitations, then usage guidance, then redacted mode specifics. It is concise yet complete, with no wasted words.
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?
The description fully explains what the tool does, its return format (JSON grouped by file), and all parameters. No output schema exists, but the description compensates adequately, making it complete for an AI agent.
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?
With 100% schema coverage, baseline is 3. The description adds useful semantics for 'pattern' (filter keys) and 'redacted' (requires file, returns line-by-line view), enhancing understanding beyond 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 clearly states it lists environment variable keys, types, and formats from .env files without exposing values. It distinguishes its scope from other tools by specifying exactly what it returns and what it avoids (actual values).
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 use context (understand project configuration) and explains the redacted option. It lacks explicit mention of when not to use it or alternative tools, but the specificity is sufficient.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that it is read-only and returns JSON or Markdown, which is consistent. No contradictions.
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?
Description is two sentences, front-loaded with purpose, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, alternatives, and output format. With 5 parameters and no output schema, the description could explicitly mention the returned fields, but the listed content (execution paths, etc.) provides adequate context.
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 all 5 parameters (100% coverage). Description adds no additional meaning beyond what the schema already provides, such as the output_format enum.
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?
Clearly states it provides 'all-in-one context for starting a dev task' and lists specific content (execution paths, tests, entry points). Distinguishes from sibling tool get_feature_context.
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 instructs to use as the first call when beginning a new task and provides an alternative (get_feature_context for narrower lookups). Also mentions it replaces manual chaining.
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?
Description confirms read-only behavior (aligns with readOnlyHint) and adds specifics: checks own file and all importing files, returns conflict details. Exceeds annotation-only info.
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?
Three focused sentences: purpose, usage instruction, behavior and return format. No wasted words.
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, description explains return JSON structure. Annotations cover safety, schema covers params. All needed context is present.
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 100% with parameter descriptions. Description does not add new semantic detail beyond those, though it provides context by mentioning the scope of checks.
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?
Clearly identifies as pre-rename collision detection, checks symbol's own file and importing files for target name conflicts. Distinct from sibling apply_rename.
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?
Explicitly states 'Use before apply_rename to verify safety', providing clear usage context. No explicit when-not or alternatives needed for a safety check.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral context beyond annotations: it states the tool requires git, and describes the return format (JSON structure). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with 4 short informative sentences. It front-loads the core purpose, then adds utility, alternatives, read-only nature, and return format. No filler or redundant information.
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 explains the return format. It covers the git dependency, parameter meaning (though schema already covers), and the usage context. The description is complete for a simple tool with 2 parameters and clear behavior.
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 100% with descriptions for both parameters. The description mentions the default for snapshots (5) but the schema already includes this information. Therefore, the description adds minimal meaning beyond what the schema provides.
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 shows file complexity over git history using cyclomatic complexity, and explicitly distinguishes it from siblings (get_complexity_report for current snapshot, get_symbol_complexity_trend for symbol-level). The verb 'get' combined with resource 'complexity_trend' is specific and unambiguous.
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 guidance on when to use the tool ('to track whether a file is improving or degrading') and when not to use it by naming exact alternatives for current snapshot and symbol-level trends. It also notes the requirement for git.
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?
Annotations already declare readOnlyHint=true, so the description's 'Read-only' adds little. However, it discloses output structure (nodes, edges, etc.) and the code constructs analyzed, which goes beyond 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?
Three concise sentences: first states purpose and scope, second gives usage reasoning and alternative, third mentions read-only and output details. Front-loaded and zero waste.
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 explains the return structure and what code constructs are covered. With rich annotations and schema, this is complete for an agent to correctly invoke the tool.
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 100% with descriptions for all parameters. The description adds no additional parameter-level information, so baseline 3 is appropriate.
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 builds a Control Flow Graph for a function/method, listing specific constructs (branches, loops, etc.) and output formats. It also distinguishes itself from the sibling tool get_call_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?
Explicitly advises using it to understand branching logic before modifying complex functions, and directs to get_call_graph for call-level graphs. This provides 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive. Description adds that it requires git and details the JSON output format, but does not contradict 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?
Four sentences with no fluff. Front-loaded with core purpose, then usage, then output format. Every sentence adds value.
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?
Fully covers purpose, usage, prerequisites, and output format. Given no output schema, the description provides sufficient detail for agent to understand and invoke correctly.
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 provides clear descriptions for all 3 parameters (100% coverage). Description does not add new parameter details beyond what schema provides, so baseline of 3 is appropriate.
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?
Clearly states it analyzes file coupling over git history, showing Ca/Ce/instability and tracking module stability. Explicitly differentiates from get_coupling for current snapshots.
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?
Directs to use for tracking module stability over time and explicitly recommends get_coupling for current snapshots. Also notes 'Requires git' as a prerequisite.
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?
Annotations declare readOnlyHint and idempotentHint. Description reiterates 'Read-only' and describes the return format (JSON with implementations and total), adding transparency beyond 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?
Three concise sentences: purpose, usage guideline with alternative, and output format. Efficiently front-loaded with no redundancy.
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 one parameter, strong annotations, and a clear return format description, the tool definition is fully informative and leaves no gaps.
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 100% with a clear description and example. The description mentions the parameter's purpose but adds minimal extra 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?
Clearly states the tool finds classes implementing/extending an interface or base class. Distinguishes from get_type_hierarchy by specifying this tool is for when you know the interface name.
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 when you know the interface name' and provides a clear alternative: 'For full hierarchy tree (ancestors + descendants) use get_type_hierarchy instead.'
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds useful behavioral context: 'Read-only' and describes the return JSON structure, clarifying what the tool produces.
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?
Three succinct sentences: purpose+patterns, usage alternatives, output structure. No wasted words and front-loaded.
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 one optional parameter and no output schema, the description fully covers purpose, behavior, output, and alternatives. Agent has enough context to select and invoke correctly.
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?
Only one parameter (period) whose schema has full coverage (enum, description). The description does not add additional meaning beyond what's in the schema; baseline 3 is appropriate.
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?
Description clearly states verb+resource ('Detect token waste patterns') and lists specific patterns. It distinguishes from siblings by mentioning alternative tools (get_session_analytics, get_real_savings).
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 tells when to use (detect token waste) and when to use alternatives ('For usage/cost overview use get_session_analytics; for A/B savings comparison use get_real_savings').
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds read-only reaffirmation and return structure (JSON format with fields), providing additional context beyond 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?
Two sentences: first states purpose and distinction, second states read-only and return format. No superfluous words, front-loaded with key information.
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 simple tool (1 optional param, no output schema), description fully covers purpose, usage guidelines, safety, return format. Agent can correctly select and invoke the tool.
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 has 100% coverage with description on the only parameter (period enum). Description does not add additional meaning beyond what schema already provides. Baseline 3 applies.
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?
Clearly states the tool performs A/B comparison of token savings between trace-mcp and raw reads, with per-file breakdown. Distinguishes from sibling get_optimization_report for pattern-based waste detection.
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 provides alternative tool: 'For pattern-based waste detection use get_optimization_report instead.' Guides when not 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds 'Read-only' and describes the return JSON structure, providing useful behavioral context beyond 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?
Two sentences, each packed with information. Front-loaded with the core functionality, followed by usage guidance and return type. No fluff.
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 rich annotations and full schema coverage, the description compensates for the lack of an output schema by detailing the return format. Usage guidelines and behavioral notes are sufficient.
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 100%, so the schema already documents both parameters. The description only adds a default value for max_results, which is marginal extra value.
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 specifies the verb 'Find', the resource 'symbols', and the criteria: co-location, shared importers, and name similarity. It also mentions alternative tools for different relationships, clearly distinguishing its purpose.
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?
Explicit guidance: 'Use when exploring a symbol to discover sibling code.' It also names specific alternatives: 'For call-graph relationships use get_call_graph instead; for all usages use find_usages.'
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that it parses Claude Code JSONL logs automatically and returns a specific JSON structure, providing useful behavioral context beyond 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?
Two sentences, front-loaded with purpose, no superfluous text. Every part adds value.
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, description specifies the output JSON structure (sessions, tokens, cost_usd, tools, models, topFiles). It covers input, behavior, and output sufficiently for an agent to use it correctly.
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 100%, so description adds little beyond schema. It notes the default for 'period' but the schema already has enum values. Parameter semantics are adequately handled by 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 analyzes AI agent session logs, listing specific outputs (token usage, cost breakdown, top files, models). It distinguishes itself from siblings by mentioning alternative tools for waste detection and cost trends.
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 provides when to use ('For waste detection use get_optimization_report; for cost trends use get_usage_trends') and declares read-only nature, guiding appropriate invocation.
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?
Annotations already provide readOnlyHint, etc. The description adds the exact return structure and lists latency metrics, going beyond 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?
Two sentences, no waste, front-loaded with key information and structured return format.
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?
Covers purpose, return structure, and safety; no output schema needed as description is self-contained.
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?
No parameters exist, so baseline is 4. The description adds value by detailing the return JSON structure.
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 specifies the exact resource (session stats) and lists all returned metrics (call counts, token savings, etc.), clearly distinguishing it from sibling tools like get_session_analytics.
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 indicates it's for the current session and is read-only, but does not explicitly state when not to use or mention alternatives.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds 'Read-only' and specifies the return format, supplementing the annotations with useful behavioral context.
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 very concise: two sentences plus a JSON outline. Every element adds value, and the most important information is front-loaded.
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 one optional parameter and no output schema, the description provides the return format and purpose, which is 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter ('days') with full schema description (default 30, min 1, max 365). The tool description does not add further meaning beyond the schema, so baseline 3 is appropriate.
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 provides daily token usage time-series with specific metrics (sessions, tokens, cost, tool calls). It distinguishes from siblings by explicitly recommending get_session_analytics for detailed session breakdown.
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 explicitly says the tool is for spotting cost spikes and directs users to get_session_analytics for detailed breakdown, providing clear guidance on when and when not to use.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that it is 'Read-only' and describes the return JSON structure, which provides useful behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no wasted words. The main purpose is front-loaded, followed by output details and usage guidance. Every sentence earns its place.
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 simple schema (1 optional parameter, no output schema) and the description's coverage of output format and usage, it is fully complete for an agent to understand and invoke the tool correctly.
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 100% (one boolean parameter fully described in schema). The description does not add extra parameter details beyond what the schema provides, so baseline score of 3 is appropriate.
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 lists all detected monorepo workspaces with metrics and a dependency graph. It uses a specific verb ('List') and resource ('monorepo workspaces'), and distinguishes itself from sibling tool get_cross_workspace_impact.
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 for monorepo structure overview. For impact of changes on other workspaces use get_cross_workspace_impact instead.' This provides clear when-to-use and when-not-to-use guidance, along with an alternative.
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?
Annotations declare idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds that it mutates the decision store (aligning with readOnlyHint=false), returns JSON with specific fields, and idempotent behavior. It does not contradict annotations, and adds meaningful context about what gets invalidated and return format.
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?
Three sentences: states action, explains consequence, provides usage context and mutability, mentions idempotence and return format. No wasted words, every sentence adds value.
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 no output schema, the description includes the return format. It covers all necessary behavioral aspects for an agent to use the tool correctly. No missing information given the tool's complexity and the richness of annotations.
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%, so baseline is 3. The description explains both parameters: id (decision ID) and valid_until (ISO timestamp, default now). It adds meaning beyond the schema by clarifying the purpose of valid_until and its default value.
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 marks a decision as invalid, explains it remains in the knowledge graph for history but is excluded from active queries, and specifies usage context (superseded or reversed). This distinguishes it from siblings like approve_decision or reject_decision.
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?
Explicitly advises to use when a decision is superseded or reversed. While no explicit when-not is given, the context is clear from the description and sibling names. Could be improved by stating not to use for permanent deletion, but sufficient.
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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds significant behavioral context beyond these: explains read-only nature, hard-cap timeout with degraded response, staleness verification, output format options (including TOON for token savings), and cluster behavior. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized given the tool's complexity (17 parameters, 5 enums). Each sentence adds value, covering purpose, filtering, output format, timeout, verification, and clustering. It is front-loaded with the main purpose and structured logically, though it could be slightly more concise.
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?
For a tool with 17 parameters, 5 enums, and no output schema, the description provides extensive context: filter options, default behaviors, output shape (JSON with decisions and clusters_summary), timeout handling, and verification details. It covers most important aspects for an agent to use it correctly, though some edge cases (e.g., exact content fields) might require schema inspection.
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% with detailed parameter descriptions. The description adds extra context for several parameters, such as order_by heat degradation, git_branch defaults, verify staleness check, and output_format TOON explanation. It goes beyond the schema by clarifying behavior and defaults, justifying a score above baseline 3.
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 queries the decision knowledge graph, filtering by multiple criteria, and returns decisions linked to code. It uses a specific verb ('Query') and resource ('decision knowledge graph'), and distinguishes itself from siblings like add_decision, get_decision, and other query tools by focusing on the knowledge graph with rich filtering.
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 explicit guidance on when to use parameters like service_name for subproject filtering, include_pending for review queue, and review_status for specific tiers. It also mentions default behavior (auto-approved + human-approved) and alternatives (get_decision for full content with index_only). However, it does not explicitly state when not 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint. Description adds that it mutates the index, explains cache invalidation, duplication checks, and return format, providing context beyond 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?
Four sentences, front-loaded with action and immediate effects, then usage and warnings. No redundant words.
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?
Tool has one param, no output schema, but description explains return JSON structure fully. Covers purpose, usage, side effects, and duplication warnings.
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 has 100% coverage for the single parameter. Description adds minimal extra context (relative path, edited file), but baseline is 3.
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 notifies trace-mcp of an edited file, reindexes it, and invalidates caches. It distinguishes from siblings like reindex by noting it's lighter.
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 to call after Edit/Write, contrasts with full reindex, and gives guidance on handling duplication warnings.
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 explicitly states 'Read-only', which aligns with the annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false). It goes beyond annotations by clarifying the response behavior when no gates are configured (returns NO_GATES_CONFIGURED, not misleading PASS) and when use_default_gates is set. This prevents misinterpretation and adds valuable behavioral context.
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 well-structured, starting with the primary purpose and followed by usage context, edge cases, and return format. It is informative without being verbose, though it could be slightly tightened (e.g., combining the CI and PR sentences). Overall, every sentence adds value, justifying a score of 4.
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 5 parameters (100% schema coverage), no output schema, and moderate complexity, the description covers all critical aspects: what it does, when to use, edge cases (no gates, default rules), and return structure. It also mentions the JSON response format. This level of detail ensures an agent can correctly invoke and interpret the tool without additional context.
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?
With 100% schema coverage, the baseline is 3. The description adds meaning by explaining the use_default_gates behavior ('Opt-in to the conservative built-in default ruleset...') and the output_format options ('json' vs 'sarif'). It also clarifies the semantics of 'scope' and 'config' indirectly. These additions raise the score above baseline.
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 specifies the tool's verb ('Run configurable quality gate checks'), resource ('project'), and outcome ('Returns pass/fail for each gate'). It lists the specific gate types (complexity, coupling, circular imports, etc.), making the purpose unmistakable. While it doesn't explicitly differentiate from sibling tools, the unique scope ('quality gates') and the detailed gate list provide strong distinctiveness.
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 context for when to use the tool: 'Use before PR/commit to ensure quality standards' and 'Designed for CI integration — AI can verify gates pass before committing.' It also explains the special case when no gates are configured, which helps the agent understand the tool's behavior. However, it does not explicitly state when not to use it or mention alternative tools for similar tasks, slightly limiting guidance.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds value by confirming read-only behavior, detailing the return shape (JSON with findings array), and explaining ORM plugin dependency. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured. It front-loads the purpose and then provides detailed antipattern conditions and usage notes. Every sentence adds value. However, it is slightly long; a minor restructure could improve readability without losing information.
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 complexity of detecting 11 antipattern categories with various conditions, the description is highly complete. It covers prerequisites, filter options, output format, and fallback alternatives. No output schema exists, so the description adequately explains the return structure.
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 100%, so parameters are well-documented in the schema. The description adds context beyond the schema: it explains default values (limit default 100, all categories), lists categories in prose, and elaborates on the output_format semantics ('json' vs 'sarif'). This enriches the agent's understanding.
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 detects performance & design antipatterns and lists specific categories. It distinguishes from siblings by explicitly naming alternative tools for related tasks (e.g., get_circular_imports for import cycles, scan_code_smells for code quality, scan_security for security).
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: when to use this tool vs alternatives, preconditions (ORM plugin required for certain signals), and scope of detectors. It also explains which detectors always run. This gives the agent clear decision criteria.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false; description adds caching behavior (1-hour, refresh=true), git requirement, methodology disclosure, and the nature of scores (heuristic with calibration results). No contradictions.
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 somewhat long but packed with useful information and front-loaded with the main purpose. Each sentence contributes value, though it could be slightly more concise.
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?
For a parameter-heavy tool with 4 params, no output schema, and complex behavior (caching, calibration, multiple signals), the description covers return structure, caching, git dependency, methodology, and limitations comprehensively.
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 100% with descriptions for all 4 parameters. The description adds default values (limit 50, min_score 0) and clarifies refresh usage, but does not provide significant additional meaning beyond what the schema already offers.
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 ranks files by a multi-signal heuristic for bug-risk triage, distinguishing it from sibling 'get_risk_hotspots' which is mentioned as an alternative for a narrower 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('prioritize where to look first') and when not to ('not to certify a file as buggy') and provides an alternative tool for a subset scenario (get_risk_hotspots). Also notes the heuristic nature with calibration data.
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 significant behavioral context beyond annotations: read-only confirmation, auto-exclusion of supplied symbol_id, score interpretation (≥0.7 high likelihood), and return JSON format. No contradictions.
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 comprehensive and front-loaded with the main purpose. Each sentence adds important information, though slightly verbose. It could be tightened without losing clarity.
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 (5 params, no output schema), the description covers all essential aspects: use cases, parameter behavior, scoring, and return format. It is complete and actionable.
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 100% with detailed parameter descriptions. The description adds value by explaining combined usage (name vs symbol_id), exclusion semantics, and default threshold, enhancing understanding 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 the tool checks for duplicate function/class names, with specific verb (check) and resource (existence in codebase). It distinguishes from siblings by focusing on duplication detection, and provides a concise purpose.
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 explicit usage patterns: using 'name' for pre-create checks and 'symbol_id' for existing symbols, with exclusion behavior explained. It lacks direct mention of alternatives but the 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds behavioral details: requires git, auto-detects main/master base, and explains output_format effects on token cost. No contradictions.
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?
Description is concise, front-loaded with core purpose, and every sentence adds meaningful information. No fluff, covers purpose, usage, behavior, output, and a tip.
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 5 parameters, no output schema, and annotations present, the description provides sufficient context: return format (JSON with changes and total), required git, auto-detection, alternative tool, and output format options. It leaves little ambiguity.
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%, so baseline is 3. Description adds value by explaining auto-detection of 'since', the purpose of 'output_format' (TOON encoding for token savings), and the return structure. This goes 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 maps a git diff to affected symbols (functions, classes, methods) and is intended for PR review. It distinguishes itself from the sibling tool compare_branches by specifying a different 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use for PR review' and directs to compare_branches for full branch comparison with risk assessment. Also mentions auto-detection of base branch when 'since' is omitted, providing clear context.
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?
Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description reinforces read-only nature and adds details about output format options (JSON, markdown, TOON) with token savings, which goes beyond basic safety.
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?
Two concise sentences with a structured note on output formats. No unnecessary words, all sentences earn their place.
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 5 parameters (all described in schema), no output schema, and rich sibling set, the description covers tool purpose, usage guidance, parameter defaults, output structure, and format options. Complete and self-contained.
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%, so description does not need to repeat parameters. However, it adds helpful clarifications: default min_cyclomatic (1 for file, 5 for project), behavior when file_path is omitted, and explanation of output_format options. This adds moderate value 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?
Clearly states it gets complexity metrics (cyclomatic, max nesting, param count) for symbols in a file or across the project. Distinguishes itself from sibling tool get_complexity_trend by noting that tool is for historical trends.
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?
Explicitly says 'Use to identify complex code before refactoring' and points to an alternative for historical trends. Provides context but does not cover all possible use/non-use cases.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral context: read-only nature, return structure (JSON with sections), and token budget mechanism. No contradictions. With good annotations, the additional context merits a 4.
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?
Three sentences: purpose, usage guidelines, return structure. Front-loaded, every sentence adds value, no fluff. Excellent conciseness.
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 (6 parameters, batch queries, token budget), the description covers return structure, deduplication benefit, and differentiation from get_symbol. No output schema makes the return description essential; it is provided. Complete and self-contained.
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% with parameter descriptions. The description adds meaning beyond the schema by explaining that symbol_id and symbol_ids enable batch queries with deduplication, and that fqn is an alternative. It also contextualizes token_budget and include_callers implicitly. This goes beyond a baseline 3.
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 precisely states the tool retrieves source code, imports, and optional callers within a token budget. It distinguishes itself from siblings by explicitly calling out get_symbol and the benetfit of shared-import deduplication.
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 clear when-to-use guidance: 'Use instead of chaining get_symbol calls' and when-not-to-use: 'For a single symbol without imports, get_symbol is lighter.' This directly addresses alternatives.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, etc. The description adds 'Read-only' (consistent) and describes return format as JSON with specific fields, plus the TOON encoding option. No contradictions.
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?
Three focused sentences: first states metrics and outcome, second gives use case, third provides alternative. Then additional info on read-only, return structure, and encoding option. No unnecessary words.
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 no output schema, the description perfectly fills the gap by listing returned fields. It covers purpose, usage, alternative, parameter options, and encoding format. Everything an agent needs is present.
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% so all parameters are described. The description adds value by explaining the 'output_format' parameter's 'toon' option and its token-saving benefit, and implicitly ties 'assessment' parameter to stability filter.
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 computes coupling metrics (Ca, Ce, instability) per file and identifies stable vs unstable modules. It explicitly distinguishes from sibling tool get_coupling_trend by stating 'For coupling changes over time use get_coupling_trend instead.'
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 usage context: 'Use to identify fragile or overly-depended-on modules.' and gives a clear when-not-to-use with an alternative tool named (get_coupling_trend).
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, but description adds 'Read-only, no side effects' and specifies return JSON structure, adding value beyond 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?
Three concise sentences with no redundancy: states purpose, adds behavioral note, gives usage guidance, and lists output fields. Every sentence adds value.
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, description fully specifies return structure (frameworks, languages, fileCount, symbolCount, structure). Complete for a simple, self-contained read operation.
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 covers 100% of parameter (summary_only) with description. The description reinforces usage with summary_only=true at session start, providing context beyond 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?
Description clearly states it provides project overview including frameworks, languages, file counts, and structure. Specific verb 'Get' and resource 'project map' distinguish it from sibling tools like get_workspace_map or get_domain_map.
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 advises to call with summary_only=true at session start and to use instead of manual ls/find, providing clear when-to-use and alternatives.
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?
Annotations already provide readOnlyHint, destructiveHint, and idempotentHint. The description adds value by stating 'Read-only' and detailing behavioral aspects like fuzzy auto-enable, fusion pipeline, mode-specific return shapes, and output format options. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured. It front-loads the core purpose and usage guidelines, then systematically covers features. Each sentence adds value, though minor redundancy could be trimmed. Efficient given the 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?
For a tool with 21 parameters and no output schema, the description thoroughly explains return format (JSON structure with fields and mode-specific shapes), lossless TOON encoding, and all key features. It covers pagination (limit/offset), filters, and retrieval strategies, leaving little ambiguity.
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?
With 100% schema coverage, baseline is 3, but the description adds significant meaning: explains modes (single, tiered, drill, flat, get), fusion with defaults, semantic modes, detail_level and output_format token savings, and drill_from scope. This goes well 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 symbols by name, kind, or text, and distinguishes itself from siblings like search_text and find_usages. It specifies the target audience (functions, classes, methods, variables) and provides alternatives, 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool vs alternatives: 'Use instead of Grep when looking for functions, classes, methods, or variables... For raw text/string/comment search use search_text instead. For finding who references a known symbol use find_usages instead.' This provides clear guidance on selection.
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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it is 'Read-only' (consistent with annotations) and specifies the JSON return structure. While it does not disclose additional behavioral traits beyond what annotations provide, the return format detail adds useful context.
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?
Three sentences efficiently convey purpose, usage guidance, and return format. No redundant information. Front-loaded with the key purpose.
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 no parameters and no output schema, the description fully covers what the tool does, when to use it (first exploration), and what it returns (JSON with topFiles, topSymbols, languageStats, exampleQueries). It also references a sibling tool for alternative use cases.
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?
There are no parameters (input schema empty), so schema coverage is 100%. The description does not need to explain parameters. Baseline for 0 parameters is 4, and the description adds value by explaining the output structure.
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 is an onboarding helper that shows top imported files, PageRank symbols, language stats, and example tool calls. It distinguishes itself from the sibling tool get_project_map by indicating that for a structured project map, that tool should be used instead.
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 'Call this first when exploring an unfamiliar project' and provides an alternative tool (get_project_map) for a structured map. This gives clear guidance on when to use and when not 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, non-destructive, idempotent. The description adds value by explaining the ambiguous text-matching filter, the output format, and that it is read-only, covering behavioral traits beyond annotations without 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 front-loaded with the main purpose and uses every sentence to add value: usage guidance, behavior, parameter tips, output format. No wasted words; concise yet comprehensive.
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 no output schema, description provides output structure (references array, total, ambiguous_filtered). Covers filtering behavior and parameter effects. Minor gap: required parameters are all three (symbol_id, fqn, file_path) but description implies uses for symbol or file, potentially underspecifying requirements.
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%, so baseline is 3. The description adds context for detail_level (token reduction) and include_ambiguous_text_matched (why to use it), enhancing meaning beyond schema. Minor gap: does not clarify that all three key parameters are required despite suggesting symbol or file focus.
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 finds all places referencing a symbol or file (imports, calls, renders, dispatches). It distinguishes from siblings like 'get_call_graph' and mentions using instead of Grep, establishing a specific verb-resource pair with differentiation.
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 tells when to use this tool (instead of Grep for symbol usages) and when to use alternatives (get_call_graph for bidirectional call graph). It also explains the default filtering behavior and the parameter to override, providing clear context.
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?
Beyond annotations (readOnlyHint, destructiveHint, idempotentHint), description details the two algorithms, mentions emitted fields (_methodology, _warnings), and states the tool is read-only. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph with clear structure: purpose, mode explanations, usage guidance, output summary. Front-loaded with key term. Minor redundancy but overall efficient.
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?
No output schema, but description specifies output structure (JSON with dead_symbols array, total, and attributes like confidence, signals). Covers all parameters, two modes, and entry point logic. Sufficient for a complex 5-parameter tool with multiple modes.
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?
All 5 parameters have schema descriptions (100% coverage), so baseline is 3. Description adds value by explaining mode-specific context (e.g., threshold default meaning, entry_points usage in reachability mode). Slightly above baseline.
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?
Description clearly states 'dead code detection', explains two modes with distinct behaviors, and explicitly names sibling tools get_dead_exports and remove_dead_code, distinguishing their 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?
Provides explicit guidance: when to use each mode, how to customize entry points, and when to use alternatives. Includes a direct statement: 'For quick export-only scan use get_dead_exports; to safely remove detected dead code use remove_dead_code.'
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?
Beyond annotations (readOnlyHint, etc.), description adds critical behavioral details: read-only nature, timeout behavior with hard cap and degraded response, output format options including TOON encoding benefits, and token budget limits. This fully informs agent 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?
Description is front-loaded with core purpose and usage guidelines, then covers details. While moderately long, every sentence adds value (timeout, formats, token economy). Minor redundancy ('Read-only' already implied by annotations) but overall efficient.
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 (search with token budget, multiple output formats, timeout behavior), the description is remarkably complete. It explains return structure, failure mode, and format trade-offs. No output schema needed because description covers it.
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%, setting baseline at 3. Description adds significant meaning: explains `description` as natural language query, `token_budget` as max tokens, and `output_format` with format-specific benefits (e.g., TOON saves 30-60% tokens). This exceeds baseline.
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?
Description clearly states the tool searches code by keyword/topic and returns ranked snippets within a token budget. It uses a specific verb ('Search') and identifies the resource ('code by keyword/topic'), distinguishing it from siblings like get_task_context and search.
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 states when to use ('when you need to READ actual code for a concept or feature') and provides specific alternatives: 'For structured task context with tests and entry points, use get_task_context instead. For symbol metadata without source, use search.'
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?
Annotations already indicate read-only, non-destructive, idempotent, closed-world. The description adds rich behavioral details like combining search, journal, risk assessment, and returning verdict, confidence, targets, scaffoldHints, nextSteps. No contradictions.
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?
Reasonably concise for the complexity. Front-loaded with purpose. Could be slightly tighter but no extraneous content.
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 specifies the return JSON structure with fields. It also mentions sibling tool context. Sufficiently complete for a complex tool with clear annotations.
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% with good descriptions. The description adds context (e.g., intent auto-classification, purpose of max_targets and skip_risk) beyond the schema. Minor additional value.
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 explicitly states it's an 'Opening-move router for new tasks' and lists its specific functionality. It distinguishes itself from get_task_context, clarifying when to use which tool.
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 guidance: 'Call this FIRST on a new task to break the empty-result hallucination chain.' Also specifies an alternative: 'For broader task context with source code use get_task_context instead.'
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?
Annotations already indicate read-only, but description reinforces 'Read-only' and adds return structure. No contradictions; adds value by describing diff-aware mode and output format.
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?
Four sentences efficiently convey purpose, usage, and key features. No fluff; front-loaded with essential information.
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, description enumerates return fields. All parameters documented in schema. Usage guidelines and behavioral notes are sufficient for complex 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 covers all 7 parameters with descriptions, so baseline is 3. Description adds context by explaining diff-aware mode and listing return fields, providing meaningful addition beyond 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?
Description clearly states it provides a full change impact report with specific components (risk score, breaking changes, dependents, etc.) and distinguishes from sibling assess_change_risk. The verb and resource are precise.
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 advises using before code modification and directs to sibling assess_change_risk for quick assessments. Provides clear context for appropriate invocation.
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?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds that it requires git and is read-only, aligning with annotations. It also details the return JSON structure, providing full behavioral 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Multiple sentences but each serves a purpose: identifies resource, lists metrics, notes git requirement, provides usage guidance, specifies read-only, and details return format. No filler; front-loaded with core purpose.
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 no output schema, the description compensates by explicitly stating the return format. It covers all parameters, the tool's requirement (git), differentiation from sibling, and the exact context for use. Fully complete for an agent to invoke correctly.
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?
Input schema has full descriptions for all three parameters. The description adds value by explaining the return shape (snapshots with commit, date, metrics), helping agents understand how parameters influence results. Baseline 3, plus extra context from description.
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 analyzes a single symbol's complexity metrics over git history, specifying cyclomatic, nesting, params, and lines. It distinguishes itself from the sibling tool get_complexity_trend by focusing on per-symbol rather than file-level trends.
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 states when to use (track a specific function's complexity evolution) and when not (for file-level trends, use get_complexity_trend instead). Provides clear context without ambiguity.
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?
Annotations confirm destructiveHint=true, and the description reinforces this: 'Destructive when applied — deletes code from source files.' It explains safety mechanisms: multi-signal detection for deadness verification and dry-run default. This adds significant value beyond the annotations alone.
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?
Four sentences only, each serving a distinct purpose: main action, verification detail, usage workflow, and data output. Front-loaded with the core purpose. No extraneous information.
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?
Without an output schema, the description includes the return JSON structure. It covers safety, workflow, and effects on other files. For a destructive tool with two parameters, this is fully complete and leaves no gaps for an AI agent.
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% with both parameters described. The description adds extra context: dry_run defaults to true for preview, and symbol_id comes from get_dead_code results. This enhances the schema's documentation but does not invent new 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 it removes dead symbols from files. It distinguishes from sibling tool get_dead_code by mentioning it as a prerequisite, establishing a clear workflow. The verb 'remove' is specific to the resource 'dead symbol'.
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 explicitly provides workflow: dry-run first to preview, then re-call with dry_run: false to apply. It warns about orphaned imports and directs users to use get_dead_code first. No ambiguity about when or when not 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it is read-only, skips test files, and returns JSON with specific fields. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured, front-loaded with purpose, lists CWEs efficiently.
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?
Explains return format and SARIF alternative, covers all parameters and annotations, no gaps.
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%; description adds value by clarifying defaults (scope whole project, output_format json, severity_threshold low) and special values like ['all'] for rules.
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?
Description clearly states it scans project files for OWASP Top-10 vulnerabilities using pattern matching, lists specific CWEs, and distinguishes from taint_analysis.
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 for pattern-based security audit and provides alternative taint_analysis for data-flow-aware analysis.
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?
Annotations already indicate read-only, and the description reaffirms 'Read-only' and details the return JSON structure. It also explains timeout behavior and grouping effect, adding value beyond 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 concise and well-structured: first sentence summarizes purpose, then differentiates from sibling, then provides details and return format. Every sentence adds value without redundancy.
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 complexity (9 parameters, no output schema), the description covers return format, usage guidance, parameter tips, and behavioral traits. No gaps remain; the agent can confidently invoke the 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%, so baseline is 3. The description adds meaningful extra guidance for parameters like 'grouping' (saves tokens), 'timeout_ms' (backtracking), and 'context_lines' (surrounding code), justifying a 4.
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 performs full-text search across all indexed files and distinguishes from symbol search by naming the sibling 'search' explicitly. It lists supported features and 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?
The description explicitly tells when to use (finding strings, comments, etc.) and when not to (symbol search, directing to 'search' instead). It provides concrete examples and alternatives.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that the tool returns a JSON with specific fields (deadExports, untestedSymbols, heritageDebt, summary), which is valuable beyond annotations. No contradictions.
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 two concise sentences listing the output fields. It is front-loaded with purpose and contains no unnecessary words.
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 parameters, annotations covering safety, and description detailing the return structure, the description is fully complete for this 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?
The tool has zero parameters, and schema coverage is 100%. The description does not need to explain parameters, so baseline 4 is appropriate.
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 performs a 'dead code & coverage audit' combining dead exports, untested symbols, and heritage debt. It explicitly distinguishes from sibling tools like get_dead_exports and get_untested_symbols.
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 advises using this tool for a one-shot health check and directs to individual sibling tools for separate checks. This provides clear context on when to use this versus alternatives.
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?
Beyond annotations (readOnly, idempotent, non-destructive), the description adds algorithmic detail (Kosaraju), clarifies edge types not walked (call, reference, etc.), and explains test file exclusion behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences cover purpose, constraints, use case, and output format. No redundant information, every sentence adds value. Front-loaded with key action and algorithm.
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?
For a simple tool with one optional parameter and no output schema, the description is fully complete: it explains the algorithm, edge types, test exclusion logic, return structure, and typical use case. No gaps.
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 single parameter 'include_tests' is fully described in both the schema and the description. The description adds context about why tests are excluded (spurious cycles) and the specific path patterns, enhancing understanding beyond the schema alone.
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?
Clearly states the tool finds circular dependency chains using the Kosaraju SCC algorithm, specifies the resource (import graph) and the scope (only import edges). It differentiates from siblings like get_import_graph and get_dependency_diagram by its specific purpose and constraints.
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 to detect and break dependency cycles.' Provides clear context on when to use, what edges are considered, and why test files are excluded by default with an opt-in option. Offers rationale for the exclusion, aiding agent decision-making.
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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, etc. Description adds key behavioral details: flags dead export keywords (not dead symbols), pagination with truncated/total_dead, and that it is read-only. No 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?
Every sentence adds value. Well-structured: purpose, differentiation, pagination, read-only, output format. No wasted words.
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?
No output schema, but description explains output structure (dead_exports array fields, total_dead, total_exports, truncated). Covers all parameters and behavioral aspects. Annotations cover safety.
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 100%. Description adds meaning beyond schema: file_pattern glob filtering, limit default/max/truncation, output_format enum explanations (json, markdown, toon with token savings).
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?
Description clearly states the tool finds exported symbols with no external consumer, explains the output fields (signals, recommendation), and distinguishes from `get_dead_code` by detailing the difference between dead export keywords and dead symbols.
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 when to use this tool vs `get_dead_code`, provides pagination limits (limit default 100, max 500, truncated behavior), and includes guidance on output_format options including 'toon' for token efficiency.
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?
Description discloses read-only nature, token savings, nested expansion with parentId/depth, output format options, and unsupported markdown behavior. Annotations already state readOnlyHint=true, consistent.
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?
Four sentences, well-organized, front-loaded with purpose. No wasted words. Each sentence provides essential information.
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?
No output schema, but description details return structure (path, language, symbols array with fields). Covers edge cases like nested depth and unsupported formats. Completely adequate for a 5-param 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?
Schema coverage is 100%, but description adds meaning for all parameters: nested default, min_loc_for_nesting range, output_format token savings, and markdown fallback. Adds significant value beyond 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?
Clearly states it gets all symbols for a file with signatures only, distinguishing from reading full file and get_symbol. Provides specific verb and resource.
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 recommends using this instead of Read to understand a file before editing, and suggests get_symbol for one symbol. Provides clear context and alternatives.
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?
Annotations already mark it as read-only and idempotent. The description adds 'Read-only' and details the output JSON structure, confidence levels, fallback behavior ('fell_back_to_file_level?'), and edge types. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five well-structured sentences with front-loaded purpose. Each sentence provides distinct value: usage advice, parameter behavior, output format, and alternative tool. No redundant or extraneous information.
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 complexity (4 parameters, multiple modes, output), the description covers purpose, usage, parameter semantics, return format (JSON with fields), and fallback behavior. No output schema exists, so the explanation of return values is appropriate and complete.
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 100%, but the description adds significant meaning: explains that symbol_id/fqn narrow to graph-resolved calls, file_path for file-level reachability, and min_confidence enum values with defaults. Also clarifies that min_confidence is ignored in file-level mode, which is beyond 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 the tool's purpose: 'Find test files and test functions that cover a given symbol or file.' It uses a specific verb ('find'), identifies the resource ('test files and test functions'), and specifies the scope ('cover a given symbol or file'). It distinguishes from sibling tools like 'get_untested_symbols' and mentions it's better than Glob/Grep.
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 advises to use instead of Glob/Grep, explains when to use symbol_id/fqn vs file_path, describes default min_confidence, and directs to 'get_untested_symbols' for alternative use cases. Provides clear context and exclusions.
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?
Annotations provide idempotentHint=true and destructiveHint=false. The description confirms idempotence ('safe to re-run') and adds that it mutates the index, explains postprocess behavior (what each level does), and discloses return structure. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficient: starts with purpose, then usage guidance, parameter details, idempotence note, and return format. Every sentence adds value without unnecessary verbosity.
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 no output schema, the description includes the exact return JSON structure. It covers parameters, behavior, usage context, and caveats (like preferring register_edit for single files). This is comprehensive for a tool with good annotations.
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 100% with descriptions for all three parameters. The description adds further meaning by explaining the postprocess flag's three levels in detail (full/minimal/none and their effects on speed and processing), which goes beyond the schema's enum 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 clearly states it triggers (re)indexing of a project/subdirectory and mutates the local index. It distinguishes itself from the sibling tool 'register_edit' for single-file updates, making its 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance: use after major file changes, prefer register_edit for single-file updates. Also details the postprocess flag levels, providing clear context on when to use each option.
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:

[![trace-mcp MCP server](https://glama.ai/mcp/servers/nikolai-vysotskyi/trace-mcp/badges/card.svg)](https://glama.ai/mcp/servers/nikolai-vysotskyi/trace-mcp)

Score Badge

Copy to your README.md:

[![trace-mcp MCP server](https://glama.ai/mcp/servers/nikolai-vysotskyi/trace-mcp/badges/score.svg)](https://glama.ai/mcp/servers/nikolai-vysotskyi/trace-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/nikolai-vysotskyi/trace-mcp'

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