roslyn-codelens-mcp
Server Quality Checklist
Latest release: v2.18.0
- Disambiguation5/5
Each of the 67 tools has a clearly distinct purpose with detailed descriptions. Overlapping areas like multiple find_ or analyze_ tools are differentiated by specific entities (callers vs. references, throw sites vs. catch blocks), leaving no ambiguity for agents.
Naming Consistency5/5All tool names follow a consistent snake_case verb_noun or verb_noun_noun pattern (e.g., find_references, get_type_overview, rebuild_solution). No mixing of conventions (e.g., camelCase) ensures predictable naming.
Tool Count1/5With 67 tools, the server far exceeds the recommended well-scoped range of 3-15. While each tool serves a specific analysis purpose, the sheer number overwhelms the surface and suggests feature bloat rather than focused functionality.
Completeness4/5The tool surface covers nearly all common code analysis tasks: search, navigation, refactoring, diagnostics, dependency analysis, test coverage, and more. Minor gaps exist (e.g., no general text editing tool), but overall it is comprehensive for a Roslyn-based analysis server.
Average 4.2/5 across 67 of 67 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 11 of 13 community issues answered or closed in the last 6 months
- 183 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action. It does not disclose behavioral details such as whether the result is flat or grouped, if it requires a loaded solution, or if there are any side effects. This is insufficient for an agent to predict behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no superfluous words. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should explain the return format (e.g., a list of package references with project names). Without this, an agent cannot fully understand the tool's output. Also, no context about preconditions or typical usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100% and the parameter description is clear. The tool description adds no additional meaning beyond what the schema provides, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'NuGet package references for projects in the solution', which is specific and distinguishes it from sibling tools like 'get_project_dependencies'. However, it does not explicitly differentiate itself from potentially related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., solution must be loaded) or when not to use it. For a tool with many siblings, this omission reduces usability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden for behavioral disclosure. It only states basic direction of traversal, omitting details like whether the operation is read-only, performance impact, error handling for missing types, or recursion depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with parenthetical clarifications that add precision. Every word is necessary; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations. The description does not specify return format, behavior when type is not found, or whether the hierarchy includes indirect ancestry. For a traversal tool, more context is needed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'symbol', with description 'Type name (simple or fully qualified)'. The tool's description adds no additional semantic 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Walk' and clearly identifies the resource as type hierarchy, covering both upward (base classes, interfaces) and downward (derived types) traversal. This distinguishes it from sibling tools like get_type_overview or find_implementations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as find_implementations or get_type_overview. Does not mention prerequisites, limitations, or optimal context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return envelope structure (items, totalCount, truncated, limit) and sorting behavior (by project then file path). Since no annotations are provided, the description bears full responsibility for transparency. It implies read-only access via 'inspect', but does not explicitly confirm lack of side effects, which 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the core purpose and immediately follow with key response details. Every word earns its place with no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and 3 simple parameters, the description partially compensates by explaining the envelope fields (totalCount, truncated, limit) and sort order. However, it omits the structure of the 'items' themselves (e.g., whether they include code snippets, file paths, sizes), which is crucial for an agent to handle responses correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters documented). The description adds the default limit of 200 and restates sorting behavior already present in the schema. This provides marginal extra value, meeting the baseline for adequate parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('inspect') and resource ('generated source code from source generators'). It distinguishes from siblings like 'get_source_generators' by focusing on the generated code rather than the generators themselves. However, it does not explicitly clarify whether the returned 'items' contain the full source code or just metadata, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternative tools (e.g., 'peek_il', 'get_source_generators', or 'get_method_source'). It does not mention prerequisites, exclusions, or typical scenarios, making it harder for an agent to select the appropriate tool among many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. Though it implies a read-only analysis, it does not explicitly state whether the tool modifies code, requires permissions, or has side effects. This lack of explicit safety information is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main purpose, and includes a concrete usage hint. Every word contributes value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description enumerates the returned data (variables declared, read, written, etc.) and provides a use case. This is sufficient for a tool with only three straightforward parameters. Minor omissions: no mention of performance or error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all parameters described in the schema. The description does not add additional meaning beyond what the schema provides (e.g., explaining the 1-based line numbering or file path format). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Analyze' and the resource 'data flow within a range of statements in a C# method'. It lists specific outputs (variables declared, read, written, etc.), making the tool's purpose distinct. While it doesn't explicitly differentiate from siblings, the purpose is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Useful for understanding variable lifecycle before extracting code', which provides implicit guidance on when to use it. However, it lacks explicit alternatives, when-not-to-use scenarios, or prerequisites, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavior. It indicates a read-only dump of context, but does not mention permissions, side effects, or the structure of the output. It is adequate 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with key information. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists what the context includes (namespace, base class, etc.), which is helpful. It could be more complete by noting the format or structure, but it is sufficient for a quick dump tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter 'symbol', describing it as a type name. The description adds 'type' context but no additional semantics beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a context dump for a type, listing specific components (namespace, base class, etc.). It is specific about the resource and action, but does not distinguish it from similar sibling tools like 'get_type_overview' or 'get_public_api_surface'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Given the large number of sibling tools (e.g., 'get_type_overview', 'analyze_method'), the description lacks any usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It states 'Return', implying a read-only operation, but lacks details on side effects (none expected) or performance implications. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no redundant words. Efficient for a simple tool, but could be expanded slightly without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so the description should clarify the return format (e.g., list, tree, graph). It only says 'graph', which is vague. Among many sibling tools, more detail on the structure would aid selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'project'. The description adds no new meaning beyond the schema's 'Project name or .csproj filename'. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Return') and specifies the resource ('project reference graph') with scope ('direct and transitive dependencies'). It distinguishes from siblings like 'get_nuget_dependencies' which focus on NuGet packages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'get_nuget_dependencies' or 'get_call_graph'. The description does not mention prerequisites or 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states 'get current status', but does not disclose whether the operation is read-only, any required permissions, error responses, or behavior for invalid task IDs. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no unnecessary words. It is concise and front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description is adequate but misses opportunities to mention return format, possible statuses, or error handling. It is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The parameter 'taskId' has a schema description that explains its source, and the tool description does not add additional semantics beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get', the resource 'status of a background task', and the identifier 'taskId'. It directly distinguishes from sibling tools like 'start_background_task' and 'list_running_tasks'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after starting a task via 'start_background_task', but does not explicitly state when to use this tool versus alternatives like 'list_running_tasks'. No when-not 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It indicates a read-only analysis tool returning reachability data. It does not mention side effects, permissions, or prerequisites like a loaded solution, which are relevant for an analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise with two sentences that front-load the main action. Every sentence adds value without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no output schema), the description covers the core purpose and return data. It lacks prerequisites and error conditions, but overall provides sufficient context for an analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for all parameters. The description does not add extra meaning beyond the schema; it focuses on overall functionality. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool analyzes control flow within a C# method range and returns reachability information. Purpose is specific and avoids vagueness, though it does not explicitly differentiate from sibling tools like analyze_data_flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions usefulness for detecting unreachable code and understanding branching, giving context for when to use. However, it does not provide when-not-to-use guidance or mention alternative tools for related analyses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions return envelope fields (items, totalCount, truncated, limit) but omits important details like scope (entire solution?), read-only nature, or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first states purpose, second describes return format. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the essential information for a simple lookup tool: what it finds and what it returns. Missing details on scope (solution-wide?) but acceptable given the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. Description adds no additional parameter-specific meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'find' and specific resource 'classes/structs implementing an interface or extending a class'. Distinct from sibling tools like find_references and get_type_hierarchy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Context is implicit but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions return fields (items, totalCount, truncated, limit default 500, byKind summary) and sorting by file then line, but does not disclose side effects, permissions, or performance implications. It implicitly suggests read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys purpose, examples, and return structure. It is front-loaded with the core action and immediately useful details, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 parameters, no output schema, no annotations), the description covers purpose, return envelope, and sorting. It lacks usage guidelines and explicit behavioral transparency, but for a simple detection tool, it is largely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add meaning beyond what the input schema already provides for the two parameters (limit and symbol). The only extra is mention of default limit 500, which is already in the schema as default null but described as default 500.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects dynamic/reflection-based usage, listing specific examples like Type.GetType, Activator.CreateInstance, and MethodInfo.Invoke. It also mentions the return envelope structure, which helps differentiate it from sibling tools like find_references or find_attribute_usages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The sibling tools list many related search tools, but the description does not help the agent decide when to pick this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses default limit, sorting, and return structure (envelope with totalCount, truncated), but does not mention error conditions or side effects (e.g., what if symbol not found).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first states purpose, second describes output format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with 2 parameters and no output schema, the description covers purpose, default behavior, and return structure adequately. Minor gap: no mention of error handling or pagination for large results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description reiterates the default limit and sorting already present in the schema, and adds context about the return envelope, but does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('scan') and resource ('IServiceCollection extension methods for DI registrations'), clearly distinguishing the tool from siblings like 'find_references' or 'inspect_external_assembly'. It also details the return envelope structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., get_type_overview, find_references). Missing prerequisites, exclusions, or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return envelope with totalCount, truncated, limit, and sorting behavior. Implies read-only but does not explicitly state non-destructive nature or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: purpose then return structure. No redundant words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple list tool without output schema. Explains sorting, default limit, and envelope fields. Missing definition of 'source generators' and error handling, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters fully (100% coverage). Description repeats schema details (default limit, sorting) but adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'List' and resource 'source generators and their output per project'. Distinct from sibling tools like 'get_generated_code' by specifying per-project listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives such as 'get_generated_code'. Does not specify prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It adds one useful behavioral detail: 'Removes both session and persistent entries.' However, it does not disclose possible side effects, required permissions, or what happens if the path does not exist, limiting transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no unnecessary words. It delivers the essential information in a compact, front-loaded structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple revoke action with one parameter and no output schema, the description covers the key behavioral aspects. It could briefly address error cases or reversibility, but it is largely complete for the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'path' described as 'Absolute path of the solution or trusted root to revoke'. The description adds no further meaning beyond what the schema already provides, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the resource ('previously trusted solution path or trusted root'). It succinctly defines the tool's purpose and stands in contrast to sibling 'trust_solution', which adds trust.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, context, or appropriate situations for revocation, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals the return envelope (totalCount, truncated, limit), sorting order, and default limit. However, it does not mention any behavioral traits such as performance impact, 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each serving a distinct purpose: the first defines the tool's action, the second explains the output format. No redundant words or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return envelope and sorting, but lacks details on what happens when thresholds are not exceeded (empty results), whether results are paginated beyond limits, or how multiple thresholds interact. Given no output schema and moderate complexity, it is somewhat incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 100% of parameters with descriptions. The description adds context: it clarifies the default limit (100, despite schema default null) and the sorting behavior (worst-first). This adds value beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find' and the resource 'classes and structs', specifies the criteria (member count or line count thresholds), and describes the output sorting (worst-first) and envelope structure. This distinguishes it from sibling tools like find_god_objects which focus on different metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool vs alternatives like find_god_objects. The description only explains the tool's own behavior without mentioning exclusions or preferred use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description implies read-only by 'list' but doesn't explicitly state non-destructive nature or potential performance impacts. Adequate but 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with main purpose, then details on skipped projects and return format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with one parameter and no output schema, the description fully explains the return envelope and mentions skipped projects, covering all essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear description for the 'limit' parameter. The description adds no new syntactic or semantic info beyond the schema, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all solutions and identifies the active one, distinguishing it from sibling tools like load_solution or set_active_solution. It also mentions skipped projects and return structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool instead of alternatives. The description only states what it does without context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains per-item statuses and order preservation, adequate for a read operation. However, it does not mention safety, side effects, or any authentication requirements. Lacks explicit statement of read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is dense but efficient; every sentence adds information. While not overly long, it could benefit from bullet points for readability. Front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description covers input formats, statuses, and references to sibling tools for edge cases. Minor omission: does not state that a solution must be active/loaded, but this is likely inferred from tool context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds significant value: explains symbol patterns (simple/qualified), constructor request format, indexer syntax, and batch usage. This goes beyond the schema's generic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns full declaration source for named members, listing specific types (methods, constructors, etc.). It distinguishes from siblings implicitly by mentioning alternatives for certain statuses (e.g., get_type_overview for whole types), but does not explicitly differentiate from all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on how to request different member kinds (constructors, indexers) and batch usage. It also gives actionable alternatives for specific statuses (metadata -> peek_il or inspect_external_assembly; unsupportedKind -> get_type_overview). Missing explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return envelope fields but does not mention error states (e.g., symbol not found) or confirm read-only nature. With no annotations, the description carries full burden and is partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers output format. However, it lacks explanation for ambiguous or missing symbols, which would be helpful for a complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds no meaningful parameter info beyond schema; the sorting info is already in the limit parameter's schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'Find the source file and line where a symbol is defined.' Distinguishes from sibling tools like find_references and find_implementations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like find_references. The description is implicit but lacks when-not context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the time-window constraint (within last 5 minutes) and implicitly indicates a read-only operation. However, it does not mention auth requirements, pagination behavior, or whether the list is scoped per user.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 14-word sentence that is front-loaded with purpose and contains no extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one parameter and no output schema, the description is largely complete. It identifies the resource, the timeframe filter, and the result type (list). Minor missing context: what constitutes a 'background task' and whether any filtering beyond time is possible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the only parameter 'limit' is described in the schema). The tool description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'list' and resource 'background tasks' with a specific time filter (running or completed within the last 5 minutes). This distinguishes it from sibling tools like 'start_background_task' or 'get_task_status'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing recent tasks but does not explicitly state when to use this tool versus alternatives like 'get_task_status' for individual tasks. No when-not-to-use or prerequisite guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return envelope (items sorted by match quality, totalCount, truncated, limit, byKind) and explains the substring match is case-insensitive, but it does not mention safety aspects (e.g., read-only, permission requirements) or whether a solution must be loaded, which is important given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the purpose and return format, with no extraneous words. It could be slightly improved by splitting into two sentences for readability, but it remains concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully explains the return envelope (a strength given no output schema), but it lacks context about the search scope (e.g., across all loaded solutions, within current solution) and prerequisites, which is needed for a search tool in a multi-solution environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters (100% coverage), but the description adds value by clarifying that the limit defaults to 200 (schema says null) and that the query performs case-insensitive substring matching, providing more context than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for types, methods, properties, and fields by name with case-insensitive substring matching, and distinguishes itself from sibling tools by being a generic symbol search, not a specific reference or usage finder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests using this tool for finding symbols by name, but it provides no explicit guidance on when to use it versus alternatives like find_references or find_unused_symbols, and lacks any when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description describes the return envelope (items, totalCount, truncated, limit, byProject summary), adding transparency beyond the schema. However, with no annotations provided, it does not disclose any side effects, authentication needs, or rate limits, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose and return format without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description could be more complete. It explains the return envelope but does not detail the structure of individual items or provide context for when to use this tool over siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters. The description adds value with examples of attribute values (e.g., Obsolete, Authorize, Serializable) and clarifies that the 'Attribute' suffix is optional, which aids understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds all types and members decorated with a specific attribute, using a specific verb and resource. It includes examples of common attributes, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding attribute usages but does not explicitly compare to sibling tools like find_obsolete_usage or find_references. No when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return envelope fields (items, totalCount, truncated, limit, byProject) and mentions sorting behavior and default limit. However, it does not discuss side effects, authentication requirements, rate limits, or behavior on empty results, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences with no extraneous information. The first sentence defines the primary action, and the second lists the output envelope fields. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema), the description covers the return envelope structure adequately. It mentions all key fields but does not detail what items contain (e.g., file path, line number). The presence of many sibling tools and the lack of output schema make this a reasonable but not exhaustive description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (symbol, limit). The description adds value by clarifying the default limit (500), sorting order (by file, then line), and the allowed format for symbol ('simple or fully qualified'). This enhances the schema's documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Find every call site') and resource ('a method'), and specifies the return envelope structure. It distinguishes itself from sibling tools like 'find_references' or 'get_call_graph' by focusing specifically on call sites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. While the purpose is clear, it lacks context such as prerequisites, when to prefer 'find_callers' over 'find_references' or 'get_call_graph', or any conditions where the tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides behavioral details: returns an envelope with sorted items (by cycle length descending), totalCount, truncated, and limit. It indicates a read-only operation (detect) without destructive hints. However, it omits error behavior or performance considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first sentence states purpose, second describes output format. 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides the output structure. It covers purpose and parameters adequately for a simple tool. However, it lacks usage guidelines and prerequisites, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters have descriptions). The description reiterates the level options and limit default/sorting, adding marginal value. The output envelope description (items, totalCount, etc.) is helpful but not strictly parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects circular dependencies in two specific graphs (project reference and namespace dependency). It uses a specific verb ('Detect') and resource ('circular dependencies'), distinguishing it from sibling tools like get_project_dependencies or analyze_data_flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for detecting cycles but does not explicitly state when to use this tool versus alternatives like get_project_dependencies or get_call_graph. No exclusion criteria or context about when it is not appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It describes the return envelope and sorting, but does not disclose whether the tool is read-only, requires a loaded solution, or has side effects. This is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, followed by the return envelope. Every sentence is informative and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description adequately covers the return envelope and sorting behavior. It could mention prerequisites like requiring a loaded solution, but overall it's sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds context: items are sorted by rule then file, and the default limit is 500. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it checks .NET naming convention compliance and lists specific conventions (PascalCase, camelCase, I-prefix, _ prefix). This distinguishes it from sibling tools like 'find_async_violations' or 'find_unused_symbols'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking naming conventions but provides no explicit guidance on when to use this tool vs alternatives, or when not to use it. Among many sibling 'find' tools, this omission reduces clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full burden. It discloses framework recognition and transitive depth behavior, but does not mention side effects, prerequisites (e.g., loaded solution), or error handling for missing symbols.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. First sentence front-loads primary purpose; second adds concrete details on frameworks and transitive behavior. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description omits return value format (e.g., list of test method names with locations). However, tool is simple with 3 well-described parameters; overall complete enough for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds extra meaning: symbol format 'Type.Method', maxDepth clamping to [1,5] and default 3, transitive meaning 'walk through helper methods'. This provides clarity beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists test methods that exercise a given production symbol, and distinguishes itself from siblings like 'find_references' by specifically targeting tests. It also mentions supported frameworks and optional transitive behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (find tests for a symbol) and how to use the transitive option with maxDepth. However, it does not explicitly state when not to use it or compare to alternatives like 'find_references' or 'generate_test_skeleton'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the read-only-ish summary behavior and the special handling of .razor/.cshtml via source-generated C# documents. However, it does not explicitly state that the tool does not modify anything, nor does it mention any error or compilation-trigger side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no redundancies. The function is stated first, the use case second, and the edge case for markup files last. Every sentence contributes necessary information in a well-ordered, efficient format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return contents (types and diagnostics), the input types, and the generated-source behavior, which is sufficient for a single-parameter tool without an output schema. It could be slightly more explicit about what is returned for invalid paths, but that is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter already documents 'Full path to the source file (.cs, or .razor/.cshtml)'. The description adds a little context for markup resolution, but that is more behavioral than parameter-level detail, so the schema already carries most of the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Get a summary of a C# file' with explicit contents (types and diagnostics). This distinguishes it from related siblings like get_type_overview and get_diagnostics, so an agent can tell them apart immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a concrete use case: 'quickly understanding a file's contents without reading it.' It does not explicitly name alternatives or exclusion conditions, but the intended context is clear enough for an agent to decide when it applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so burden is on description. It discloses it works on 'referenced closed-source assemblies', implying read-only behavior on external code. However, it doesn't mention return format, potential errors, or side effects. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. Every word earns its place. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, no output schema, and no nested objects, the description is nearly complete. It explains input and purpose. An explanation of what 'ilasm-style IL' is might benefit less experienced users, but the assumed knowledge is reasonable for the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for methodSymbol. The tool description goes beyond by providing an example format ('Newtonsoft.Json.JsonConvert.SerializeObject(object)'), which clarifies the exact syntax expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns 'ilasm-style IL for a single method in a referenced closed-source assembly'. The verb 'Return' and specific resource 'ilasm-style IL' make the purpose unambiguous, and it distinguishes itself from siblings like get_method_source which returns source code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need IL for a method) but does not explicitly state when to use this tool versus alternatives like get_method_source. It provides an input constraint (fully-qualified name) but no 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool queues a task and returns a taskId for polling, but does not detail failure modes or rate limits. Adequate for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no unnecessary words. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single parameter, no output schema, and sibling polling tool, the description is adequate. It could mention that the task runs asynchronously, but the purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a parameter description that matches the tool description. The description adds no extra 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Queue a long-running tool' and the resource (tool), with explicit mention that only 'rebuild_solution' is allowed. This distinguishes it from siblings like 'get_task_status' and 'rebuild_solution'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Allowed tools: rebuild_solution' and advises polling with 'get_task_status'. This provides clear context and follow-up, though it lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool's read-only nature (diffing), reports five change kinds with breaking/non-breaking classification, sorting order, and states limitations (e.g., not detecting return type changes). It does not mention side effects or performance, but the disclosure is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with the main function, then listing change kinds, return structure, sorting, and limitations. It is detailed but not verbose. Minor redundancy exists (e.g., repeating 'from a prior get_public_api_surface'), but overall it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (multiple change kinds, sorting, limitations) and lack of output schema, the description covers the return fields and behavior thoroughly. It mentions limitations and required input type. It does not specify if the solution must be loaded or the output format, but these are inferable. Adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter with a detailed description covering both format and source. Since schema description coverage is 100%, the baseline score is 3. The tool description repeats some schema information but does not add significant new 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: diffing the current public API surface against a baseline, listing five specific change kinds, and returning a structured result. It uses a specific verb ('diff') and resource ('public API surface'), and the detail distinguishes it from sibling tools like get_public_api_surface.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that a baseline from a prior get_public_api_surface run is required, but it does not explicitly state when to use this tool versus alternatives or when not to use it. The exclusion of alternative guidance is a minor gap, but the usage 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses key behaviors: undoing name mangling, handling different frame types (declaration vs exact location), external frames resolving with origin=metadata, and preserving original trace order. No destructive behavior or side effects are described, but the tool is read-only by nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long but packs essential details in a structured way. It starts with the main action ('Map a pasted .NET stack trace') then lists specifics. Every sentence provides value; no tautology or filler. Could be slightly shortened, but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of stack trace resolution and the lack of output schema, the description covers return behavior well (frames resolved, order preserved, declaration vs exact location, origin=metadata). It is complete enough for an AI agent to understand what the tool does and what output to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add much parameter meaning. It mentions the limit default (500) and that stack trace should be pasted as-is (multi-line), which slightly expands on schema. The description also adds info about output order, but that's not parameter-specific. Overall adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool maps a pasted .NET stack trace to file/line/symbol, undoing compiler name mangling. It specifies various mangling patterns (async/iterator, lambdas, local functions, generic arity) and trace formats (Exception.ToString, log-prefixed, inner-exception chains, Ben.Demystifier). This is a specific verb+resource that distinguishes it from any sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use it for 'a pasted .NET stack trace' and details what types of traces it handles. It implies the tool should be used when needing to resolve symbols in a stack trace, but does not provide explicit when-not-to-use or alternative tools. Given the uniqueness among siblings, this is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses important behavioral traits: filters out test methods, MCP tools, source-generator output, MEF-composed services, and interop-laid-out fields. It also describes the return envelope structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and front-loaded with purpose. It lists filtered-out types efficiently. However, it could be slightly shorter by not listing every filtered category, though it adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (dead code detection, filtering, return envelope), the description covers all key aspects: what it does, filters, and return fields. No output schema exists, but the description explains the return structure. It is complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add meaning beyond what the schema provides for parameters. It mentions limit in the envelope description but not as a parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds potentially unused types and members (dead code detection) and specifies that it checks public symbols across the solution. This is a specific verb+resource that distinguishes it from sibling tools like find_uncovered_symbols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for dead code detection but provides no explicit guidance on when to use this tool versus alternatives or when not to use it. It does not differentiate from similar tools like find_uncovered_symbols.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly indicates a read-only query returning trust state components with no mention of side effects, which is sufficient but could explicitly state that no state is modified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant information; every phrase is meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately lists the returned data. It could mention that it's a snapshot of current trust state but is sufficiently complete for a read-only query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds value by listing the returned components, providing more context than the empty schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Return' and resource 'trust state' and enumerates the components (session-scoped paths, persistent paths, trusted roots, analyzer policy), clearly distinguishing it from mutation tools like 'trust_solution' and 'revoke_trust'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting trust state but does not explicitly state when to use this tool versus alternatives or provide any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes matching behavior and return value (full path). However, no annotations exist, and the description does not disclose failure modes, prerequisite state, or side effects beyond switching the active solution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, followed by matching details and return value. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers purpose, matching semantics, and return value. Missing error conditions or prerequisites, but adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes the single parameter as a partial or full name. The description adds 'case-insensitive' behavior, which is meaningful beyond the schema. With 100% schema coverage, the description adds useful value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool switches the active solution and that subsequent calls operate on that solution. Mentions partial case-insensitive matching, which distinguishes it from related tools like load_solution or list_solutions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly advises use before other solution-dependent calls. No explicit when-not-to-use or alternatives listed, but the context of sibling tools provides some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Clearly states read-only analysis outputs. Does not mention side effects, but none expected. Transparent for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first explains what is returned, second adds efficiency context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description must explain returns. It does: signature, location, callers, outgoing calls. Sufficient for a single-parameter analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage and describes the symbol parameter well. Description does not add new parameter details but reinforces the purpose. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get', resource 'method', and specific outputs: signature, location, callers, outgoing calls. Distinguishes from siblings by noting it's more efficient than calling find_callers separately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly compares to find_callers, indicating use when comprehensive analysis is needed. Could be more explicit about when not to use it, but the efficiency note provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility. It discloses the two modes and their outputs, and mentions the assembly is closed-source. However, it does not discuss prerequisites (e.g., assembly must be referenced) or error cases, leaving minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the purpose and modes. Every word adds value, with no redundancy or waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, 100% schema coverage, and no output schema, the description adequately covers the tool's behavior and return types for each mode. It could be slightly more detailed about the format of returned data, but overall it's sufficient for an inspection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with adequate parameter descriptions, and the tool description adds substantial meaning by explaining the behavior of 'mode' and 'namespaceFilter' (e.g., 'mode=summary' returns namespaces and type counts, 'namespace' requires namespaceFilter). This goes beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects a referenced closed-source assembly with two explicit modes (summary and namespace) and what each returns. This differentiates it from sibling tools like get_type_overview 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.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting external assemblies but provides no explicit guidance on when to use this tool versus alternatives like get_public_api_surface or get_type_hierarchy. No exclusions or when-not-to-use scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, but the description discloses key behaviors: frees memory, and if the unloaded solution was active, another takes over. This provides actionable understanding beyond just the operation name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose, no redundancy. Every sentence adds unique, useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description fully covers purpose, usage context, matching behavior, and side effects. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already describes the parameter as 'Partial or full solution name/path to match'. The description adds only the case-insensitivity detail, offering marginal additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Unload a previously loaded solution') and its purpose ('to free memory'). It distinguishes itself from its complementary sibling 'load_solution' by emphasizing the memory reclamation aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('when you're done analyzing a codebase'), provides matching behavior details ('partial, case-insensitive name'), and implies consequences ('another loaded solution becomes active'). Missing explicit 'when not to use', but sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It describes the combined behavior from find_references and find_callers, and outlines the scope of analysis (files, projects, call sites). It does not disclose performance or limitations, but for a read-only analysis tool 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each essential and front-loaded. The first states the main purpose, the second explains composition, and the third gives usage context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and no output schema, the description is largely complete. It defines purpose, scope, and usage. A minor gap is that it does not describe the return format, but the phrase 'shows every file, project, and call site affected' implies the output scope. Overall, it is sufficient for an agent to select and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a parameter description that explains the expected format. The tool description adds no additional semantic details beyond the schema. Baseline 3 is appropriate as the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes the blast radius of changing a symbol, showing affected files, projects, and call sites. It distinguishes itself from siblings like find_references by noting it combines multiple tools into a single impact summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use before renaming, changing signatures, or removing a type/method.' This tells the agent exactly when to invoke this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the default preview mode (returns diff without writing) and the effect of setting preview=false (applies changes to disk). This is adequate transparency for a mutation tool, though it could mention reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that convey purpose, prerequisite workflow, and key parameter behavior. No wasted words; front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema, the description covers the core workflow (discover then apply) and preview behavior. It omits details about return format or error handling, but is sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema by explaining that actionTitle is the exact title from get_code_actions and that preview controls whether changes are written. This extra context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Apply') and resource ('code action refactoring or fix') and immediately distinguishes from the sibling tool 'get_code_actions' by instructing to use it first for discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states to use get_code_actions first and explains the default preview mode and how to disable it. It does not mention when not to use this tool or provide alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses return format (summary + per-violation list), scope (production projects only), and limitations (static analysis, no fix). It does not mention performance impact or runtime behavior, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: first states purpose and violation types, second describes output, third adds constraints and limitations. Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (six violation classes) and absence of output schema, the description provides sufficient detail about return format (summary + per-violation with severity, location, snippet). It could clarify if it targets the current solution or all loaded projects, but the phrase 'across all production projects' is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the baseline is 4. The description adds no parameter info because none exist, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects six specific classes of async/await misuse across production projects, with enumeration of violation types. It distinguishes itself from sibling analysis tools like find_disposable_misuse or find_naming_violations by being async-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use (for async misuse detection) and what it does not do (no fix suggestions, skips test projects). However, it does not explicitly compare to sibling tools or provide 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses behavioral traits such as default exact-only matching, the effect of includeBaseClauses, and sorting order. It also explains what caughtType means for bare catches, adding transparency beyond simple input/output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but well-structured with front-loaded purpose and clear information flow. Each sentence adds value, and it avoids unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters and no output schema, the description is highly complete: it explains the output envelope structure (items, totalCount, etc.), the sorting order, and the behavior for bare catches. It fully covers what an agent needs to understand invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema describes each parameter. The description adds meaning by explaining the semantic effect of includeBaseClauses and clarifying that caughtType is null for bare catches, providing context the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds catch clauses handling a specific exception type and reports their behavior (hasFilter, rethrows, isEmpty). It distinguishes itself from sibling tools by being exclusively focused on catch blocks and their swallowing behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (to find who is silently swallowing an exception). It details the includeBaseClauses option for broader matching, though it does not explicitly contrast with siblings like find_exception_flow or find_throw_sites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains return envelope structure (items sorted by kind then title, totalCount, truncated, limit default 100), but does not explicitly state read-only behavior or error cases. However, given the lack of annotations, this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key behaviors: optional range selection, return envelope structure, sorting, and limit. No output schema, but description provides necessary details. Could mention error conditions or empty results, but overall sufficient for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value by explaining optional endLine/endColumn for 'extract-method style refactorings' and restates limit default, giving context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List available code actions (refactorings and fixes) at a position in a C# file' with specific verb and resource. It distinguishes from sibling 'apply_code_action' by noting that returned titles can be passed to it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to optionally specify endLine/endColumn for range selection and notes the workflow to apply_code_action. No explicit when-not-to-use or comparison with similar sibling like get_code_fixes, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It discloses the return envelope structure (items, totalCount, truncated, limit) and the default limit of 100, and implies a read-only operation ('reviewed and applied').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second explains return format. 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no output schema, so the description compensates by detailing the envelope structure. However, it omits prerequisites (e.g., solution must be loaded) and error conditions. Adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 4 parameters described). The description adds minor value by mentioning sorting by title and default limit, slightly augmenting the schema. Baseline 3 is exceeded.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get available code fixes for a specific diagnostic at a file location' uses a specific verb and resource, clearly distinguishing from sibling tools like get_code_actions which handle other code actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after identifying a diagnostic at a file location, but does not explicitly state when to use this over alternatives. It provides clear context but lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool's behavior as a read-only retrieval operation (getting an overview), which is implied. It does not explicitly state it is non-destructive, but the content suggests it. Adds value by listing what the overview includes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence front-loads the purpose and contents, the second provides a usage comparison. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter tool with no output schema and no annotations, the description covers what the tool does and its benefits. It could specify the output format more, but it is adequate for an agent to decide to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'typeName', which already explains it can be simple or fully qualified. The description does not add meaningful extra context beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool provides a comprehensive overview of a type, listing specific aspects like namespace, base class, interfaces, members, DI dependencies, type hierarchy, and diagnostics. This is a specific verb (get) and resource (type overview), and distinguishes itself from sibling tools by combining multiple separate calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says it is more efficient than calling get_symbol_context + get_type_hierarchy + get_diagnostics separately, which tells the agent when to use this tool versus alternatives. Provides clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool performs a destructive-like operation (full reload, recompile, rebuild indexes). No annotations exist, so the description carries the full burden. It clearly states the actions, but could be more explicit about side effects (e.g., long runtime, discarding cached state).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first explains what it does, second advises when to use. Every word is necessary; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description covers purpose and usage. It is sufficient for an agent to decide when to invoke, though could mention expected duration or whether it blocks other operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters and schema coverage is 100%, so no parameter documentation is needed. Baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool forces a full reload of the solution by re-opening the .sln, recompiling all projects, and rebuilding indexes. Distinguishes itself from siblings like load_solution (loads without rebuild) and set_active_solution (merely switches).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: after changing Directory.Build.props, adding/removing NuGet packages, or when diagnostics seem stale. Lacks explicit 'when not to use' or alternatives, but the guidance is specific and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: 'allowOnly' ignores framework/generated targets, self-references allowed, generated code never a source, etc. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense but verbose; could benefit from bullet points or tighter structure. Every sentence adds value, but readability suffers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive: covers rule syntax, two semantics, result grouping, sorting, and output structure (envelope with byRule). No output schema, so the description compensates fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, but the description adds valuable nuance beyond schema, e.g., explaining 'to' arrays for forbid vs. allowOnly and the priority order of rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks user-supplied layering rules against the solution's semantic type graph. It distinguishes from siblings by focusing on custom rule evaluation, not just dependency analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Detailed guidance on rule kinds and interpretation of empty results. Lacks explicit when-not-to-use or alternatives, but context is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details result content (source location, resolved handler, subscription kind), sorting order, and envelope fields (totalCount, truncated, limit). It does not mention performance or side effects, but for a read-only search this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each adding distinct information: purpose, symbol types, result details, use cases. No fluff, but could be slightly more streamlined without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only 2 parameters and no output schema, the description covers purpose, input semantics, use cases, and result structure comprehensively. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds value by explaining limit default (500) and sorting, and providing examples for symbol ('MyClass.Clicked'). This goes beyond the schema's type/description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it 'Find every += and -= site for an event symbol across the solution.' This is a specific verb and resource, and distinguishes it from general find tools like find_references or grep.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions use cases: 'memory-leak audits', 'UI event subscriber inspection', or 'when Grep over EventName would miss qualified sites'. It does not compare with sibling tools but gives practical context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description thoroughly discloses behavior: kinds classification, envelope summary, multiple references per line reported separately, sorting by file/line/column, and default limit. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but well-structured, front-loading purpose then details. Each sentence is informative, though some detail could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains output format (each reference tagged with kind, envelope with byKind summary), sorting, and default limit. Complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds significant value: explains each parameter's purpose, lists possible kinds for 'kinds', defines 'symbol' format, and states 'limit' default. Enhances schema meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds all references to a symbol across the solution, each tagged with a kind. It lists many kinds, which distinguishes it from sibling tools like 'find_callers' or 'find_implementations'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to filter by kinds with an example (mutation sites) but does not explicitly state when to use this tool vs alternatives or 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses static analysis, 3-helper-hop limit, test framework recognition, complexity sorting, and riskHotspotCount. No side effects mentioned, but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (two sentences) and front-loaded with purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers purpose, methodology, output details, and constraints comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100%. Description does not need to add param info; baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports public methods and properties not transitively reached by tests, with specific details on helper hops, sorting, and summary. It distinguishes from siblings like 'find_unused_symbols'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to find uncovered code in tests) and mentions recognized test frameworks. It does not explicitly state when not to use or name alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It details the envelope structure (items sorted worst-first, totalCount, truncated, limit, summary with max/avg/overThreshold, maxCognitive) and explains metric options and threshold filtering. It lacks explicit side-effect or permission info, but as a read-only analysis tool, 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused paragraph with clear front-loading: it starts with the primary action, then details metrics and output structure. Every sentence adds unique value without redundancy or extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description thoroughly explains the return envelope (sorted items, totalCount, truncated, limit, summary fields). For a tool with 4 parameters and no nested objects, this is sufficient. Minor gap: no mention of error conditions or performance implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all 4 parameters have descriptions). The description adds significant value beyond schema: it explains the default limit (100), clarifies the 'metric' choices ('cyclomatic' default and 'cognitive') and that both are always reported, describes threshold as 'minimum complexity' applied to selected metric, and details sorting and envelope. This enriches parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates complexity for members, specifying two metrics (cyclomatic and cognitive) and maxNesting. It distinctly identifies the resource (members: methods, constructors, etc.) and the action (calculate). This differentiates it from sibling code analysis tools like 'analyze_data_flow' or 'find_circular_dependencies'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use: to get complexity metrics for code members. It explains the metrics and envelope, giving context. However, it does not explicitly state when not to use or list alternatives, though no direct sibling overlaps in functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that results are sorted by severity descending, file, and line, and that the return envelope includes fields like totalCount, truncated, limit, and severity summary. It does not mention side effects or destructive behavior, which is appropriate for a read-only diagnostic tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first conveys the core purpose, and the second provides essential usage context about trust and return format. No wasted words; every sentence is necessary and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return envelope. It covers the prerequisite for analyzer diagnostics and the sorting behavior. For a tool with four well-documented parameters, the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds value by explaining the return envelope structure (items, totalCount, truncated, limit, severity summary) and reiterating the trust requirement for analyzer diagnostics, which is not fully captured in the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists compiler errors and warnings, with an option to include analyzer diagnostics. It uses specific verb 'list' and resource 'compiler errors and warnings across the solution', which distinguishes it from sibling tools like get_project_health or analyze_method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions that analyzer diagnostics require the solution to be trusted and directs users to 'trust_solution', providing clear context for when the includeAnalyzers parameter is usable. However, it does not specify when to use this tool over alternatives or 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides key behavioral details: filtering out production projects/generated code/BCL calls, case-insensitive project filter, and sort order (tests by file/line, projects by name ASC). It could mention that the tool is read-only, but the behavior is well-covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: it starts with the main purpose, then details output fields, use cases, filtering behavior, and sorting. Every sentence adds value, though it could be slightly more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one optional parameter, no output schema), the description is comprehensive: it explains input, output content, filtering, and sorting. It lacks mention of pagination or limits, but these are not critical for this type of tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the single parameter 'project' with 100% description. The tool description adds context (case-insensitive, optional) beyond the schema's basic description. Baseline for 100% coverage is 3, but the extra context warrants a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a 'per-project inventory of test methods' and lists specific reported details (framework, attribute kind, row count, location, referenced symbols). It distinguishes itself from the sibling find_tests_for_symbol by specifying the direction (project → tests vs. test → production).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'answer what does this test suite cover?' or 'break down test counts by framework/attribute'. It also contrasts with find_tests_for_symbol, giving clear guidance on which tool to use for which direction of analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses behavior: two patterns, return format (summary + per-violation list with severity/location/method/snippet), scope limitations, and static analysis nature. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise at about 4 sentences, front-loaded with purpose and patterns. Could be slightly more structured but efficiently conveys all necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema or annotations, description is self-contained: explains what it does, how results are structured, scope, and limitations. No missing gaps for a parameterless tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no parameters, and schema coverage is 100%. Baseline score of 4 applies; description adds no parameter info but is not needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it detects IDisposable/IAsyncDisposable leaks and describes two specific patterns with severity levels. Differentiates well from sibling tools which focus on other code analysis aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use (detecting disposable misuse) and what it does not cover (test projects, constructors, fix suggestions). Lacks explicit comparison to alternatives but contextually sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses sorting order (errors first, then by usage count, then symbol name), omission of test projects, case-insensitive project filter, and inclusion of third-party NuGet deprecations. These details provide strong behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of about five sentences, front-loading the main purpose and then adding relevant details. It is efficient but could be slightly more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (grouping, sorting, multiple obsolete sources), the description covers all key behaviors. No output schema is provided, but the description explains the output structure (grouped by message and severity with counts) sufficiently for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have clear descriptions in the input schema. The tool description does not add significant new meaning beyond stating that errorOnly returns error-level deprecations and the project filter is case-insensitive, which is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find', the resource 'call sites referencing [Obsolete]-marked symbols', and the grouping by deprecation message and severity. It also distinguishes itself from the sibling tool 'find_attribute_usages' by noting it is sharper for migration-planning workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool ('Sharper than find_attribute_usages for migration-planning workflows') and what to expect (includes source- and metadata-marked obsoletes, omits zero usages and test projects). It implies when not to use by contrasting with find_attribute_usages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It details that the search covers the entire solution, includes throws in lambdas and local functions, attributes throws to the containing member, and returns a sorted envelope with summaries. While it does not explicitly state read-only behavior or performance characteristics, the description is sufficiently transparent for a typical 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that begins with the primary purpose, then details scope, parameter usage, comparison with a sibling, and return format. It is information-dense but not excessively verbose. Minor improvement could be splitting into sentences, but it remains clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is highly complete given the tool's complexity. It covers the exception type specification, matching scope (including lambdas and local functions), the use of 'includeDerived', the distinction from 'get_exception_flow', and the envelope structure (items, totalCount, truncated, limit, byType/byProject summary, sorting). No output schema exists, so the description compensates fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by giving concrete examples for the 'exceptionType' parameter (System.ArgumentNullException, MyApp.DomainException) and explaining the scope of 'includeDerived' (matches subclasses). It also describes the types of throw statements matched, which enriches parameter understanding without being redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find' and the resource 'every place an exception type is thrown across the solution'. It explicitly distinguishes itself from the sibling tool 'get_exception_flow' by describing a different use case (finding all throws vs. escapes from a specific method), providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Find every place an exception type is thrown'), when not to use it (use 'get_exception_flow' for method escape analysis), and how to use parameters like 'includeDerived'. It also explains the types of throws matched (throw new, throw expr, bare throw), covering usage context thoroughly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It fully discloses that the tool does not write to disk, what stubs include (happy-path Fact, Theory+InlineData, Assert.Throws), async detection, framework auto-detection, and returns TodoNotes. There are no hidden behaviors or contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that front-loads the main purpose. Every sentence contributes useful information, but it could be more scannable with bullet points. It is efficient but slightly verbose for an AI agent's quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains the return content (framework, file path, class name, file contents, TodoNotes). It covers edge cases like async detection, framework override, and exclusion of properties/operators. The tool's behavior is completely specified 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value beyond the schema by explaining how the symbol FQN works (type vs method) and providing example usage. For the framework parameter, it lists the allowed values and explains auto-detection. This enhances understanding beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it emits a test-class skeleton (parseable C#) for a method or type. It distinguishes from siblings by mentioning pairing with find_uncovered_symbols and get_test_summary. The verb 'emits' and the specific output (framework, file path, class name, file contents, TodoNotes) make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (generating test stubs) and what it does not do (not write to disk). It specifies exclusions (properties, indexers, operators, constructors) and mentions options to override framework. However, it does not explicitly contrast with alternatives like 'find_uncovered_symbols' or 'get_test_summary', though it pairs with them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description thoroughly discloses what the tool returns and its behavior (e.g., returns source location only for non-metadata, includes all listed attributes). It does not mention side effects, but as a read-only tool, this is acceptable. Could add note about requiring loaded code, but not critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-organized paragraph that front-loads the main purpose. It is concise but covers all necessary details. Slightly verbose in listing all included attributes, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and no output schema, the description fully covers the tool's purpose, usage, parameter format, return content, exceptions, and sorting. No gaps for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a reasonable schema description. The tool description adds value by clarifying the exact format of the symbol parameter with examples ('Greeter.Greet', 'Greeter.Greeter', 'System.Console.WriteLine') and distinguishing method vs constructor notation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns every overload of a method or constructor with source and metadata, specifying exactly what is included (full signature, parameter details, return type, etc.) and excluded (operator overloads). It distinguishes itself from the sibling tool get_operators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: for ordinary methods pass 'Type.Method', for constructors pass 'Type.Type'. Directs users to use get_operators for operator overloads, and specifies sorting order (parameter count ASC, then signature ordinal ASC).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description extensively discloses behavioral traits: defaults (complexity threshold 10, large-class limits), test projects skipped, case-insensitive filtering, sort order, and return format (counts plus top-N hotspots). This fully informs the agent of 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but front-loaded with the core purpose. Every sentence adds useful context, though some details (like sort order) could be optional. Still efficient for the complexity involved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains the return structure (counts per dimension, top-N hotspots) and covers edge cases (null project, zero hotspots). The tool has only 2 simple parameters, and the description addresses all relevant context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by noting that 'project' can be null (whole solution) and that 'hotspotsPerDimension=0' yields counts-only output. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool aggregates 7 specific health dimensions per project, using specific verbs ('aggregate', 'returns') and resources ('health dimensions', 'hotspots'). It distinguishes itself from sibling tools by being a focused health assessment tool rather than a general analysis tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use is provided: 'when answering 'how is this project doing?' / 'where should I focus?' / 'what's the technical debt picture?''. While it doesn't explicitly state when not to use or suggest alternatives, the context and sibling list imply it's for high-level health checks, not deep dives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: deterministic sorting, returned fields, skipped items (test projects, generated code, internal symbols, etc.), and that inherited members are not repeated. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose. The second sentence is somewhat long but packs essential details. Overall concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description thoroughly covers the return format (list of API entries with specific fields plus summary buckets) and all filtering rules, making it complete for a parameterless tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so the description does not need to add parameter details. It does add semantic context about the output format and filtering, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enumerates public and protected types and members in production projects of the active solution, with a specific verb ('Enumerate') and resource ('public and protected type and member'). This distinguishes it from siblings like 'get_type_overview' or '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.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving the complete API surface of a solution, but does not explicitly state when to use it versus alternatives. However, the detailed filtering criteria (skips test projects, generated code, etc.) provides implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool marks trust for analyzer execution and warns that analyzer DLLs run in-process, indicating a security implication. However, it does not explain whether trust is additive or overwriting, or the effects of revoking trust. Still, it covers the essential behavioral trait and a key warning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the primary purpose, and includes a crucial usage warning. Every sentence contributes meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters, no output schema), the description covers the essential purpose and usage constraint. However, it omits information about the return value or success/failure indication, which could affect an agent's ability to handle the response. This minor gap prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, so baseline is 3. The description adds value by reiterating the path format ('.sln/.slnx file or directory') and emphasizing the user confirmation requirement, which is not in the schema. This slightly elevates the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool marks a solution path or directory root as trusted for analyzer execution. It distinguishes from sibling tools like revoke_trust and list_trusted_paths by specifying the action and the prerequisite relationship with get_diagnostics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (before get_diagnostics) and provides a critical warning: 'Always confirm with the user before calling this tool — analyzer DLLs run as in-process code.' This gives clear guidance and an exclusionary condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It is highly transparent, detailing side effects (cascades to overrides and interface implementations, rewrites call sites), preview vs apply mode, conflict handling with force, and limitations (source-defined methods only). It fully discloses behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-organized, with key actions stated upfront. Every sentence adds value, detailing operation semantics, rejected cases, and mode behavior. Minor redundancy could be trimmed, but the structure is logical and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no output schema), the description is remarkably complete. It explains conflicts, the role of 'force', preview mode, source-defined methods requirement, and how operations interact. It covers edge cases like extension method preservation and params array ordering. No obvious gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, but the description adds critical meaning beyond the schema. It explains that operations apply in order, that 'add' requires 'callSiteValue' (or optional 'defaultValue'), that 'reorder' expects a full permutation, and that 'remove' drops 'parameter'. It also clarifies edge cases like extension method 'this' parameter handling and params array restrictions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Add, remove, or reorder a method's parameters and update every call site' using Roslyn's change-signature engine. It specifies the resource (a method's signature) and the exact actions. This distinguishes it from sibling tools like rename_symbol or find_references, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive guidance on when to use the tool, including detailed explanations of each operation type (add, remove, reorder) and their requirements. It also lists rejected unsafe scenarios (e.g., invalid identifiers, unresolvable types). However, it does not explicitly state when NOT to use this tool versus alternatives, such as simpler refactorings. Overall, it strongly guides proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully describes behavior: two axes, thresholds, qualification logic, exclusions (BCL namespaces, test projects, generated code, interfaces, nested types), and sorting. No side effects expected for a read-only analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is dense but efficient, each sentence adds value. Structured logically: purpose, comparison, axes, qualification rule, defaults, exclusions, sorting. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Very detailed but lacks specification of return format (e.g., list of type names with scores). No output schema; description should mention what is returned. Otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds crucial context: all three size thresholds must be crossed AND at least one coupling threshold, defaults, and configurability. This significantly aids correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool finds types combining high size and high coupling, distinguishing it from sibling find_large_classes by explaining the two axes and why it's a sharper signal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains when to use (to identify god classes violating SRP) and implicitly when not (DTOs, dispatchers are excluded). It compares to find_large_classes but doesn't explicitly address other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behaviors: compiler reduction for applicability, meaning of isStatic, scope limitations, return format details. It provides comprehensive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured with clear sections. While compact, it could be slightly more concise, but each sentence adds essential information for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description thoroughly explains the return format (signature, kind, origin, etc.). It covers all necessary aspects for an agent to invoke and interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds significant value beyond schema by explaining type formats (e.g., generic, array, tuple), default limit, and case-insensitive nameFilter behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns extension members applicable to a receiver type, using specific verbs like 'answer', and distinguishes it from siblings by focusing on extension methods/properties. No sibling tool has similar functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to find extension members for a type) and clarifies important behaviors (e.g., results not filtered by using scope, sort order). It does not explicitly mention alternatives or when not to use it, 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses all behavioral traits: what is returned (operator kind, signature, parameters, return type, etc.), inclusion of compiler-synthesized operators, source vs. metadata, sort order, and the non-inheritance rule. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but front-loaded with the core purpose. Every sentence adds value, though some details (e.g., sort order) could be more concise. Still, it is well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and lack of output schema, the description provides a comprehensive understanding of what the tool returns and its constraints. An agent can accurately select and invoke this tool based solely on the provided text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'symbol' described. The description adds meaningful guidance beyond the schema: 'Pass a type name, simple or fully qualified (e.g. 'Vector2', 'MyApp.Money', 'System.Decimal').' This helps the agent construct valid input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a unique verb-resource pair: 'Return every user-defined operator and conversion operator on a type'. It clearly distinguishes from sibling tools (e.g., get_type_overview, find_references) by focusing exclusively on operators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to invoke the tool (pass a type name, simple or fully qualified) and notes that operators do not inherit, so returned operators are declared only. It does not explicitly say when not to use or list alternatives, but the context is clear given the tool's specialized nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description fully carries the burden. It details preview mode vs apply, conflict reporting, force flag, cascading to references/constructors/overrides/nameof/XML doc crefs, and unsupported features. This is comprehensive and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and front-loaded with the main purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no output schema), the description covers all essential aspects: what it renames, preview vs apply, conflict handling, force, and limitations. It is complete enough 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.
Parameters4/5Does 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 explaining the interplay between preview, conflicts, and force, and clarifying what 'Conflicts' means. This extra context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renames types or members across the entire solution using Roslyn Renamer. It specifies the verb 'rename' and the resources 'type or member', and distinguishes itself from siblings like change_signature by focusing on renaming rather than signature changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance: defaults to preview mode, explains how to apply, and explicitly states unsupported cases (locals/parameters, file renames). However, it does not explicitly compare to sibling tools like find_references or change_signature, but the behavior is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Covers cycle detection, hard cap with truncation, direction options, external callee marking, and virtual dispatch limitations. Thorough and accurate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured and front-loaded, but slightly verbose. Every sentence adds value; minimal redundancy. Could be tightened but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for complexity: covers depth, direction, cycle detection, truncation, output format, and external callees. No output schema, but description adequately explains return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value beyond schema by explaining the graph structure, truncation handling, and external callee details, enhancing semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb (get) and resource (call graph) with specifics: transitive caller/callee graph for a method symbol, depth-bounded. Distinguishes from siblings like find_callers by mentioning depth > 1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this instead of recursive find_callers / analyze_method calls when you need depth > 1', providing clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description fully carries the behavioral transparency burden. It thoroughly details the algorithm (depth-first, cycle-safe, bounded), return fields, edge cases (when filters, documented exceptions), and limitations (static analysis only, no runtime failures, truncation). This is exceptional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the main purpose, but it is somewhat lengthy (6 sentences). However, every sentence adds necessary detail for a complex analysis tool, so it earns its length. It is not excessively verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description fully explains the return values (escapes, path, caughtIn, etc.) and covers the algorithm, limitations, edge cases, and truncation behavior. For a tool of this complexity, the description provides complete contextual information for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the meaning of parameters beyond the schema (e.g., maxDepth controls callee walking depth, maxNodes caps visited methods, includeDocumented filters documented exceptions). It provides context that the schema's descriptions alone do not fully convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific language: 'Which exceptions can escape a method — the is calling this safe? question.' It clearly states the tool's purpose and actively distinguishes from sibling tool find_throw_sites, which is mentioned as the alternative for a plain textual scan of throws.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool vs alternatives: 'use find_throw_sites for a plain textual scan of throws.' It also describes limitations (no reflection, no virtual-dispatch) and exclusions (lambdas, local functions), providing clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it explains the returned fields (constructors, factories, diRegistrations, instantiable, note, requiredMembers, accessible) and special semantics like null accessible meaning not computed, instance builder exclusion, async factory unwrapping, and isImplicit. No annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: first sentence states core purpose, then enumerates content, then details on accessibility, DI, and non-instantiable types. Every sentence adds value. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description must explain what the tool returns, and it does so in detail: constructors (with accessibility, isImplicit, obsolete), factories (including cross-type, async), diRegistrations, requiredMembers, instantiable flag with note, and accessible semantics. It covers all key aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters documented). The description adds meaningful context for fromProject (computes accessible with InternalsVisibleTo). For symbol, it adds 'simple or fully qualified', which is minor but helpful. Exceeds the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb-resource pair: 'Answer how do I construct this type?' and lists the covered items (constructors, static factories, DI registrations). It distinguishes itself from siblings like find_implementations and get_type_overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use (to find how to construct a type) and when not: for interfaces/abstract/static classes it says to use find_implementations instead. It also explains that DI registrations indicate the type should be resolved rather than constructed. Alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It thoroughly discloses: runtime loading, filter matching rules (case-insensitive glob vs exact case-sensitive), transitive closure, error on no match, replace semantics, instant activation for already-loaded solutions without filter, typical load time, background mode behavior, and activation timing. This goes well beyond minimal requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but well-structured with clear sentences. It front-loads the main purpose and then details. While it is somewhat lengthy, every sentence adds necessary information for correct usage. Could benefit from bullet points for scanning, but current format is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully covers error cases (no match), background task polling, activation behavior, and replaces and activate semantics. It also references related tools (list_solutions, get_task_status). This is highly complete for a tool with 4 parameters and complex behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value by explaining matching rules for include (only * and ?, case-insensitive) and rootProjects (exact, case-sensitive), the interaction between the two filters, the transitive closure, and the behavior of background mode. This is more than what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads a solution file and makes it active, with specific details on filtering and background loading. It distinguishes from sibling tools like unload_solution and set_active_solution by describing its unique behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance, including when to use filters, when to use background mode, and what happens on errors. It also gives an alternative strategy (do a no-filter load first and use list_solutions) for uncertain naming, and explains the replace-activate semantics for already-loaded solutions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MarcelRoozekrans/roslyn-codelens-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server