Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries the full burden. It discloses zero-based coordinates (important) and indicates output is guard clauses inserted at method start. Could mention if existing checks are overwritten, but overall adequate for a simple insertion tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise at three sentences, structured with USAGE, OUTPUT, IMPORTANT. Every sentence serves a purpose without wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks explanation of return value (no output schema). Ambiguous about 'nullable parameters' vs 'reference type parameters'. Missing details on handling parameters with existing checks. For a simple tool, mostly adequate but could be expanded.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and already describes parameters as zero-based. The description restates the zero-base hint but adds no new meaning for filePath or preview. Default baseline score of 3 applies because schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool adds ArgumentNullException.ThrowIfNull guard clauses for nullable parameters. It includes usage instructions and distinguishes from sibling tools that perform other refactorings like change_signature or extract_method.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is clearly described: 'Position cursor on a method with reference type parameters.' It does not explicitly mention when not to use, but the context is sufficient for an AI agent. No sibling tool performs the same function, so alternatives are not needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It discloses zero-based coordinates, output structure (list of impacted locations, safety, issues), and the purpose. It does not explicitly state it is non-destructive, but 'analyze' implies read-only. Sufficient for agent understanding.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences plus a usage line, front-loaded with purpose. Every sentence adds value, no fluff. The important note about zero-based coordinates is prominent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Describes output adequately given no output schema. Could mention prerequisites like symbol existence or error handling. Otherwise, it provides sufficient context for a moderately complex analysis tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds emphasis on zero-based coordinates and enumerates changeType options, but these are already in the schema. Marginal added value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it analyzes what would break if a symbol is changed, using a specific verb and resource. It distinguishes from sibling tools like rename_symbol or change_signature that actually perform changes, by emphasizing analysis before making changes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when considering a change to identify breaking changes, but does not explicitly state when not to use it or name alternative tools for performing the actual change. Provides a clear usage pattern with parameter examples.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It only states it returns specific fields but does not disclose potential side effects, prerequisites (e.g., code must be compilable), or 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short, front-loaded with purpose, lists returns, and provides an example. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description lists return fields. It covers purpose, parameters, and usage. However, constraints like file existence or line range validity are not mentioned, but overall adequate for a simple analysis tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the description adds a concrete usage example, clarifying how to specify line numbers. This goes beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it analyzes branching and reachability, and lists return fields. This distinguishes it from siblings like analyze_data_flow which focuses on data flow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

An example usage is provided but no explicit guidance on when to use vs alternatives like analyze_data_flow or analyze_method. The context is implied but not fully directive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It lists return values, indicating a read-only analysis, but does not explicitly state that it does not modify code or require special permissions. This is adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise: two sentences plus a usage example. The purpose is front-loaded. Every part earns its place without unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description must explain return values. It lists names like 'variablesDeclared' and 'dataFlowsIn/Out' but does not describe their semantics or structure, leaving ambiguity. More detail is needed for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description does not need to add much. The usage example illustrates syntax but does not provide additional semantic meaning beyond the schema. Baselines at 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it analyzes variable assignments and usage, and lists specific return fields. It differentiates from siblings by focusing on data flow as opposed to control flow or change impact, though not explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

