ts-language-mcp
Server Quality Checklist
Latest release: v2.0.0
- Disambiguation3/5
Several tools serve overlapping purposes, making it ambiguous for an agent to choose. For instance, `get_symbols`, `find`, `get_workspace_symbols`, and `get_outline` all retrieve symbol information but with different levels of detail; `get_code_fixes` and `apply_code_fix` are tightly coupled; and `get_diagnostics` and `get_all_diagnostics` are very similar in functionality, differing only in scope.
Naming Consistency4/5The naming is largely consistent, following a `verb_noun` pattern throughout, which aids predictability. Minor deviations include `batch_analyze` instead of `analyze_batch`, and `find` and `quality_report` which lack nouns, but these are readable and do not significantly harm overall consistency.
Tool Count4/5With 29 tools, the count is on the higher side but still within a reasonable range given the broad scope of TypeScript language services covered. Each tool serves a specific analytical or transformation purpose, so the density is justified, though some consolidation could reduce potential overlap.
Completeness4/5The tool set covers an extensive range of language server capabilities including navigation, code actions, refactoring, diagnostics, and quality analysis. Minor gaps include a lack of tools for symbolic renaming previews being integrated with the rename tool itself, but overall the surface is comprehensive for static analysis and transformation tasks.
Average 3.9/5 across 29 of 29 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'context-aware' but gives no behavioral details: no indication of side effects, cost, rate limits, or return structure. The word 'Get' suggests read-only, but this is not explicitly stated, and the agent cannot infer safety or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. However, the second sentence ('Context-aware suggestions.') is vague and adds little value. The description is appropriately brief but could be more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, a complex anyOf constraint, and no output schema, the description is incomplete. It does not explain the output format, error behavior (e.g., ambiguous symbol), or how to effectively use the two alternative invocation patterns. The description relies entirely on the schema, which is insufficient for an 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it merely echoes 'position' and 'context-aware'. The anyOf constraint is not summarized, and the symbol parameter's behavior is left to the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('code completion suggestions') with a location ('at a position'). This distinguishes it from siblings like get_hover or get_signature, though it does not explicitly contrast with them. The term 'context-aware' adds some specificity but is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. With 27 sibling tools covering similar positional analysis, the absence of when/when-not instructions leaves the agent to infer from context. The description implies use for autocomplete but does not exclude other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states that it returns nested symbols with ranges, implying a read operation. It does not disclose any behavioral traits such as file type restrictions, performance characteristics, or whether the outline is live or cached.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, front-loaded with the key verb and resource. Every word is necessary; there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one parameter, no output schema, no annotations) and the large number of sibling tools, the description is too sparse. It does not explain what types of symbols are included, whether the outline is for the entire file, or how it relates to other symbol tools. More context is needed 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'file' parameter. The description adds no additional meaning beyond the schema, so it meets the baseline but does not add extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'hierarchical structure/outline of a file', and specifies the return value 'nested symbols with their ranges'. This distinguishes it from sibling tools like 'get_symbols' (which may be flat) and other analysis 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description only implies its purpose but does not mention when not to use it or provide alternative tools. With many siblings, this is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions that the compiler knows the exact edit and import path, but does not state whether the operation is read-only, what happens if no fixes exist, or any side effects. The description relies on the schema for ambiguous symbol behavior, which is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at four sentences, with each sentence providing distinct value: purpose, preference over manual fixes, targeting methods, and a hint about disambiguation. No redundant or unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and many siblings. The description does not describe the return format (e.g., what a fix looks like), does not mention the `errorCodes` parameter, and does not explain how to use the output in conjunction with `apply_code_fix`. This leaves significant gaps for an AI agent to correctly invoke and process the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by recommending the `symbol` parameter as preferred and explaining the `Container.member` qualification, which is already in the schema but reinforced. It also provides a usage hint about not needing coordinates, which is not in the schema, slightly improving semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves fixes proposed by TypeScript for errors at a position, with examples like adding imports or removing unused code. It is specific and distinguishes from general diagnostic tools, but does not explicitly differentiate from sibling tools like `apply_code_fix` or `get_diagnostics`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises preferring this tool over hand-writing fixes and explains two targeting methods (symbol vs. coordinates), with a preference for symbol. However, it does not provide guidance on when to use alternatives like `apply_code_fix` or when not to use this tool, which is important given the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. It mentions only the basic operation (fetching analyses) and a schema-detailed error for ambiguous symbols. Missing context includes: that the operation is read-only (implied but not stated), performance benefits of batching, error behavior for invalid positions, return format, or any side effects. This leaves significant gaps for an agent to safely invoke the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, no filler. The first sentence front-loads the primary purpose, and the second sentence provides a key usage hint (include parameter). Every word serves a purpose, and the structure makes the tool's action immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite high schema coverage, the description lacks completeness given the tool's complexity and many sibling tools. No information is given about return values, error handling beyond ambiguous symbols, prerequisites (e.g., open project), performance trade-offs, or when to use this vs. individual analysis tools. For an agent evaluating multiple similar tools, this description leaves many operational questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters meaningfully documented. The description adds marginal value beyond the schema: it explains that the include parameter selects analyses (with default all) and reiterates the purpose of positions for multiple positions. Since the schema already provides comprehensive descriptions (enum values, disambiguation syntax), the description provides minimal incremental semantic clarity, fitting a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Get hover, definition, references, diagnostics, and signature for multiple positions in one call.' It specifies a concrete verb ('Get') and resource (multiple analysis types across multiple positions). This distinguishes it from sibling tools like get_hover (single analysis, single position) and analyze_position (all analyses, single position). The list of analyses explicitly differentiates from other batch or individual tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need multiple positions or select analyses via the include parameter. However, it does not explicitly guide when to use batch_analyze over alternatives like calling individual tools sequentially or using analyze_position. No comparisons or exclusions are provided, leaving the agent to infer the best use case without clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'find all implementations' without disclosing return format, performance, or error behavior beyond the schema's note about ambiguous names. Key behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each contributing distinct information without redundancy. The main purpose is stated first, followed by context and usage strategy. No word is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and the presence of many sibling tools, the description covers input usage well but omits what the tool returns or any prerequisites (e.g., indexing). It leaves the agent guessing about the result structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds value by explaining the two targeting modes (symbol vs. coordinates), preferring symbol for convenience, and detailing qualification syntax. This goes beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds implementations of interfaces or abstract methods, and mentions it is useful for understanding polymorphic code. This distinguishes it from sibling tools like get_definition or get_references, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises preferring the symbol name over explicit coordinates, and explains how to qualify symbols. However, it does not provide when-to-use vs. alternatives like get_type_hierarchy or get_call_hierarchy, leaving the agent to infer selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly implies a read-only operation ('Find where a symbol is defined') and documents the two targeting modes. However, it does not specify the return format or handle edge cases like multiple definitions, leaving the agent to infer critical usage details from the schema 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. The first sentence front-loads the core purpose, and the second expands on targeting without any wasted words or redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no output schema, the description should compensate by explaining the return structure (e.g., a location object with file/line/range). It also does not address whether multiple definitions are returned for overloaded symbols. While the parameters are fully covered, the missing output specification leaves a gap for an agent trying to use the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage, with each parameter clearly documented (including qualification hints for 'symbol' and error behavior for ambiguity). The description adds only a summary preference for 'symbol' as the primary method, which provides marginal added value beyond 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'Find where a symbol is defined. Jump from usage to declaration.' This is a specific verb+resource combination that directly distinguishes from sibling tools like get_references (which finds all usages) and get_type_definition (which finds the type's definition). The addition of two targeting methods further clarifies the tool's capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus its many siblings (e.g., get_type_definition, get_implementations, get_references). While it explains two ways to specify the target, it fails to mention when one method is preferred over another in terms of tool choice. There are no exclusions, alternatives, or context about prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return content (type signature, JSDoc) and error behavior for ambiguous symbols. However, it omits details like output structure (e.g., is it a single string or structured object?), possible errors for missing symbols, and any side effects or permissions. It is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the purpose, and wastes no words. Every sentence adds distinct information. Excellent conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description covers inputs and outputs adequately. It mentions the return type and error condition. It does not explain output format or what happens for non-existent symbols, but these are minor gaps. For the complexity level, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by summarizing the two targeting modes and stating a preference for symbol name, and mentions that an ambiguous name returns error with candidates. These are useful clarifications but not transformative beyond the schema's detailed descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets type information and documentation for a symbol, using specific verbs and resource. It mentions returning both type signature and JSDoc comments, which distinguishes it from siblings like get_signature (only signature) or get_definition (only location). However, it does not explicitly differentiate from siblings, which prevents a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on using symbol name (preferred) vs. file/line/column, and mentions qualifying symbols to disambiguate. This helps the agent choose the right input mode. However, it does not advise when to use this tool versus alternatives such as get_type_definition or get_signature, and lacks explicit when-not or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It correctly states it lists imports (a read operation) and details what is included (named imports, defaults, namespaces), but does not disclose any edge cases (e.g., empty files, invalid syntax) or whether it follows dependencies transitively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, front-loaded with the action ('List all imports') and adds specifics. It wastes no words, though it could be even more concise by omitting the parenthetical (redundant with the output description).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 param, no output schema, no nested objects), the description covers the basic purpose and output structure. However, it lacks any context about error behavior (e.g., if file doesn't exist) or whether imports are resolved relative to project root or import paths.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'file' parameter, so baseline is 3. The description adds no extra semantic meaning about the file path beyond what the schema already states ('Path to the file (relative to project root)').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('list') and resource ('imports in a file') and distinguishes from siblings by specifying 'with their details (named imports, defaults, namespaces).' Sibling tools like 'organize_imports' or 'get_outline' have different purposes, making this scope clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to inspect imports in a file, but provides no explicit guidance on when to use this vs. 'organize_imports' or 'get_symbols' (which also deals with file symbols). No alternative tools or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not detail behavioral traits such as performance impact, auth needs, or whether results are cached. A moderate score as it at least discloses the multi-category aggregation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that efficiently conveys the tool's purpose and scope, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description could clarify the structure of the report (e.g., 'returns a JSON with per-category arrays'). However, it is sufficiently complete for a simple configuration like topN, and the parameter is well-covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter is fully documented. The description does not add extra meaning beyond the schema (e.g., what 'worst offenders' means or how topN affects output), so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a 'combined code quality report' covering complexity hotspots, coupled modules, and duplicate code. It distinguishes itself from sibling tools like detect_duplication and calculate_metrics by aggregating multiple categories in one call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is used for a consolidated overview of code quality issues, but does not explicitly state when to choose this over sibling tools like calculate_metrics or detect_duplication individually.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool searches the AST and supports pattern matching and filtering, which implies a read-only operation. However, it does not discuss performance characteristics, default behavior (e.g., project-wide scope), or whether the search is synchronous. The description adds moderate context beyond the schema but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of exactly two sentences: the first states the core purpose, and the second enumerates key capabilities. No words are wasted, and the most important information is front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 7 parameters, all well-documented in the schema, the description covers the main functional aspects: pattern matching, kind filtering, and export status. It omits mention of the scope parameter (project/file/directory) and pagination (limit, offset), but these are minor details. For a search tool with moderate complexity, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, earning a baseline of 3. The description adds concrete examples of how to use the query parameter (glob: *Service, regex: /^get/), which enriches the schema's generic description. It also explicitly ties the 'kinds' and 'exported' parameters to symbol filtering, reinforcing their purpose. This extra context justifies a slightly higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for symbols in the AST by name pattern and kind, using a specific verb ('Search') and resource ('symbols in the AST'). It outlines distinct capabilities (glob patterns, regex, filtering by kind and export status) that differentiate it from sibling tools like get_symbols, which likely only support exact name lookups. This makes the purpose immediately understandable and distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_symbols or get_workspace_symbols. It does not mention prerequisites, constraints, or scenarios where another tool would be more appropriate. An agent would have to infer usage context from the capabilities alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the use of the TypeScript compiler, handling of tsconfig paths/aliases, and coverage of various import types. It also mentions including efferent/afferent coupling and instability. Missing info on performance, error handling, or rate limits, but the given behavioral detail is good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs significant detail without being overly long. It is front-loaded with the main action. Minor improvement could be breaking it into two sentences for readability, but it is concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and no output schema, the description is adequate but incomplete. It does not explain the output format, structure of dependencies, or how coupling metrics are presented. The schema covers parameters, but the agent would benefit from knowing what the return data looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents parameters. The description adds context about the resolution mechanism and import types covered, which hints at the behavior of the parameters but does not directly add per-parameter meaning beyond 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/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool shows what a file imports and what imports it, resolved through the TypeScript compiler, covering static, re-export, dynamic, and require imports. It also mentions coupling metrics, distinguishing it from similar tools like 'get_imports' which may not resolve paths or include coupling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is used for dependency analysis with TS compiler resolution, but it does not explicitly state when to use this tool versus siblings like 'get_imports', 'calculate_metrics', or 'find'. No guidance on when not to use it or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that results include kind, source line, and text, and mentions error behavior for ambiguous symbols. However, it does not state whether the operation is read-only, mention performance implications, or describe any rate limits—leaving gaps for a tool that may scan large projects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place: purpose, result details, targeting methods, and error behavior. It is efficient and front-loaded with the core action. However, it could be slightly tighter by removing the parenthetical 'preferred: no need to know coordinates' which is already implied.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema, the description covers the essential usage: what results contain, how to target, and pagination support. It does not explicitly state what happens when a symbol is not found or if the file path is invalid, but these are minor omissions. Overall, the agent has enough information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds significant value beyond the schema: it explains that symbol is 'preferred' and how to qualify ambiguous names, it notes that combining with 'file' restricts scope, and it clarifies that 'contextLines' is additional to the already-carried line text. This enhances the agent's understanding of parameter intent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'find' and resource 'usages of a symbol across the project'. Distinguishes from siblings like get_definition or get_implementations by focusing on all usages rather than definitions or implementations. The description also notes the two targeting methods, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to use symbol name vs coordinates (preferring symbol) and mentions combining with 'file' to restrict scope. However, it does not explicitly compare to sibling tools (e.g., when to use get_references vs get_definition or get_implementations), leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description correctly discloses that the tool performs a preview and makes no changes. It clearly states that it shows all affected files and positions, which covers the key behavioral trait of being non-destructive. However, it does not mention what happens on ambiguity or error (though the schema covers that), and there is no mention of other potential side effects or authorization needs. Overall, it is transparent enough for a safe preview tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, both of which are essential: the first states the high-level purpose, and the second clarifies the non-destructive nature. Every sentence earns its place. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 5 parameters and no output schema, the description is brief. It does not describe the format of the preview result (e.g., list of file paths, line numbers, column numbers). Without output schema, this information is important for the agent to understand the return value. The description also lacks guidance on parameter combinations. It is adequate but not fully 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already described in the schema. The tool description adds no additional meaning about parameters (e.g., how to choose between the symbol vs line/column options). According to guidelines, baseline is 3, and there is no extra value added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Preview' and the resource 'locations that would change when renaming a symbol.' It distinguishes the tool from its sibling 'rename_symbol' by emphasizing that it shows affected files without making changes. The purpose 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it previews changes before renaming, but it does not explicitly say when to use it versus alternatives (e.g., 'use this before rename_symbol'). No when-not-to-use guidance is provided. The context with siblings suggests the workflow, but the description itself lacks explicit usage directives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It openly declares that the tool is a read-only aggregation of multiple analysis actions—no mention of side effects, permissions, or performance implications. The bundled nature is disclosed, but a description of what happens if the file/position is invalid or if the symbol is ambiguous is missing from the description (though the symbol parameter's error note covers one edge case).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-crafted sentence that front-loads the key benefit ('Get comprehensive analysis at a position') and lists the included features without any filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4 parameters (all documented in schema at 100% coverage), no output schema, and no annotations, the description efficiently summarizes the tool's purpose and scope. The missing pieces are minor: no mention of return format, how errors are reported (e.g., if both line/column and symbol are provided), or rate-limit considerations. But for a combined read tool, the current description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter-level semantics—it does not explain how 'file', 'line', 'column' interact (the schema already shows the anyOf requirement) or what 'signature help' includes. The symbol parameter description in the schema is already quite detailed, so the description adds no incremental value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a strong, specific verb ('Get comprehensive analysis') and clearly identifies the resource ('a position') and the bundled capabilities: hover info, definition, references, diagnostics, and signature help. This immediately distinguishes it from sibling tools like get_hover, get_definition, get_references, get_diagnostics, and get_signature that each handle only a single aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a one-stop shop for all text-document-or-symbol analysis, which provides clear usage context. However, it does not explicitly say when NOT to use it (e.g., if you only need a fast definition lookup) or name alternatives for sub-set use cases. A simple exclusion note would elevate this to 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It describes the tool as calculating static code metrics, which implies a read-only operation. It does not discuss performance implications for large projects or whether results are cached. The description adds useful context but lacks depth on side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long with no wasted words. Key information is front-loaded, and the usage tip is placed naturally at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 optional parameters, no output schema, clear context from sibling tool names), the description is nearly complete. It explains metrics computed and parameter usage. A minor gap is not specifying whether the output includes cumulative or per-function data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters well. The description adds slight value by reinforcing the tip for the 'file' parameter and implying 'topN' controls the number of hotspots. However, it does not explain the default for 'topN' beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates code quality metrics, explicitly naming cyclomatic complexity per function and lines of code per function/file. It also mentions identifying complexity hotspots, which distinguishes it from sibling tools like detect_duplication or quality_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a specific usage tip: 'Omit "file" for project-wide analysis.' This clarifies when to omit the file parameter. However, it does not explicitly distinguish when to use this tool versus siblings like quality_report or get_diagnostics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the output format (worst offenders, ranked, full call chains) and the analytical approach (tracing via depth). However, it does not state whether the operation is read-only, what data access permissions are needed, or any rate-limiting/performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant words. It front-loads the primary action and output, then adds a brief use case. Every sentence earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 optional parameters, no output schema, and no annotations, the description provides adequate context: it explains the tool's goal, the type of output, and the analytical scope. The only minor gap is lacking details on the output structure (e.g., what fields are in the call chain), but the schema descriptions and general output statement are sufficient for an agent 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3 is appropriate. The tool description does not add parameter-specific guidance beyond what the schema already provides. All parameters (skip, take, maxDepth, includeTests, minDirectCallers, maxChainsPerOffender) are well-documented in the schema, and the description focuses on the output and purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds symbols heavily accessed through multiple layers of indirection (A → B → C), with output ranked by score and full call chains. This verb+resource combination distinguishes it from sibling tools like get_call_hierarchy which focus on direct relationships.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly identifies the use case 'identifying hidden coupling and deeply wrapped dependencies', providing clear context. However, it does not explicitly exclude alternatives or mention when not to use it, missing an opportunity to differentiate further from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing side effects. It explicitly states 'write the result to disk' and notes that includeContent returns the formatted text. This covers the mutation behavior and optional return, though it doesn't detail error handling or overwrite semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and no extraneous details. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex nested options object and no output schema, but the description clearly explains the primary side effect (writing to disk) and the optional return behavior. It lacks details on edge cases or option usage, but the schema covers those, making this adequate for a formatting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description only paraphrases the includeContent parameter ('Pass includeContent to also get the formatted text back') without adding new details about file or options. It adds minimal value beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Format a TypeScript/JavaScript file using TypeScript's built-in formatter and write the result to disk.' It identifies the resource (file) and the specific verb (format), and distinguishes itself from sibling analysis tools by being the only formatting operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (for formatting) but does not explicitly contrast it with alternatives or state when not to use it. Siblings are all read/analysis tools, so the purpose alone suggests usage, but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It states the output is a 'flat list' and implies a read-only operation, which is useful. However, it lacks explicit disclosure of side effects, rate limits, authentication needs, or pagination behavior beyond the schema parameters. The description is accurate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the core function, and the second provides an alternative. There is no redundant or extraneous information, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (list symbols) and has no output schema. The description explains what it returns and when to use a different tool. It covers the essential context for an agent to decide to invoke it. A perfect score would require more detail on the exact structure of each symbol (e.g., name, kind, range), but the current description is sufficient given the tool's straightforward purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already defines the three parameters (file, limit, offset) with clear descriptions. The tool's description adds no additional meaning beyond the schema. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'symbols defined in a file', and the output format 'flat list'. It also distinguishes itself from the sibling 'get_outline' by explicitly noting that hierarchical structure should use that tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance to use 'get_outline' for hierarchical/nested structure, which is a clear alternative for a related use case. However, it does not address when to use this tool versus the many other siblings (e.g., get_hover, get_completions), which are for entirely different purposes, so the context is adequate but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the targeting mechanisms and direction options, but it does not disclose error handling (e.g., what happens if the class/interface doesn't exist), rate limits, or return format. The schema mentions error behavior for ambiguous symbols, but the description itself does not. Thus, transparency is adequate but not fully comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each earning its place. The first sentence states the purpose, the second explains the direction parameter, and the third covers the two targeting methods. No wasted words, 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (one required, one enum, two alternative targeting methods) and no output schema, the description adequately covers the input options. However, it does not describe the output format (e.g., list of names, tree structure) or behavior when the target is not found. For a hierarchy query tool, mentioning the return shape would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the direction enum values in a readable way ('supertypes shows parents, subtypes shows implementations/extensions') and by summarizing the preferred targeting method ('symbol' name preferred, no need to know coordinates). This helps an agent understand the parameter semantics more intuitively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), resource ('type hierarchy'), and scope ('for a class/interface'). It explains the two directions ('supertypes' shows parents, 'subtypes' shows implementations/extensions). This distinguishes it from siblings like get_implementations (which may only list direct implementations) and get_type_definition (which goes to definition).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that targeting by 'symbol' name is preferred and explains the alternative explicit coordinates, but it does not provide explicit guidance on when to use this tool versus its many siblings (e.g., get_implementations, get_call_hierarchy). The usage context is implicit from the purpose, but no explicit when-to-use or when-not-to-use advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool uses TypeScript's organizer, previews edits by default, and writes to disk only when 'apply' is true. This is adequate, though it omits details like error handling or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence states the core purpose, and the second adds usage guidance. Information is front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain what a preview looks like (e.g., a diff or list of changes). It also does not mention prerequisites like needing a TypeScript project or handling unsaved files. Given the 2-parameter simplicity, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters described in the input schema). The description adds minimal extra meaning beyond the schema, restating the 'apply' default. The baseline score of 3 is appropriate since the schema already provides comprehensive parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Sort' and 'drop unused ones' on the resource 'file's imports', using TypeScript's own organizer. This distinguishes it from sibling tools like get_imports (retrieval) and format_document (formatting), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the default behavior ('previews the edits by default') and how to apply changes ('pass apply to write them to disk'). While it does not explicitly list when to use or avoid this tool versus alternatives, the context of sibling tools provides enough implicit 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?
With no annotations provided, the description carries the full burden. It discloses sorting by severity, a default cap of 50 results, and the 'summary.total' and 'summary.truncated' fields. It could be improved by noting any performance implications or that it scans all files, but current coverage is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and scope. The second sentence adds critical behavioral details without any redundant or extraneous information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description reasonably explains the tool's behavior, including the summary fields. It could mention what a single diagnostic entry looks like or note that scanning all files may be slow on large projects, but it is largely complete for a diagnostics list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context about truncation and sorting, which relates to the 'limit' parameter, but adds little beyond what the schema already says for each parameter. No parameter-specific usage guidance is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get TypeScript + ESLint errors and warnings for all files in the project.' This provides a specific verb (Get), resource (diagnostics), and scope (all files). It distinguishes itself from the sibling 'get_diagnostics' by explicitly covering the entire project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Useful for checking project health after changes,' which gives a clear use case. It does not, however, explicitly mention when not to use this tool or name alternatives (e.g., 'get_diagnostics' for single-file checks), which would improve the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It reveals sorting and default capping behavior, and conditionally includes ESLint. However, it does not describe the output format, behavior on missing files, or how a capped result is indicated. This leaves moderate gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. Front-loaded with the core action, followed by conditional behavior. Every word serves a purpose. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 params, no output schema, no annotations), the description covers the main behavior and constraints well. It is missing the return format and explicit differentiation from siblings, but it is largely 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by explaining the default cap (relates to 'limit'), and the conditional inclusion of ESLint (relates to 'includeEslint'). It does not elaborate on 'file' or 'includeSuggestions', but the added context for two parameters justifies a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns TypeScript and ESLint errors and warnings for a file. The verb 'Get' and specific resource 'errors and warnings for a file' make the purpose unambiguous. It distinguishes from siblings like 'get_all_diagnostics' by specifying single-file scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: ESLint results are conditional on ESLint being installed, results are sorted by severity, and capped at 50 by default. However, it does not explicitly guide the agent on when to use this tool versus alternatives like 'get_all_diagnostics' or 'get_symbols', nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It mentions speed ('fast', 'faster') and 'supports fuzzy matching,' which are useful. However, it does not explicitly state that the tool is read-only, nor does it discuss authorization, side effects, or rate limits. For a search tool, read-only behavior can be inferred, but more transparency would be ideal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 48 words spread across three sentences. Every sentence adds value: the first states purpose, the second gives usage guidance, the third describes a key feature (fuzzy matching). No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema) and the presence of a sibling 'find' tool, the description adequately covers purpose, usage, and a notable feature. It does not describe the return format, but the tool name ('get_workspace_symbols') implies returning symbol objects. For a straightforward search tool, this is sufficient; it could mention the return type but is not severely lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already fully documents both parameters. The description adds no additional semantic meaning beyond what the schema provides (e.g., it repeats that the query is for symbol names). With full schema coverage, a baseline of 3 is appropriate; the description does not improve parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Fast symbol search across the workspace by name.' It specifies the verb (search), resource (symbols), and scope (workspace). It also differentiates from the sibling 'find' tool, establishing a distinct 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides guidance on when to use this tool: 'Faster than the find tool for simple name lookups.' This directly helps an agent decide between this and alternatives. It also implies when not to use it (complex lookups) without being overly verbose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It reveals that the tool writes to disk (destructive), that ambiguous symbols return an error listing candidates, and that applyToAll is conditional. It does not cover authentication or rollback, but the disclosed behaviors are relevant and significant for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a distinct purpose: overall action, applyToAll usage, and targeting options. No extraneous words or redundancy. It is well-structured and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, conditional logic, and no output schema, the description covers the essential usage patterns (targeting, applyToAll conditions, error handling for ambiguous symbols). It does not explicitly describe the return value or what 'success' looks like, but for a mutation tool this is a minor gap. The information is largely 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100% (all parameters documented in schema), the description adds meaning beyond the schema: it explains why symbol targeting is preferred (no coordinates needed), that combining symbol with file restricts search, the error behavior for ambiguous symbols, and the condition for applyToAll. This adds valuable semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Apply' and the resource 'one of the fixes returned by get_code_fixes and write it to disk'. It distinguishes itself from the sibling tool get_code_fixes (which returns fixes) by focusing on application and persistence. The purpose 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to use fixes from get_code_fixes and explains two targeting methods (preferring symbol over coordinates). It also notes the applyToAll option and its precondition (fixAllDescription). However, it does not explicitly state when not to use this tool or compare it to other mutation tools like rename_symbol, but the context of fixes makes the usage reasonably 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?
Without annotations, the description carries the full burden of disclosure. It correctly indicates this is a read-only operation (no side effects) and details the behavior: showing parameters, types, and active parameter based on cursor position. No contradictions with missing 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of moderate length that conveys the core purpose and behavior. Every clause earns its place with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could clarify the return format (e.g., list of signatures, active parameter index). However, the tool's name and common IDE conventions make the return format predictable. The coverage of use case, parameters, and behavior is sufficient for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the symbol parameter's qualification format (e.g., 'Container.member') and that ambiguous names return error with candidates. This goes beyond the schema's brief description and helps the agent use the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves function signature help when the cursor is inside parentheses. It specifies the resource (parameter names, types, active parameter) and distinguishes it from siblings like get_hover or get_completions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (cursor inside function call parentheses) and implicitly distinguishes it from get_hover and get_completions by targeting signature-specific information. However, it does not explicitly mention when not to use it or name alternative tools for other cursor positions.
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 key behaviors: the tool writes changes to disk (persistence), handles shorthand properties and aliased imports correctly (edge case handling), and returns a summary of files modified and total changes. No annotations are provided, so the description carries full burden; it covers mutation and return behavior well, though it could mention whether the operation is reversible or if confirmation is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with purpose, followed by key behavioral details and then usage guidance. Every sentence adds unique value with no redundancy or filler, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, anyOf constraint, no output schema), the description provides enough detail for usage: targeting methods, disambiguation, and return summary. However, without an output schema, describing the return format in more detail (e.g., structure of summary) would improve completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the dual targeting mechanism and qualification syntax for disambiguation ('Container.member'), which goes beyond the schema's brief descriptions. However, it doesn't add detail to 'newName' beyond what the schema provides, keeping the score at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'rename' and the resource 'symbol', explaining that it writes changes to disk and returns a summary. It distinguishes itself from siblings like 'get_references' or 'rename_preview' by emphasizing it performs the actual rename operation, while tools like 'rename_preview' likely just preview changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each targeting method: 'symbol' name is preferred because it avoids needing coordinates, and the alternative file/line/column approach is documented. It also explains how to disambiguate symbols (e.g., 'Container.member') and warns that ambiguous names return an error with candidates, which helps the agent avoid errors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the full burden. It discloses behavior on ambiguous symbol input (returns error listing candidates), the two targeting methods, and direction semantics. Read-only nature is implied by the operation name ('get') but not explicitly stated; overall adequate for a query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the purpose, then explain direction and targeting alternatives. Every sentence adds value, no redundancy. Concise yet complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, 100% schema coverage, and no output schema, the description covers core functionality well. It explains both targeting methods, direction, and error behavior. Lacks a brief note on return structure (e.g., list of call sites) but not critical given the schema detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds significant value beyond schema: explains preferred targeting (symbol), qualification format for disambiguation, combination with file, and error behavior on ambiguity. This guidance meaningfully helps the agent select parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get call hierarchy for a function/method' with specific verb and resource. It clearly distinguishes from sibling tools like get_references or get_type_hierarchy by focusing on call relationships and direction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use 'symbol' vs 'file/line/column' targeting, states symbol is preferred, and explains how to combine with 'file' to restrict search. Does not explicitly mention when not to use this tool (e.g., vs get_references) but gives sufficient context for correct 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?
No annotations are provided, so the description carries the full burden. It transparently discloses the dual targeting modes (symbol vs. coordinate), precedence order (symbol preferred), and error behavior for ambiguous names. It omits disclosure of potential side effects or performance implications, but as a jump/navigate tool these are minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
At two sentences, the description is efficient and front-loaded with the key distinction. Every sentence adds value: the first defines the tool's unique action; the second explains targeting options. Minor room for improvement: could front-load the targeting options more aggressively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a navigation/jump operation with no output schema, the description fully covers the what, why, and how. It explains the two targeting modes (symbol vs. coordinates), disambiguation for qualified names, error behavior, and the relationship to sibling 'get_definition'. No gaps for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. The description adds clear value by explaining the 'symbol' parameter supports qualification ('Container.member') for disambiguation, which goes beyond the schema's brief note. It also clarifies that using 'symbol' with 'file' restricts search scope, enriching the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Jump to the declaration') and clearly distinguishes this tool from its sibling ('get_definition'). It provides an explicit example contrasting landing on a variable vs. its type interface, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (to navigate to a symbol's type declaration rather than the symbol itself) and provides concrete guidance on how to target via 'symbol' name (preferred) or explicit file/line/column. It also explains what happens with ambiguous names, offering clear usage rules.
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?
Even without annotations, the description exhaustively discloses behavioral traits: it detects duplicates by AST fingerprint, ignores identifiers/literals (finding renamed copies), and explicitly specifies that it does not catch near-misses with extra statements. This fully informs the agent of the tool's capabilities and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—just two sentences—and front-loads the main action and method. Every sentence adds crucial information about what the tool does, how it works, and its limitations. No words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity of the tool (3 optional parameters, no output schema, no annotations), the description is remarkably complete. It explains the core behavior, matches, and exclusions, leaving no significant gaps for an agent to understand when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds value by clarifying the matching behavior (ignoring identifiers/literals) which helps parameter understanding (e.g., what 'file' scope means). However, it does not elaborate on the parameter semantics beyond what the schema provides, so a 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does ('Detect duplicate code blocks') and specifies the method ('comparing AST structure fingerprints'). It also distinguishes what matches are found (exact structural duplicates ignoring identifiers/literals) and what is not (near-misses with extra statement), leaving no ambiguity about 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear guidance on when to use this tool for finding exact structural duplicates, and explicitly states that near-misses with extra statements are not found. However, it does not mention when to use alternatives from the sibling list (e.g., 'calculate_metrics' or 'get_references') which could provide complementary duplication analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jgauffin/ts-language-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server