A usage example is provided, but there is no guidance on when to use this tool versus alternatives like analyze_control_flow. An explicit when-to-use or when-not-to-use statement is missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It discloses the output includes signature, callers, outgoing calls, and location, but does not mention that the tool is read-only, any performance implications, or the exact format of the location. It provides adequate but not comprehensive behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences plus a usage line. It front-loads the key value proposition and example, with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains what is returned (signature, callers, outgoing calls, location). For a tool with 6 parameters and no nested objects, this is largely sufficient. It could be slightly improved by mentioning return structure or error conditions, but it is already complete enough for an agent to understand.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes all parameters (100% coverage). The description adds value by showing a usage example (analyze_method('MyService', 'ProcessData')) and clarifying defaults (includeCallers=true, includeOutgoingCalls=false), which enriches understanding beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides a comprehensive method analysis including signature, callers, outgoing calls, and location in one call. This distinguishes it from sibling tools like 'find_callers' or 'get_outgoing_calls' that offer only individual aspects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a concrete usage example and indicates optional parameters, but does not explicitly state when to use this tool versus alternatives. The context implies combining multiple analyses, but lacks 'when to use' or 'when not to use' guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses zero-based coordinates and preview mode behavior but omits details on safety (e.g., is the change reversible, permissions required). The added value is moderate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is well-structured with clear sections (USAGE, OUTPUT, WORKFLOW, IMPORTANT) and is concise. No unnecessary sentences, though minor reorganization could improve front-loading.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters, no output schema, and no annotations, the description covers workflow, coordinate system, preview mode, and title matching. It lacks details on error handling but is fairly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (baseline 3). The description adds context: 'Supports exact and partial matching' for title, and reinforces zero-based coordinates and preview mode usage, enhancing parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Apply a code action by its title' and mentions exact and partial matching. It does not explicitly differentiate from sibling tool apply_code_fix, but the purpose is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a multi-step workflow: call get_code_actions first, then apply with preview=true, then apply with preview=false. This gives explicit context on when and how to use the tool, though alternatives are not discussed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. Discloses listing, previewing, and applying, but omits side effects (e.g., disk writes), permissions, or error behavior. Zero-based coordinate warning is helpful.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences plus a clear workflow list. No redundancy, front-loaded with purpose. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, description omits return format (what does listing/preview return?). Could also mention error scenarios. Workflow is described but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds value: fixIndex can be omitted to list, preview defaults to true, and always preview first. Emphasizes zero-based coordinates beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States 'Apply automated code fix for a diagnostic' and outlines a multi-step workflow. Could better distinguish from siblings like roslyn:apply_code_action_by_title or roslyn:get_code_fixes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides an explicit three-step workflow: list, preview, apply. Emphasizes to always preview and uses zero-based coordinates. Does not explicitly state when not to use this tool or name alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses key behaviors: two-step preview/apply process, zero-based coordinates, and output structure (oldSignature, newSignature, call sites). It implies mutation but doesn't detail reversibility or permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (ACTIONS, WORKFLOW, OUTPUT, IMPORTANT) and is concise, using minimal sentences to convey essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains return values (oldSignature, newSignature, call sites) and the preview workflow, making it complete for a refactoring tool with a required preview step.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema: workflow for preview, zero-based coordinate requirement, and enumeration of actions (add, remove, rename, reorder) which clarifies the changes array parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool modifies a method signature and previews call site impact, listing specific actions (add, remove, rename, reorder) which differentiates it from sibling tools like rename_symbol or extract_method.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear workflow: preview first (preview=true), review changes, then apply (preview=false). However, it does not explicitly mention when not to use or compare to alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 discloses the output fields (compatible, requiresCast, conversionKind, explanation), which is useful. However, it does not mention side effects or prerequisites, but given its read-only nature, this is acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences plus a usage example and output fields. Every element is purposeful and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, the description covers the key aspects: what it does, when to use it, and what it returns. No output schema exists, but the description compensates by listing output fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both parameters having clear descriptions. The tool description does not add additional meaning beyond the schema, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Check if one type can be assigned to another.' It specifies the verb 'check' and the resource 'type compatibility,' distinguishing it from sibling tools that analyze code structure or apply refactorings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance: 'Use before generating assignments or casts.' It also includes a usage example, though it does not explicitly mention when not to use or list alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 tool is read-only ('visualize'), returns structured data or diagram syntax, and detects circular dependencies. While it could mention prerequisites like the solution must be loaded, the description provides adequate transparency for the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with purpose, then output details and use cases. Every sentence adds value with no redundancy. It is concise and well-structured for quick parsing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description is largely complete. It covers purpose, output format, and use cases. Missing prerequisites (e.g., solution must be loaded) is a minor gap, but overall sufficient for an agent to decide when to invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% coverage, so baseline is 3. The description adds value by specifying the default format ('json') and clarifying that JSON returns 'structured data', which goes beyond the schema's description. This extra detail helps an agent understand the parameter's effect.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (visualize as a graph), the resource (project dependencies), and what it provides (shows references, detects circular dependencies). It distinguishes itself from sibling tools like find_circular_dependencies which likely return a list, and get_project_structure which gives structure, not graph visualization.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description lists use cases (understand architecture, find circular dependencies, plan refactoring) which imply when to use it. However, it does not explicitly mention when not to use or compare to alternative siblings. The context is clear but lacks explicit differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It mentions conversion and output, but lacks details on whether the tool modifies the file in-place, what the return format is, or how preview mode affects behavior. The zero-based coordinate warning adds useful context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: three short sentences covering purpose, usage, output, and an important note. No unnecessary words, front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple refactoring with 4 parameters and no output schema, the description covers the core action and critical coordinate detail. However, it omits what the tool actually returns (e.g., a code action or modified code) and does not mention side effects or preview behavior, leaving minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (baseline 3). The description adds the 'ZERO-BASED coordinates' emphasis, which is not fully captured in schema descriptions, providing extra value. However, it does not explain the 'preview' parameter or other semantics beyond coordinates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Convert a field to a property with getter/setter', which is a specific verb+resource. It distinguishes from sibling tools like 'rename_symbol' or 'extract_method'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides actionable usage: 'Position cursor on a field declaration' and a critical note about zero-based coordinates. However, it does not explicitly state when not to use this tool or compare with alternatives like 'change_signature'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses zero-based coordinate requirement and describes output as generated code ready to insert. However, with no annotations, it does not explicitly state whether the tool is read-only or has side effects, leaving behavioral traits partially inferred.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: three brief sentences covering purpose, usage, output, and an important note. Each sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and 5 parameters with full schema coverage, the description adequately explains purpose, output format, coordinate system, and a use case. The optional includeMemberNames is not elaborated but schema covers it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds an example for interfaceName and reiterates zero-based coordinates, but does not significantly deepen understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool generates an interface from a class or struct, extracting public instance members. Distinguishes from siblings like extract_method or extract_variable by specifying the output type and context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit usage instructions: position on class declaration and provide interfaceName. Mentions usefulness for dependency injection and testability, giving context. Lacks explicit when-not-to-use or alternative sibling comparisons.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Mentions data flow analysis and zero-based coordinates, but does not disclose that the tool modifies files, requires a loaded solution, or any potential side effects. The output fields are mentioned but not detailed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Five sentences covering purpose, usage, output, workflow, and a crucial note. Well-structured and front-loaded. Could be slightly condensed but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema provided, but description covers key output fields (extractedCode, replacementCode). Missing prerequisites (e.g., solution loaded) and error conditions. Sufficient for basic usage but not exhaustive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. Description adds value by clarifying that startLine/endLine must contain complete statements, preview flag defaults to true, and coordinates are zero-based. This goes beyond schema field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the verb 'extract' and the resource 'selected statements into a new method'. It distinguishes itself from siblings like 'extract_variable' by specifying data flow analysis for parameters and return type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit usage requirements ('Specify startLine/endLine range containing complete statements inside a method') and a two-step workflow ('Preview then Apply'). Does not explicitly contrast with alternative tools or state when not to use, but the workflow is helpful.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears full responsibility. It discloses a critical behavioral trait: 'Uses ZERO-BASED coordinates (editor line - 1).' This prevents coordinate errors. No mention of side effects, but for extraction, safety is implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (three sentences) and front-loaded with the action. It includes an 'OUTPUT' line and a crucial note. Each sentence serves a purpose, but the 'OUTPUT' line could be more specific about return value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description only says 'Expression extracted to a new local variable,' lacking details on what the tool returns (e.g., success message, diff, or code action). With 6 parameters and no return info, completeness is adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds minimal parameter meaning beyond the schema. It implies the 'line' and 'column' relate to cursor position, but no extra detail on optional parameters like 'preview'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Extract an expression to a local variable', which is a specific verb and resource. Among siblings, it distinguishes itself from 'extract_method' and 'inline_variable', 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance: 'Position cursor on or select an expression.' This tells the agent when and how to invoke the tool, though it lacks explicit when-not-to-use or alternative suggestions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses output details: list of symbols, kind, arguments, source location. No mention of side effects, but appropriate for a read-only search tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise, well-structured with usage examples and output description. Every sentence provides value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 3 params, no output schema, and no annotations, description covers purpose, usage, and output adequately. Could be more detailed on output format but sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. Description adds usage examples demonstrating how to use parameters, which adds value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it finds all types and members decorated with a specific attribute. Examples and use cases make purpose unambiguous and distinct from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit use cases like finding API endpoints, authorization points, etc. Lacks explicit when-not-to-use or alternative tools, but context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 zero-based coordinates but does not disclose read-only nature, authentication, or performance characteristics, which are important 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences plus an important note; front-loaded with purpose and no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains purpose and usage well but lacks details on return format or truncation behavior beyond maxResults hint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and each parameter has descriptions. The description adds critical context about zero-based coordinates for line and column, adding value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Find all methods/properties that call or reference a specific symbol' and explicitly distinguishes it as the inverse of find_references, providing a specific verb and resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear use case ('impact analysis') and differentiates from find_references, but does not explicitly state when not to use or list alternative sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description mentions output format but does not explicitly state it's read-only or disclose any side effects. Behavioral transparency is adequate for a simple detection tool but could be improved.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise: main purpose, two usage lines, output and use case. No unnecessary words. Information is front-loaded and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and lack of output schema, the description covers what the tool does, how to use it, and what to expect. Could mention read-only nature or behavior when no cycles found, but generally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the only parameter 'level'. Description adds usage context beyond schema, showing examples for both values and clarifying default behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it detects cycles in dependency graphs. Distinguishes from sibling roslyn:dependency_graph by focusing on cycle detection. Uses specific verb 'detect' and resource 'cycles in project or namespace dependency graphs'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides two explicit usage patterns (default and with level parameter) and states use case (architecture analysis). Does not mention when not to use or alternatives, but guidance is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description adds an important behavioral note about zero-based coordinates, but lacks details on search scope, performance, or handling of no results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two focused sentences with no fluff; the critical coordinate warning is highlighted with IMPORTANT.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks a description of return format beyond 'types with locations' and no comparison to similar sibling tools, but given the tool's simplicity and no output schema, it is nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description need not add much; it reiterates the zero-based coordinate note already in the schema, adding marginal value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it finds implementations of interfaces or abstract classes and returns types with locations, which distinguishes it from siblings like get_derived_types or find_references.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives (e.g., find_references, get_derived_types) or when not to use it. The description only states the basic function.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses the important behavioral trait of zero-based coordinates and states the return format (file paths, line numbers, code context). With no annotations provided, it carries the full burden and does so adequately, though it could mention further behavioral aspects like performance expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences and a bolded important note. Every part adds value without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the moderate complexity and lack of output schema, the description covers purpose, coordinate system, and return content. It could be more explicit about response structure, but overall it is complete enough for agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, providing a baseline of 3. The description adds extra context by emphasizing zero-based coordinates for line and column, and elaborates on the maxResults parameter with default and truncation behavior, going beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool finds all references to a symbol across the entire solution, specifying the verb, resource, and scope. This distinguishes it from siblings like roslyn:find_callers and roslyn:find_implementations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description lacks guidance on when to use this tool versus alternatives such as find_callers or find_implementations. It does not mention when not to use it or provide context for choosing it over siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 describes the tool as a detector/reader of reflection usage, outputting a list of calls. It does not mention side effects, destructiveness, or permissions. While likely a safe read, the lack of explicit non-destructive statement and absence of any behavioral nuance (e.g., rate limits) keeps this adequate but not exceptional.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise yet complete. It front-loads the core action, then provides usage examples, output description, and use cases in a well-structured format. Every sentence earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, usage, and output format despite lacking an output schema. It gives clear use cases. However, it omits potential limitations (e.g., can it detect all reflection? performance implications?) and does not specify error conditions. Still, it provides sufficient context for a simple analysis tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with both parameters having descriptions ('Filter to specific project', 'Maximum results (default: 100)'). The description provides usage examples showing both parameters but does not add 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it 'Detect dynamic/reflection-based type and method usage that is invisible to static reference searches', which is a specific verb+resource. It differentiates itself from static search tools like find_references. Usage examples and output format further clarify its purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a 'Use for:' section listing contexts like refactoring, security audits, and understanding dynamic behavior. It implies it is complementary to static searches but does not explicitly name sibling tools or state when not to use it. Still, the guidance is clear and context-rich.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Given no annotations, the description covers key behavioral traits: it returns symbols with zero references excluding declarations, includes a default limit of 50 results, and lists output fields (location, kind, accessibility). It does not mention performance implications but is otherwise transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: two sentences plus a usage line and output description. No filler, front-loaded with the core purpose. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 5 parameters, no output schema, and no annotations, the description provides adequate context: what it does, how to use it, and what it returns. It could mention handling of large results or edge cases, but is generally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds value by demonstrating the projectName parameter usage and noting the default maxResults, but does not elaborate on other parameters like includePrivate or symbolKindFilter beyond their schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly defines the tool's purpose: finding unused types, methods, properties, and fields in a project or solution. It specifies the scope (entire solution or specific project) and differentiates from sibling tools like find_references and find_callers by focusing on zero references.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit usage examples with and without a project name, guiding the agent on invocation. While it doesn't explicitly state when not to use it or compare to alternatives, the examples and context are sufficient for typical scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must disclose behavioral traits fully. It mentions preview mode and that it applies changes when preview=false, but omits critical details such as side effects on files, required permissions, error handling, or what happens when preview mode returns (e.g., no mention of diff output). This leaves agents underinformed about a mutation operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences and a clear notice about preview mode. Every sentence adds value, with no unnecessary words. It is well-structured and front-loads the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and the tool's batch mutation nature, the description should clarify return behavior (e.g., what preview mode returns) and scope (e.g., works on whole solution vs open documents). It mentions project filtering via parameter but not error conditions or performance implications. Adequate but incomplete for an agent to fully trust the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters have schema descriptions, so baseline is 3. The description does not add any additional meaning beyond the schema; it merely restates the preview constraint already in the parameter description. Schema coverage is 100%, so no extra value from description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool formats multiple documents using Roslyn's NormalizeWhitespace, focusing on indentation, spacing, and line breaks. However, it does not explicitly differentiate from sibling tools like organize_usings_batch which also modify whitespace, though the specific mention of NormalizeWhitespace helps narrow the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for whitespace formatting but provides no guidance on when to choose this tool over alternatives like organize_usings_batch or validate_code. The preview mode warning offers some usage context, but lacks explicit when-to-use/when-not-to-use criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, but description adds key behavioral info: output format and zero-based coordinate system. Could mention side effects or permissions, but adequate for a code generator.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise three-part structure with clear 'USAGE', 'OUTPUT', 'IMPORTANT' sections. No redundancy, but could be slightly more scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, usage, output, and coordinate system for all 5 parameters. Lacks error handling details but sufficient for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all 5 parameters. Description adds context for includeProperties and notes zero-based coordinates, adding value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it generates a constructor from fields/properties, with specific action and resource. Differentiates from sibling generation tools like 'generate_equality_members'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit usage: position on class/struct declaration and use includeProperties for auto-properties. Lacks exclusions or alternatives but sufficient for intended use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description discloses the key behavioral detail of zero-based coordinates. It notes the output compares all instance fields and properties. However, it does not mention any side effects (e.g., file modification) or the behavior of preview mode.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise, using short sentences and clear sections (USAGE, OUTPUT, IMPORTANT). Every sentence adds necessary information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of 5 parameters and no output schema, the description adequately covers the purpose, usage coordinates, and generated output. It could mention error conditions (e.g., if not on a type declaration) but is otherwise complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are documented. The description adds clarifying context about zero-based coordinates for line and column, which is crucial for correct invocation. This adds value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates equality members (Equals, GetHashCode, ==/!=) for a type. The verb 'Generate' and resource 'equality members' are specific. While it doesn't explicitly differentiate from sibling tools like generate_constructor, the purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises positioning the cursor on a class or struct declaration and uses zero-based coordinates. It implies the context for use but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description lacks behavioral context such as impact on solution, required permissions, or rate limits. It does not disclose any traits beyond the basic operation described in the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: a single purpose sentence followed by four succinct usage examples. Every sentence adds value, and the most critical information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple query tool with complete parameter schema, the description provides adequate context through examples. However, it lacks information about return structure, pagination, or error handling, which would be valuable for a comprehensive understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already describes each parameter. The description adds example values (e.g., 'project:MyProject') which clarify the expected format for the 'scope' parameter, but does not provide additional semantic depth beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool finds symbols with specific attributes, and provides concrete examples (e.g., 'Obsolete', 'Serializable'). It is a specific verb-resource combination, but does not explicitly differentiate from the sibling 'find_attribute_usages', which may serve a similar purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through examples showing different scopes (solution, project, file) and attribute names. However, there is no explicit guidance on when to use this tool over alternatives like 'find_attribute_usages' or conditions 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description alone should disclose behavioral traits. It only says 'Get full inheritance chain' with a basic example, lacking details on edge cases, included types (e.g., interfaces), error behavior, or return format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two clear lines, front-loading the purpose. Every element earns its place with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description is adequate but leaves gaps: no mention of return format (example implies a string chain), handling of missing type, or whether interfaces are included. It covers the core function but not exhaustively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the parameter 'typeName' has a generic description. The description adds little beyond confirming the parameter's role; it does not clarify format (e.g., full namespace) or provide constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'full inheritance chain BY NAME', which is specific and distinguishes it from sibling tools like get_derived_types. The usage example reinforces this.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage via the example but does not explicitly state when to use this tool versus alternatives like get_type_hierarchy, nor does it provide when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full burden. It discloses the zero-based coordinate behavior and that it returns all actions. However, it does not state whether the operation is read-only, has side effects, or requires specific permissions. Given the lack of annotations, more behavioral detail would be beneficial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections (USAGE, OUTPUT, WORKFLOW, IMPORTANT) and is front-loaded with the purpose. It is concise but retains necessary details. Minor improvement: could be slightly more compact without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately describes the return format (title, kind, equivalenceKey). It covers all 7 parameters implicitly through usage patterns and schema coverage. It mentions the 100+ refactorings for context. Could mention error handling or pagination, but overall sufficient for an agent to use effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds a usage pattern but does not provide additional meaning beyond what the schema already offers (e.g., zero-based coordinates are already in schema). It does not elaborate on the boolean flags or the optional selection parameters beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get'), resource ('ALL available code actions'), and scope ('at a position'). It distinguishes itself from siblings like 'apply_code_action_by_title' and 'get_code_fixes' by positioning itself as the master tool that returns both fixes and refactorings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage patterns (filePath, line, column) and a workflow: call this first, then use apply_code_action_by_title. It also highlights the zero-based coordinate requirement. However, it doesn't explicitly distinguish when to use 'get_code_fixes' instead, though it is implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must cover behavioral traits. It only states the return type (list of fix titles and descriptions) but does not mention that it is a read-only operation, any side effects, error conditions, or prerequisites (e.g., solution must be loaded). This is insufficient for a tool with no annotation support.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise: two sentences plus a numbered workflow list. It front-loads the purpose and uses structured steps. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the basic purpose and workflow but lacks details on edge cases (e.g., no fixes available, invalid parameters). Since there is no output schema, the return format is only superficially described. Adequate for a simple tool but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with each parameter described in the schema. The description adds no extra meaning beyond the schema. Baseline is 3, and there is no additional value, so score remains 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets available code fixes for a specific diagnostic and returns a list of fix titles and descriptions. It distinguishes itself from siblings like apply_code_fix (which applies a fix) and get_diagnostics (which finds issues) through the explicit workflow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear workflow: use get_diagnostics first, then get_code_fixes to see options, then apply_code_fix. This tells the agent when to use this tool in the sequence, though it doesn't explicitly state when not to use it or exclude alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that coordinates are zero-based and describes the output as per-method breakdown. It does not mention performance or limitations, but the key behavioral aspects are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise and well-structured: purpose, metrics list, usage, output, important note. Every sentence adds value and there is no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given high schema coverage and no output schema, the description provides essential context: usage patterns, zero-based coordinates, and output format (per-method breakdown). It is fully adequate for agent usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds value by explaining how to differentiate file-level vs method-level use and listing the metrics. This goes beyond the schema descriptions which only provide types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves complexity metrics for a method or entire file, lists the available metrics, and distinguishes between file-level and method-level usage. This is specific and unique among sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage patterns: 'get_complexity_metrics(filePath) for file, or add line/column for specific method'. It also notes zero-based coordinates. However, it does not explicitly mention when not to use or compare to alternatives, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It correctly discloses the zero-based coordinate requirement, but does not mention other behavioral traits like read-only nature, performance, or error handling. The disclosure is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: two sentences plus an important note. It is front-loaded with the core purpose and immediately provides critical coordinate information. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, but the description specifies the expected return fields (name, kind, signature). For a simple query tool with three descriptive parameters and a clear return description, the context is sufficient for safe and correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds value by emphasizing the zero-based coordinate system, which is critical for correct usage. This goes beyond the schema's description and reduces ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'containing member at a position', and specifies the return values (name, kind, signature). It distinguishes from sibling tools by focusing on the enclosing symbol rather than other code analysis tasks, though not explicitly comparing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like get_symbol_info or get_method_signature. The description just says 'useful for understanding context', which is vague and does not help the agent decide when to choose it over siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It reveals that the tool returns all types inheriting by name, with transitive inclusion by default (controlled by includeTransitive). However, it lacks details on error behavior, performance implications, or handling of edge cases like non-existent base types. The transparency is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: a one-line purpose followed by a USAGE section with two examples. No superfluous words. The structure front-loads the key action and then provides immediate, practical examples. Every sentence is earned.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (find derived types by name), the description covers the essential behavior and usage. It mentions the key parameter includeTransitive with default. However, it omits any mention of the maxResults parameter or what happens if no types are found. With no output schema, a brief note on return format would improve completeness, but it remains largely adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, so baseline is 3. The description adds value by showing usage examples: e.g., includeTransitive=false to get direct children only, clarifying the default behavior (true). This goes beyond the schema's brief descriptions, particularly for includeTransitive, and provides context for usage. maxResults is not mentioned, but the schema covers it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Find all types inheriting from a base type BY NAME.' It specifies the verb (Find) and resource (types inheriting from a base type), differentiating itself from siblings like get_base_types which do the reverse. The purpose is unambiguous and distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The USAGE section provides concrete examples showing how to call the tool with and without the includeTransitive parameter. This gives practical guidance on parameter use. However, it does not explicitly compare with sibling tools like get_type_hierarchy or specify when to choose this tool over alternatives, which would elevate the score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavioral traits. It states the tool returns a list of diagnostics with details, but does not disclose potential side effects, prerequisites (e.g., loaded solution), or whether it triggers compilation. The 'use before committing' hint suggests a read-only check, but this is not explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: the first covers purpose and return format, the second gives usage guidance. No unnecessary words, and the core information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and four optional parameters, the description is fairly complete. It explains what is returned and when to use it. However, it does not address cases like overlapping parameters or what happens if no diagnostics are found. Still adequate for most use cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the description itself does not add significant meaning beyond what the parameters already convey. The main description does not elaborate on parameter usage; it relies on the schema, making a baseline score of 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves compiler diagnostics (errors, warnings, info) for a file or project. It distinguishes from sibling tools like analyze_control_flow or analyze_data_flow, which are more specific analyses.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises using the tool 'before committing to catch issues,' providing a clear usage context. It does not explicitly say when not to use it or mention alternatives, but the context of sibling tools implies alternatives for more targeted analysis.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description details the output (list with lifetime, service type, etc.) and implies a read-only scan. It lacks explicit side-effect disclosure but is adequately transparent for a scanning tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with usage examples and output details. It is concise yet informative, though the USAGE lines could be integrated into prose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains what the tool returns. It covers purpose, usage, output, and use cases, making it complete for a tool with one optional parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description shows usage with projectName but does not add significant meaning beyond the schema's 'Filter to specific project'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it scans for DI service registrations with specific examples (AddScoped, AddTransient, etc.). This differentiates it from sibling tools that focus on other code analysis tasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit usage examples and lists use cases (understanding service wiring, finding missing registrations, auditing lifetimes). Does not mention when to avoid using it or alternatives, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears the transparency burden. It discloses that the tool returns diagnostics, types, namespace, and line count, indicating a read-only operation. However, it lacks details on error handling, file existence behavior, and explicit read-only confirmation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, with two sentences that front-load the purpose and provide an example. No redundant or unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema), the description adequately covers its return components. However, it could elaborate on the scope of 'type declarations' (e.g., top-level only) for full completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already fully describes the single parameter 'filePath' as 'Absolute path to source file' (100% coverage). The description's usage example does not add further semantic meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get comprehensive file overview in ONE CALL' and lists specific components (diagnostics summary, type declarations, namespace, line count). This differentiates it from siblings like get_diagnostics or get_type_overview which provide only subsets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a usage example, implying when to use the tool. However, it does not explicitly state when to prefer this over individual sibling tools, nor does it mention any prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 states the output is full source code, but does not explicitly mention that the operation is read-only or any side effects. The name 'get' implies read-only, but more transparency would be beneficial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with the purpose, and includes a usage example and output hint in a structured format. Every sentence adds value without unnecessary repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given two simple string parameters and no output schema, the description is fairly complete: it states purpose, usage, output, and prerequisite. It could mention that the generated file must exist, but that is implied. Lacking annotations, it still provides adequate context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers both parameters with descriptions (100% coverage). The description adds a usage example with parameter names, but does not enrich the meaning beyond what the schema already provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'View the source code produced by a source generator.' It includes a usage example with concrete parameter values and specifies the output is full source code. This distinguishes it from sibling tools like get_source_generators.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises to 'Use get_source_generators first to discover available generated files,' providing clear guidance on the prerequisite workflow. It doesn't list when not to use this tool, but the sibling differentiation is helpful.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full behavioral burden. It discloses that the tool returns constructors, factory methods, builder patterns, and hints (e.g., IDisposable). It also shows output format. However, it does not mention side effects, required permissions, or edge cases like static classes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, with two sentences plus usage and output examples. Every part adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description adequately outlines the output content (constructors, factory methods, hints). It could be more complete by noting limitations (e.g., types without public constructors) but is sufficient for an agent to understand the tool's value.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The parameter 'typeName' is already described in the schema (100% coverage). The description adds a usage example but no new semantic constraints or 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool retrieves all ways to create an instance of a type, listing constructors, factory methods, and builder patterns. It uses a specific verb 'get' and a unique resource 'instantiation_options', distinguishing it from sibling tools like 'get_method_signature' or 'get_method_overloads'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a concrete usage example (typeName='HttpClient'), showing how to call the tool. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites or limitations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the basic operation, it notes the important behavioral detail that coordinates are zero-based. Without annotations, this disclosure adds value. Does not cover safety or permissions, but the read-only nature is implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences: purpose, return value, usage hint with critical coordinate warning. No unnecessary words, front-loaded information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Fully describes what the tool does, what it returns, and key usage details. For a simple tool with no output schema, this is complete and sufficient for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and descriptions are already explicit (e.g., 'Zero-based line number'). The description reiterates the zero-based constraint but adds no new semantic meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it retrieves all overloads of a method and returns signatures with parameter details. Differentiates from siblings like get_method_signature by focusing on overloads, and includes usage context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states 'Use when you need to choose between overloads', providing a clear context for use. Does not include when-not or alternatives, but the positive use case is well defined.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided. The description mentions output contents but does not disclose behavior for missing methods, invalid overload indices, or other edge cases. Minimal behavioral context beyond the tool's basic function.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: the first defines the output, the second shows usage. Extremely concise, front-loaded, and no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple retrieval tool with 3 parameters and no output schema. The description explains what is returned, but lacks details on output structure or error handling, which could be helpful given the complexity of method signatures.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%. The description adds value by providing a concrete usage example that illustrates parameter ordering and the optional overloadIndex, aiding the agent beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it gets a detailed method signature by name, including parameters, return type, nullability, and modifiers. This distinguishes it from siblings like get_method_source or get_method_overloads, though it does not explicitly highlight differences.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a usage example but offers no guidance on when to use this tool versus alternatives such as get_method_source or change_signature. There is no explicit context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 it returns source code and eliminates file reads, but lacks details on error handling or performance implications. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences plus a usage example. Efficiently front-loads the purpose and provides essential context without extraneous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description compensates by detailing the return content (signature, body, location, line count). It covers key aspects for a read-only retrieval tool, though error scenarios are not mentioned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by showing a usage example with parameters and describing the output (signature, body, location, line count), helping the agent understand what each parameter leads to.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets the actual source code of a method by type and method name. It provides a usage example and distinguishes from siblings like get_method_signature.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says 'Eliminates need for file Read,' implying a direct source retrieval alternative. However, it does not explicitly compare to sibling tools or state 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description carries full burden. Discloses output format (Results array with source, errors array) and optimization benefit. However, does not mention read-only nature, auth needs, rate limits, or side effects. Adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: uses sections for USAGE and BENEFIT, provides a clear example. No wasted words; every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given simple 2-param tool with no output schema and no annotations, description covers input format, output structure, and usage benefit. Lacks error handling details but sufficient for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description adds a concrete example for 'methods' but does not clarify 'maxMethods' beyond repeating schema default. Marginal added value over schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Get source code for multiple methods in a single call (batch optimization).' The verb 'Get' and resource 'source code for multiple methods' are specific, and the batch nature distinguishes it from siblings like get_method_source.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a USAGE example and mentions BENEFIT ('One call instead of multiple - reduces round trips when tracing code flows.'). Implies when to use it, but does not explicitly state when not to or compare to alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 coordinates are zero-based, which is critical for invocation. However, it does not mention side effects (though unlikely) or handling of invalid inputs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, using clear headings (USAGE, OUTPUT, IMPORTANT) and front-loading the purpose. Every sentence adds unique value with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains the output format ('List of missing members with exact signatures ready to copy'), which is helpful. It does not cover error cases, but it is adequately complete for a simple, read-only tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes all 3 parameters with 100% coverage. The description adds valuable context by emphasizing zero-based coordinates and that line and column refer to the type declaration, enhancing understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get all interface and abstract members that must be implemented for a type.' This distinguishes it from sibling tools like roslyn:implement_missing_members, which actually implements them, and roslyn:get_base_types, which retrieves base types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes 'USAGE: Position on a class that implements interfaces or extends abstract classes.' and 'Use before implementing interfaces,' providing clear context. It lacks explicit alternatives or when-not-to-use, but the guidance is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries the full burden. It describes the output (list of projects with packages, versions, asset settings) and implies it is a read-only query. For a simple listing tool, this is adequate behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, with the main action stated first, followed by succinct usage examples and output description. Every sentence is functional and avoids redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (single optional parameter, no output schema), the description covers the essential aspects: what it does, how to call it, and what the response contains. It does not discuss error handling or limitations, but the context is sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with the 'projectName' parameter already described as 'Filter to specific project'. The description adds usage examples that demonstrate how to use the parameter, but does not add significant new 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists NuGet package references per project with versions. This is a specific verb-resource pairing that distinguishes it from sibling tools like 'find_circular_dependencies' or 'dependency_graph' which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides two usage examples (with and without the optional parameter) and lists explicit use cases: dependency audits, version checks, understanding external dependencies. It does not mention when not to use or alternatives, but the examples sufficiently guide an agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that coordinates are zero-based (a critical behavioral detail), and that it returns a list of called symbols with locations. Despite no annotations, this provides good transparency, though it omits specifics like handling of async methods or lambdas.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, with two sentences and a critical note. Every sentence adds value: the first explains the tool's purpose, the second adds context about return values, and the note warns about coordinate systems.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately explains that the tool returns a list of called symbols with locations and warns about zero-based coordinates. However, it could benefit from specifying the structure of each returned symbol (e.g., name, kind, exact position).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully documents all 4 parameters (100% coverage). The description adds no additional meaning beyond the schema, such as clarifying how the coordinates relate to the method's body or how maxDepth affects results.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves methods and properties called by a method, using specific verbs ('Get all methods and properties that a method calls'). It distinguishes from siblings like find_callers (which finds callers) and dependency_graph (broader scope), by focusing on outgoing calls from a specific method.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for understanding method dependencies but does not explicitly state when to use this tool versus alternatives like find_callers or dependency_graph. No when-not-to-use or exclusion criteria are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 25,000-token output limit, default parameter values, and per-project limits for references (100) and documents (500). This is strong behavioral context, though it could explicitly state the tool is read-only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first states the purpose, the second gives a critical usage warning. Every word adds value; no fluff. It is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description covers input constraints (token limits, defaults) and performance tips. It lacks details about the output structure (e.g., whether it returns a hierarchical JSON), but the summaryOnly hint partially addresses this. Overall, it is sufficiently complete for a parameterized query tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds significant value beyond the schema by revealing default behaviors (e.g., 'includeReferences' defaults to true) and practical constraints (e.g., 'includeDocuments' limited to 500 per project). This aids the agent in parameter selection.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get solution/project structure' is a clear verb+resource pair that distinguishes this tool from siblings like 'get_file_overview' or 'get_type_hierarchy' by focusing on top-level structure.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises using 'summaryOnly=true' or 'projectNamePattern' for large solutions to avoid token limit errors, providing practical when-to-use guidance. However, it does not mention when NOT to use this tool (e.g., preferring a more specific sibling).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 states the output format but does not mention prerequisites (e.g., solution must be loaded) or performance implications. For a read-only listing tool, this is adequate but could be more transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a front-loaded main statement, followed by clear usage examples and output description. No superfluous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with one optional parameter and no output schema, the description covers purpose, usage, and output. It lacks mention of preconditions like solution loading, but given common context among roslyn tools, it is mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds a usage example with a concrete string value and reinforces that the parameter filters per project, adding value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'list' and the resource 'active source generators and their generated output per project'. It distinguishes from the sibling tool 'get_generated_code' which likely returns specific code, while this lists generators and their output.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides usage examples with and without parameters, and states the use case ('understanding generated code, debugging generator issues'). However, it does not explicitly mention when NOT to use this tool or suggest alternatives like 'get_generated_code'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It lists returned information (kind, type, namespace, documentation, location) but does not disclose side effects, permissions, or performance traits. Mediocre transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence plus an important warning and output summary. Front-loaded with purpose. Efficient but could be more structured with bullet points or sections.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, so description compensates by listing return fields. It explains coordinate convention but omits error conditions or prerequisites. Adequate for a simple info tool but not fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema already describes each parameter (100% coverage). Description adds value by clarifying the zero-based coordinate conversion, reinforcing practical usage beyond schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the verb 'Get' and the resource 'detailed semantic information about a symbol at a specific position'. It lacks explicit distinction from other info-retrieval sibling tools like 'get_type_overview', but the purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides critical usage guidance on zero-based coordinates with a concrete example. Does not explicitly state when to use this tool over alternatives, but the context of needing detailed symbol info at a position is implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description partially covers behavioral traits: it mentions the return format (baseTypes chain, derivedTypes list) and notes that results are truncated with a hint if the maxDerivedTypes limit is exceeded. However, it does not disclose whether the tool is read-only, performance implications, or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at two sentences plus a bolded note. It front-loads the purpose and provides critical context efficiently without wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema, the description briefly describes the return values but omits details about error cases (e.g., type not found, invalid file) and performance considerations. It is adequate but not fully complete for a tool with 4 parameters and no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds value by emphasizing the zero-based coordinate requirement and explaining the truncation behavior for maxDerivedTypes. This goes beyond the schema's basic descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get the inheritance hierarchy (base types and derived types) for a type.' It uses a specific verb and resource, and distinguishes from siblings like get_base_types and get_derived_types by combining both.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description lacks guidance on when to use this tool versus alternatives like get_base_types or get_derived_types. It does not specify prerequisites or exclusion criteria, only mentioning the zero-based coordinate requirement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It describes the operation as reading members and mentions verbosity control, but lacks details on constraints (e.g., ambiguous names, performance, error handling) and assumes a read-only behavior without explicit statement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a clear first-line purpose, followed by well-organized usage patterns and a note on name forms. Every sentence adds value without fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of an output schema, the description covers usage patterns and parameter behavior well, but does not explain the return structure or clarify that maxResults limits output, which could be confusing when stating 'Get all members'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds value by explaining name forms (fully-qualified, simple, partial) and illustrating verbosity levels with examples, which goes beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get all members (methods, properties, fields, events) of a type BY NAME.' This distinguishes it from siblings like get_type_members_batch and get_method_signature, providing a specific verb+resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage patterns are given (basic, with inheritance, filter by kind, verbosity control) and the tool works with fully-qualified, simple, or partial names. However, it doesn't explicitly state when not to use or mention alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It mentions output format (results/error) and benefit, but does not disclose read-only nature, rate limits, or other behavioral traits beyond what is implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: a single sentence followed by a code block and bullet points. Every element adds value, with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers batch optimization aspect well, but lacks detail on the return structure (e.g., format of members). However, given 5 parameters and no output schema, the description is largely complete for its niche.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with 5 parameters fully described. The description adds a usage example but no additional parameter meaning beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it 'gets members for multiple types in a single call', with a specific verb and resource. It distinguishes itself from the singular sibling 'get_type_members' by highlighting the batch optimization.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a usage example and explicitly mentions the benefit of reducing context usage, giving agents clear context for when to use this batch variant over the single-type alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It discloses that the tool returns 'type info, base types (first 3), and member counts' but does not elaborate on what 'type info' includes (e.g., namespace, visibility, location). It also does not mention any side effects (none expected) or authentication requirements. Adequate but lacks detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences total, with the key information front-loaded. The example is embedded in a code block. No fluff or unnecessary details. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 parameter, no output schema, no annotations), the description provides a reasonable summary of outputs: type info, base types (first 3), member counts. It covers the main purpose. Minor gap: not specifying if 'type info' includes namespace or modifiers, but overall complete for a quick overview tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers the single parameter 'typeName' with description 'Type name' (100% coverage). The description adds an example usage 'get_type_overview("MyService")' but no additional semantics like case sensitivity or format requirements. Baseline 3 since schema already defines the parameter well.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the purpose: 'Get comprehensive type overview in ONE CALL: type info + base types (first 3) + member counts.' It clearly specifies the resource ('type overview') and the verb ('Get'). It distinguishes from siblings like get_type_hierarchy or get_base_types by combining multiple aspects in a single call. However, 'type info' is somewhat vague, missing a detailed breakdown.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an example usage: 'get_type_overview("MyService")' and implies it's for quick understanding. However, it lacks explicit guidance on when to use this tool versus more specialized siblings (e.g., get_type_hierarchy for deep hierarchy, get_type_members for members list). No when-not-to-use or alternatives mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.