A Roslyn-powered MCP server providing deep semantic analysis and code transformation for .NET solutions, exposing over 50 tools for AI agents to browse, understand, test, refactor, and enforce rules on .NET codebases.
go_to_definition — Find where any symbol is defined (file + line)
find_references — Find all references to a symbol, tagged by kind (read, write, invocation, etc.)
search_symbols — Fuzzy/substring search for types, methods, properties, and fields
find_implementations — Find all classes/structs implementing an interface or extending a class
find_callers — Find every call site for a method, property, or constructor
get_type_hierarchy — Walk base classes, interfaces, and derived types
analyze_change_impact — Show all files, projects, and call sites affected by changing a symbol
get_call_graph — Transitive caller/callee graph, depth-bounded with cycle detection
get_symbol_context — One-shot context dump for any type (namespace, base class, interfaces, members)
get_type_overview — Comprehensive type overview: context + hierarchy + diagnostics in one call
analyze_method — Method signature + callers + outgoing calls in one call
get_file_overview — Types defined in a file + file-scoped diagnostics
get_method_source — Full declaration source (docs, attributes, signature, body) for one or many members
get_overloads — Every overload of a method or constructor with full parameter detail
get_operators — Every user-defined operator and conversion operator on a type
get_extension_methods — Every extension member applicable to a type (including BCL LINQ)
get_instantiation_options — Constructors, static factories, DI registrations, and required members for a type
get_project_dependencies — Project reference graph (direct and transitive)
get_di_registrations — Scan for DI service registrations (AddSingleton, AddTransient, etc.)
find_circular_dependencies — Detect cycles in project or namespace dependency graphs
check_architecture — Enforce layering rules (forbid/allowOnly) against the real semantic type graph
get_nuget_dependencies — List NuGet package references per project
find_event_subscribers — Every += / -= site for an event symbol
find_tests_for_symbol — List xUnit/NUnit/MSTest methods that exercise a production symbol
get_test_summary — Per-project inventory of test methods with framework, attribute kind, and production symbols referenced
find_uncovered_symbols — Public methods/properties no test transitively reaches, sorted by cyclomatic complexity
generate_test_skeleton — Emit a compilable test-class skeleton for a method or type
get_diagnostics — List compiler errors, warnings, and Roslyn analyzer diagnostics
get_code_fixes — Get available code fixes with structured text edits for any diagnostic
get_complexity_metrics — Cyclomatic and cognitive complexity + max nesting depth per member
find_naming_violations — Check .NET naming convention compliance
find_async_violations — Detect sync-over-async, async void misuse, missing awaits, fire-and-forget tasks
find_disposable_misuse — Detect IDisposable/IAsyncDisposable instances at risk of leaking
find_large_classes — Find oversized types by member or line count
find_god_objects — Types combining high size with high cross-namespace coupling
find_unused_symbols — Dead code detection via reference analysis
find_reflection_usage — Detect dynamic/reflection-based usage
find_obsolete_usage — Every call site referencing [Obsolete]-marked symbols
get_project_health — Composite audit aggregating 7 quality dimensions per project
get_exception_flow — What exceptions can escape a method (walks callees, propagates through try/catch)
find_throw_sites — Every place an exception type is thrown
find_catch_blocks — Every catch for an exception type, with rethrow/empty/filter flags
analyze_data_flow — Variable read/write/capture analysis within a statement range
analyze_control_flow — Branch/loop reachability analysis within a statement range
get_code_actions — Discover available refactorings and fixes at any position
apply_code_action — Execute any Roslyn refactoring by title, with preview mode
rename_symbol — Solution-wide safe rename with preview mode and conflict reporting
change_signature — Add, remove, and reorder method parameters with full call-site rewriting
get_public_api_surface — Enumerate every public/protected type and member in production projects
find_breaking_changes — Diff the current API against a baseline JSON or DLL
find_attribute_usages — Find types and members decorated with a specific attribute
get_source_generators — List source generators and their output per project
get_generated_code — Inspect generated source code from source generators
inspect_external_assembly — Browse types, members, and XML docs from closed-source NuGet packages
peek_il — Decompile any method to ilasm-style IL bytecode
resolve_stack_trace — Map a pasted .NET stack trace to file/line/symbol, undoing compiler name mangling
list_solutions — List all loaded solutions and which is active
set_active_solution — Switch the active solution
load_solution — Load an additional .sln/.slnx at runtime
unload_solution — Unload a solution to free memory
rebuild_solution — Force a full reload of the analyzed solution
start_background_task — Queue a long-running tool to run in the background
get_task_status — Poll the status of a background task
list_running_tasks — List background tasks running or completed within the last 5 minutes
trust_solution — Authorize a solution to run Roslyn analyzers
list_trusted_paths — Inspect the persistent trust store
revoke_trust — Revoke a previously-granted trust for a solution path
Provides deep semantic analysis of .NET codebases, allowing for the exploration of type hierarchies, call graphs, dependency injection registrations, diagnostics, and automated code fixes.
Enables the inspection and listing of NuGet package dependencies and references across projects within a .NET solution.
A Roslyn-based MCP server that gives AI agents deep semantic understanding of .NET codebases — type hierarchies, call graphs, DI registrations, diagnostics, refactoring, and more.
A hosted deployment is available on Fronteir AI.
Related MCP server: mcp-deepcontext
find_implementations — Find all classes/structs implementing an interface or extending a class
find_callers — Find every call site for a method, property, or constructor
find_event_subscribers — Every += / -= site for an event symbol, with resolved handler and subscribe/unsubscribe tag
find_tests_for_symbol — List xUnit/NUnit/MSTest methods that exercise a production symbol; opt-in transitive walk through helpers
get_test_summary — Per-project inventory of test methods with framework, attribute kind, data-row count, location, and production symbols referenced
find_uncovered_symbols — Public methods and properties no test transitively reaches; sorted by cyclomatic complexity for prioritization
generate_test_skeleton — Emit a compilable test-class skeleton (as text) for a method or type. Auto-detects xUnit/NUnit/MSTest; surfaces constructor dependencies as TodoNotes; returns a suggested file path. Closes the loop with find_uncovered_symbols
get_type_hierarchy — Walk base classes, interfaces, and derived types
get_di_registrations — Scan for DI service registrations. Reads generic (AddSingleton<IFoo, Foo>()), single-generic, typeof pair and factory-lambda forms
get_instantiation_options — "How do I construct this type?" in one call: constructors with full parameter detail, static factory methods declared anywhere in the solution (including on a separate factory type), DI registrations, and required members. Pass fromProject to learn whether that project can actually reach each option — it honours InternalsVisibleTo, so it answers "can my test project call this internal constructor?"
get_project_dependencies — Get the project reference graph
get_symbol_context — One-shot context dump for any type
get_public_api_surface — Enumerate every public/protected type and member in production projects; flat, deterministically-sorted list suitable for API review or breaking-change baselines.
find_breaking_changes — Diff the current API against a baseline JSON or DLL; report removed members, kind changes, and accessibility changes with Breaking/NonBreaking severity.
find_reflection_usage — Detect dynamic/reflection-based usage
get_exception_flow — What exceptions can escape a method: walks callees depth-bounded, propagates each throw up through every enclosing try/catch, and reports what still escapes with its propagation path; metadata callees contribute their documented exceptions
find_throw_sites — Every place an exception type is thrown, optionally including derived types; rethrows flagged
find_catch_blocks — Every catch for a type, optionally via base clauses; flags filtered, rethrowing, and empty (swallowing) handlers
find_references — Find all references to any symbol (types, methods, properties, fields, events), each tagged with a kind (read, write, readwrite, invocation, method_group, object_creation, cast, type_check, typeof, base_type, type_constraint, type_argument, declaration, attribute, nameof, xml_doc) and reported per occurrence with a column; filter server-side with kinds (e.g. ["write","readwrite"] for mutation sites)
go_to_definition — Find the source file and line where a symbol is defined
get_method_source — Full declaration source (XML docs, attributes, signature, body — original formatting) for one or many members by name in a single call: methods (all overloads), constructors, properties, indexers, fields, events; per-item statuses (ok/notFound/ambiguous/metadata/unsupportedKind) so a batch never fails wholesale
resolve_stack_trace — Map a pasted .NET stack trace to file/line/symbol, undoing compiler name mangling (async/iterator state machines, lambdas, local functions, generic arity); handles inner-exception chains, log-prefixed lines, and Demystifier traces
get_diagnostics — List compiler errors, warnings, and Roslyn analyzer diagnostics
get_code_fixes — Get available code fixes with structured text edits for any diagnostic
search_symbols — Fuzzy workspace symbol search by name
get_nuget_dependencies — List NuGet package references per project
find_attribute_usages — Find types and members decorated with a specific attribute
find_obsolete_usage — Every [Obsolete] call site grouped by deprecation message and severity, errors first; for planning migrations
find_circular_dependencies — Detect cycles in project or namespace dependency graphs
check_architecture — Enforce layering rules you supply (forbid and allowOnly) against the real semantic type graph rather than using directives; violations are grouped per boundary with a reference count and example sites
get_complexity_metrics — Cyclomatic complexity, cognitive complexity and max nesting depth per member (methods, constructors, properties, indexers, operators). Cyclomatic counts paths and starts at 1; cognitive measures how hard the code is to follow and starts at 0. metric picks which one the threshold and sort use — cognitive is the better refactoring-priority signal, cyclomatic the better test-budget one
find_naming_violations — Check .NET naming convention compliance
find_async_violations — Sync-over-async, async void misuse, missing awaits, fire-and-forget tasks; per-violation report with severity
find_disposable_misuse — IDisposable/IAsyncDisposable instances not wrapped in using/await using/returned/assigned to field; severity error/warning per violation.
find_large_classes — Find oversized types by member or line count
find_god_objects — Types combining high size with high cross-namespace coupling; sharper signal than raw size for SRP violations
find_unused_symbols — Dead code detection via reference analysis. Auto-filters test methods (xUnit/NUnit/MSTest), MCP tool entry points, source-generator output, MEF-composed services, and interop-laid-out fields; filter counts surface in summary.filteredOut
get_project_health — Composite audit aggregating 7 quality dimensions per project (complexity, large classes, naming, unused symbols, reflection, async violations, disposable misuse) with counts and top-N hotspots inline
get_source_generators — List source generators and their output per project
get_generated_code — Inspect generated source code from source generators
inspect_external_assembly — Browse types, members, and XML docs from closed-source NuGet packages and referenced assemblies
peek_il — Decompile any method to ilasm-style IL bytecode from closed-source or generated assemblies
get_code_actions — Discover available refactorings and fixes at any position (extract method, rename, inline variable, and more)
apply_code_action — Execute any Roslyn refactoring by title, with preview mode (returns a diff before writing to disk)
rename_symbol — Solution-wide safe rename of a type or member via Roslyn's Renamer, with preview mode, conflict reporting, and a freshness check against on-disk edits
change_signature — Add, remove, and reorder a method's parameters and rewrite every call site; handles named/optional arguments, params and extension methods, and reports the overrides and interface implementations it cascaded to
list_solutions — List all loaded solutions and which one is currently active
set_active_solution — Switch the active solution by partial name (all subsequent tools operate on it)
load_solution — Load an additional .sln/.slnx at runtime and make it the active solution
unload_solution — Unload a loaded solution to free memory
rebuild_solution — Force a full reload of the analyzed solution
start_background_task — Queue a long-running tool (currently rebuild_solution) to run in the background; returns a taskId to poll
get_task_status — Get the current status, result, or error of a background task by its taskId
list_running_tasks — List background tasks running or completed within the last 5 minutes
trust_solution — Authorize a solution to run Roslyn analyzers (required before get_diagnostics with includeAnalyzers: true)
list_trusted_paths — Inspect the persistent trust store + session-trusted solutions
revoke_trust — Revoke a previously-granted trust for a solution path
analyze_data_flow — Variable read/write/capture analysis within a statement range (declared, read, written, always assigned, captured, flows in/out)
analyze_control_flow — Branch/loop reachability analysis within a statement range (start/end reachability, return statements, exit points)
analyze_change_impact — Show all files, projects, and call sites affected by changing a symbol — combines find_references and find_callers
get_type_overview — Compound tool: type context + hierarchy + file diagnostics in one call
analyze_method — Compound tool: method signature + callers + outgoing calls in one call
get_overloads — Every overload of a method/constructor (source + metadata) with full parameter and modifier detail in one call
get_extension_methods — Every extension member applicable to a type — including arrays, nullables and tuples — from the solution and referenced assemblies (so LINQ shows up), using Roslyn's own applicability rules; covers C# 14 extension blocks including properties and static members
get_operators — Every user-defined operator and conversion operator on a type (source + metadata) with kind, signature, parameters, and source location. Includes synthesized record equality and .NET 7+ checked variants
get_call_graph — Transitive caller/callee graph for a method, depth-bounded with cycle detection
get_file_overview — Compound tool: types defined in a file + file-scoped diagnostics in one call
All list-returning tools wrap their results in a uniform envelope:
{
"items": [ ... ],
"totalCount": 142,
"truncated": false,
"limit": 500,
"summary": { ... }
}When truncated is true, the items are the top N by the tool's natural sort order (severity-first, worst-first, by-project, etc.) — usually that's exactly what you want. Raise limit only if the missing tail items matter for the task.
Tools that include a summary aggregate today:
get_diagnostics — { error, warning, info, hidden } counts
find_references — { byProject: { name: count }, byKind: { kind: count } }
find_callers, find_attribute_usages — { byProject: { name: count } }
search_symbols, find_reflection_usage — { byKind: {...} }
find_unused_symbols — { byKind, filteredOut: { testMethod, testContainer, mcpTool, generated, composition, interop } }
find_naming_violations — { byRule: {...} }
get_complexity_metrics — { max, avg, overThreshold, maxCognitive } (the first three describe the selected metric)
Single-object tools (get_type_overview, get_symbol_context, apply_code_action, etc.) return their bespoke shape directly — the envelope only wraps list-returning tools.
When a tool can't proceed (symbol not resolved, solution not trusted, file not found, ambiguous match, etc.), the response is an isError: true content block carrying a structured JSON body:
{
"code": "SolutionNotTrusted",
"message": "Solution 'Foo.sln' is not trusted for analyzer execution. ...",
"details": { "solutionPath": "C:\\Foo.sln" }
}Error codes (switch on code to handle each):
SymbolNotFound — type / method / property could not be resolved.
SolutionNotTrusted — get_diagnostics or get_code_fixes requested analyzers but the solution hasn't been authorized via trust_solution.
AmbiguousMatch — set_active_solution / unload_solution matched multiple solutions; details.matches lists them.
FileNotFound — file path or baseline doesn't exist (or isn't in any loaded project).
ProjectNotFound — solution name didn't match any loaded solution.
InvalidArgument — caller-supplied input was malformed, unsupported, or out of range.
Internal — unexpected error not modeled above; message carries the underlying exception text.
Cancellation: the MCP framework's native cancellation is honored. Cancelling a tools/call request mid-flight terminates the operation; long-running tools (get_diagnostics with analyzers, get_code_actions, apply_code_action, get_code_fixes) check the token at hot-loop boundaries.
Metadata-origin symbols (from NuGet packages and referenced assemblies) are first-class citizens:
Tier 1 — Navigation (find_references, find_callers, find_implementations): Accepts closed-source type and member names. Resolves them from assembly metadata and reports all source-level usage sites.
Tier 2 — Inspection (inspect_external_assembly): Browse namespaces, types, members, and XML doc comments from any referenced assembly without decompiling.
Tier 3 — IL (peek_il): Decompile a specific method to annotated ilasm-style IL using ICSharpCode.Decompiler — useful for understanding the internals of NuGet libraries.
Location-returning results include an Origin field (source or metadata) and an IsGenerated flag to distinguish hand-written code from closed-source or generated output.
ROSLYN_CODELENS_OPEN_PROJECT_TIMEOUT_SECONDS — per-project MSBuild load timeout (default 300). When a project exceeds this duration during workspace open, it's recorded as a SkippedProjects entry with kind: "Timeout" and the rest of the solution still loads. Useful when a legacy or malformed project wedges the BuildHost-net472 subprocess.
get_diagnostics and get_code_fixes can load Roslyn analyzers — DLLs that execute in-process. To prevent untrusted analyzers from running automatically, this server uses a VS/Rider-style trust model:
Solutions passed on the CLI at startup are auto-trusted for the current session.
Other solutions must be explicitly trusted via the trust_solution MCP tool.
Analyzer DLLs must come from the user's NuGet global packages folder, the dotnet SDK install dir, or the solution's own bin/obj. Other paths are skipped.
Use the list_trusted_paths and revoke_trust tools to inspect and manage trust state. Persistent trust is stored at %APPDATA%\roslyn-codelens\trust.json.
See SECURITY.md for the full threat model.
{
"mcpServers": {
"roslyn-codelens": {
"type": "stdio",
"command": "npx",
"args": ["-y", "roslyn-codelens-mcp"]
}
}
}The npm package ships no server code — it is a launcher that installs the RoslynCodeLens.Mcp
.NET global tool at a matching version and execs it, so the .NET 10 SDK must be on PATH.
Subsequent starts skip the install entirely and work offline.
Add to your MCP settings (.vscode/mcp.json or VS settings):
{
"servers": {
"roslyn-codelens": {
"type": "stdio",
"command": "dnx",
"args": ["RoslynCodeLens.Mcp", "--yes"]
}
}
}claude install gh:MarcelRoozekrans/roslyn-codelens-mcpdotnet tool install -g RoslynCodeLens.McpThen add to your MCP client config:
{
"mcpServers": {
"roslyn-codelens": {
"command": "roslyn-codelens-mcp",
"args": [],
"transport": "stdio"
}
}
}Runs without a .NET SDK on the host; the solution is bind-mounted at /workspace.
docker build -t roslyn-codelens-mcp .
docker run -i --rm -v "$PWD:/workspace" roslyn-codelens-mcpThe mounted solution must be restored for MSBuildWorkspace to resolve its
references, and tool output reports container paths rather than host paths — see
docs/site/docs/getting-started/docker.md.
The server automatically discovers .sln files by walking up from the current directory. You can also pass one or more solution paths directly:
# Single solution
roslyn-codelens-mcp /path/to/MySolution.sln
# Multiple solutions — switch between them with set_active_solution
roslyn-codelens-mcp /path/to/A.sln /path/to/B.slnWhen multiple solutions are loaded, use list_solutions to see what's available and set_active_solution("B") to switch context. The first path is active by default.
By default the server speaks stdio. Pass --http to expose the same tools over
streamable HTTP instead — useful for
one long-lived server (warm Roslyn workspace, no per-client startup cost) shared by several
local MCP clients:
roslyn-codelens-mcp /path/to/MySolution.sln --http # http://127.0.0.1:3001
roslyn-codelens-mcp /path/to/MySolution.sln --http --port 8080{
"mcpServers": {
"roslyn-codelens": {
"type": "http",
"url": "http://127.0.0.1:3001"
}
}
}The HTTP endpoint binds to 127.0.0.1 only and is intended for single-user, local use: all
connected clients share the same solution state (set_active_solution affects everyone), and
there is no authentication. --host can widen the binding, but the server will warn — its tools
can read and modify source files, so only do this on networks you fully trust.
All type lookups use pre-built reverse inheritance maps, member indexes, and attribute indexes for O(1) access. Benchmarked on an i9-12900HK with .NET 10.0.7:
Tool | Latency | Memory |
| 2.1 µs | 576 B |
| 2.5 µs | 720 B |
| 2.8 µs | 1.5 KB |
| 3.5 µs | 1.3 KB |
| 3.7 µs | 2.7 KB |
| 4.1 µs | 1.0 KB |
| 16 µs | 23 KB |
| 19 µs | 1.6 KB |
| 72 µs | 904 B |
| 78 µs | 24 KB |
| 115 µs | 14 KB |
| 159 µs | 35 KB |
| 265 µs | 3.5 KB |
| 478 µs | 16 KB |
| 564 µs | 259 KB |
| 705 µs | 19 KB |
| 781 µs | 25 KB |
| 792 µs | 54 KB |
| 797 µs | 101 KB |
| 822 µs | 99 KB |
| 849 µs | 48 KB |
| 885 µs | 247 KB |
| 1.1 ms | 104 KB |
| 1.1 ms | 34 KB |
| 3.5 ms | 286 KB |
| 3.8 ms | 224 KB |
| 3.9 ms | 557 KB |
| 5.8 ms | 333 KB |
| 7.0 ms | 335 KB |
| 8.4 ms | 396 KB |
| 10 ms | 337 KB |
| 12 ms | 399 KB |
| 15 ms | 788 KB |
| 23 ms | 1.0 MB |
| 28 ms | 1013 KB |
| 33 ms | 1.3 MB |
Solution loading (one-time) | ~4.1 s | 16 MB |
The server watches .cs, .csproj, .props, and .targets files for changes. When a change is detected, affected projects are lazily re-compiled on the next tool query — only stale projects and their downstream dependents are re-compiled, not the full solution.
Location-returning tools include an IsGenerated flag to distinguish source-generator output from hand-written code.
.NET 10 SDK
A .NET solution with compilable projects
The server analyses every project that MSBuildWorkspace can load under the .NET SDK runtime.
Supported: SDK-style projects (<Project Sdk="...">), any target framework — net48, net6.0, net8.0, net10.0, etc. .NET Framework targets work fine as long as the csproj uses the SDK-style format.
Skipped (with a warning, not a crash): legacy non-SDK-style projects (<Project ToolsVersion="..." xmlns="http://schemas.microsoft.com/developer/msbuild/2003">, typically .NET Framework projects authored in older versions of Visual Studio). These rely on Microsoft.Common.props imports from the .NET Framework MSBuild that ships with Visual Studio, which is not available in the .NET SDK MSBuild runtime.
When a solution contains legacy projects, the server:
Loads every SDK-style project normally — all tools work for those.
Skips each legacy project and records it in LoadedSolution.SkippedProjects.
Surfaces the skipped list via list_solutions (the SkippedProjects array on each SolutionInfo) and in the return message of load_solution. Each entry includes the project name, kind (Legacy), and reason.
To analyse a legacy project, convert it to SDK-style format (see Microsoft's migration guide) or open the solution from a Visual Studio Developer Command Prompt so the full Visual Studio MSBuild is on PATH.
dotnet build
dotnet test
dotnet run --project benchmarks/RoslynCodeLens.Benchmarks -c ReleaseICSharpCode.Decompiler — MIT license (v8+). Used for IL disassembly in the peek_il tool.
MIT
Analyze the blast radius of changing a symbol — shows every file, project, and call site affected. Combines find_references and find_callers into a single impact summary. Use before renaming, changing signatures, or removing a type/method.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Symbol name to analyze (type name, 'Type.Method', etc.) |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Analyze control flow within a range of statements in a C# method. Returns reachability of start/end points, return statements, and exit points. Useful for detecting unreachable code and understanding branching.
| Name | Required | Description | Default |
|---|---|---|---|
| endLine | Yes | Last line of the statement range (1-based) | |
| filePath | Yes | Full path to the C# source file | |
| startLine | Yes | First line of the statement range (1-based) |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Analyze data flow within a range of statements in a C# method. Returns variables declared, read, written, captured by lambdas, and flowing in/out of the region. Useful for understanding variable lifecycle before extracting code.
| Name | Required | Description | Default |
|---|---|---|---|
| endLine | Yes | Last line of the statement range (1-based) | |
| filePath | Yes | Full path to the C# source file | |
| startLine | Yes | First line of the statement range (1-based) |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Get a comprehensive analysis of a method in one call: signature, location, all callers, and all outgoing calls (methods this method invokes). More efficient than calling find_callers separately.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Method symbol (e.g. 'Greeter.Greet' or 'MyNamespace.MyClass.MyMethod') |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Apply a code action (refactoring or fix) by its title. Use get_code_actions first to discover available actions. Defaults to preview mode (returns diff without writing files). Set preview=false to apply changes to disk.
| Name | Required | Description | Default |
|---|---|---|---|
| line | Yes | Line number (1-based) | |
| column | Yes | Column number (1-based) | |
| endLine | No | End line for text selection (1-based, optional) | |
| preview | No | Preview only — return diff without writing to disk (default: true) | |
| filePath | Yes | Full path to the C# source file | |
| endColumn | No | End column for text selection (1-based, optional) | |
| actionTitle | Yes | Exact title of the code action to apply (from get_code_actions) |
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.
Is 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema, the description covers 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema 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.
Does 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.
Does 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.
Add, remove, or reorder a method's parameters and update every call site (Roslyn's own change-signature engine). Cascades to overrides and interface implementations, rewrites named and optional arguments, and preserves an extension method's this parameter; the overrides and implementations it also rewrote are listed in CascadedTo. Operations apply in order: remove drops parameter; reorder takes order, a full permutation of the parameters surviving at that point; add appends name plus type and REQUIRES callSiteValue — the expression every existing call site will pass, since the tool never guesses call-site semantics — with an optional defaultValue that instead makes the parameter optional and leaves existing calls untouched. Rejected as unsafe: an added name that is not a valid C# identifier or collides with an existing parameter; a type that does not resolve, or resolves ambiguously (qualify it); moving or removing an extension method's this parameter (it must stay first); and any signature that would leave a surviving params array anywhere but last — add the parameter and reorder it before the params array, or remove that array. Defaults to preview mode (returns edits without writing files); set preview=false to apply. New compiler errors the change would introduce are reported as Conflicts, and apply mode refuses to write them unless force=true. Source-defined methods only; overloaded names must be disambiguated.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Apply even when Conflicts are reported (default: false) | |
| method | Yes | Method to change: `MyClass.MyMethod` or fully qualified `Namespace.MyClass.MyMethod` | |
| preview | No | Preview only — return edits without writing to disk (default: true) | |
| operations | Yes | Parameter edits applied in order. Each has `kind` (`remove`, `reorder` or `add`) plus: `parameter` for `remove`; `order` for `reorder`; `name`, `type`, `callSiteValue` and optional `defaultValue` for `add` |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Check user-supplied layering rules against the solution's real semantic type graph (resolved symbols, not using directives — so a fully qualified reference with no using is still caught, and an unused using is not reported). Rule kinds: forbid (a dependency from from to to is a violation) and allowOnly (a dependency from from to anything outside to is a violation). TWO SEMANTICS YOU MUST KNOW TO READ AN EMPTY RESULT CORRECTLY. (1) allowOnly evaluates ONLY solution-internal, non-generated targets: references to framework and NuGet namespaces such as System.Collections.Generic are ignored (otherwise every file would violate every allowOnly rule), and so are types declared entirely in generated code, which the caller cannot remove. To restrict a framework or generated namespace, write an explicit forbid — that path DOES evaluate metadata and generated targets. (2) Self-references are always allowed: a scope depending on itself is never a violation, under either kind. Results are grouped per violated rule plus sourceScope plus targetScope edge, each with a full referenceCount and the first maxSitesPerViolation sites. Sorted by rule order, then by descending reference count. Generated code is never reported as the SOURCE of a violation under either kind. Envelope adds a byRule / totalReferences / rulesEvaluated summary.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (default: 100). Items are sorted by rule order, then by descending reference count. | |
| rules | Yes | Layering rules to evaluate, in priority order. Each is `kind` (`forbid` or `allowOnly`), `from`, `to` (array of patterns), and an optional `description`. | |
| scope | No | Scope compared by the rules: `namespace` (default) or `project`. | namespace |
| maxSitesPerViolation | No | Maximum example sites recorded per violated edge (default: 5). The full reference count is reported regardless. |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Detect six classes of async/await misuse across all production projects: sync-over-async (.Result, .Wait*, GetAwaiter().GetResult()), async void outside event handlers, missing await in async methods, and fire-and-forget tasks. Returns a summary plus a per-violation list (severity error/warning, location, containing method, snippet). Skips test projects and generated code. Static analysis only — no fix suggestions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Find all types and members decorated with a specific attribute (e.g., Obsolete, Authorize, Serializable). Returns an envelope with items, totalCount, truncated, limit, and a byProject summary.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (default: 500). Items are sorted by file, then line. | |
| attribute | Yes | Attribute name to search for (with or without 'Attribute' suffix) |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Diff the current solution's public API surface against a baseline (JSON snapshot from a prior get_public_api_surface run, or a baseline .dll file). Reports five change kinds: Removed/KindChanged/AccessibilityNarrowed (Breaking) plus Added/AccessibilityWidened (NonBreaking). Returns a summary plus a per-change list (kind, severity, fully-qualified name, entity kind, project, file, line, details). Sort: Breaking before NonBreaking, then name ASC. Limitations: return type changes, sealed-ness changes, and nullable annotation changes are not detected (PublicApiEntry schema doesn't capture them).
| Name | Required | Description | Default |
|---|---|---|---|
| baselinePath | Yes | Path to a baseline .json snapshot (from a prior get_public_api_surface call) or a baseline .dll file. |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Find every call site for a method. Returns an envelope with items, totalCount, truncated, limit, and a byProject summary.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (default: 500). Items are sorted by file, then line. | |
| symbol | Yes | Method name as Type.Method (simple or fully qualified) |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Find the catch clauses that handle an exception type across the solution, and say what each one does with it. Each item reports hasFilter (a when clause, so the handler may decline at runtime), rethrows (the body contains a bare throw;) and isEmpty (an empty handler body) — together these answer 'who is silently swallowing this exception?' in a single call. By default only clauses declaring exactly the requested type match; set includeBaseClauses to also surface handlers that catch a base type, including catch (Exception) and bare catch, since those bind the requested type too. caughtType is null for a bare catch. The exception type may live in source or in metadata. Returns an envelope with items, totalCount, truncated, limit and a byType / byProject summary, sorted by file, line, column.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (default: 500). | |
| exceptionType | Yes | Exception type to search for (e.g. `System.IO.IOException` or `MyApp.DomainException`). | |
| includeBaseClauses | No | Also match clauses catching a base type of the requested one, including bare `catch`. Default false. |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Detect circular dependencies in the project reference graph or namespace dependency graph. Returns an envelope with items sorted by cycle length desc, totalCount, truncated, and limit (default 100).
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Level: 'project' or 'namespace' (default: project) | project |
| limit | No | Maximum number of items to return (default: 100). Items are sorted by cycle length desc. |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Detect IDisposable / IAsyncDisposable instances at risk of leaking. Two patterns: local variables holding a disposable that aren't wrapped in using/await using/returned/assigned-to-field-or-out-parameter (warning), and bare-expression-statement discards of a disposable creator/factory (error). Returns a summary plus a per-violation list (severity error/warning, location, containing method, snippet). Skips test projects and generated code. Scope: methods only (not constructors/accessors/operators); ownership transfer via method/constructor argument is not detected. Static analysis only — no fix suggestions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Find every += and -= site for an event symbol across the solution. Accepts source events (e.g. 'MyClass.Clicked') or metadata events (e.g. 'System.Diagnostics.Process.Exited'). Each result reports the source location, the resolved handler (method FQN, or a synthetic name like 'lambda at File.cs:N' for inline handlers), and the subscription kind (Subscribe for +=, Unsubscribe for -=). Use this for memory-leak audits (compare subscribe/unsubscribe pairs), UI event subscriber inspection, or when Grep over '+= EventName' would miss qualified or fully-typed subscription sites. Returns an envelope with items sorted by file path then line, totalCount, truncated, and limit (default 500).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (default: 500). Items are sorted by file path, then line. | |
| symbol | Yes | Event symbol (e.g. 'MyClass.Clicked' or 'System.Diagnostics.Process.Exited') |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Find types that combine high size with high coupling — 'god classes' that violate single-responsibility and become refactoring nightmares. Sharper signal than find_large_classes alone: a 1000-line internal helper used only by its own namespace is not flagged, but a 200-line class called from 15 different namespaces is. Two axes: size (lines/members/fields) and coupling (incoming/outgoing namespace counts). A type qualifies when it crosses ALL THREE size thresholds AND at least one coupling threshold — keeps DTOs (high field count only) and dispatchers (high member count only) off the list. Defaults: lines >= 300, members >= 15, fields >= 10, incoming-namespaces >= 5, outgoing-namespaces >= 5. Each threshold is independently configurable. BCL namespaces (System., Microsoft.) excluded from outgoing count. Test projects, generated code, interfaces, and nested types are skipped. Sort: total axes exceeded DESC, then line count DESC.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Optional: restrict to a single project by name (case-insensitive). | |
| minLines | No | Min lines for size axis. Default 300. | |
| minFields | No | Min field count for size axis. Default 10. | |
| minMembers | No | Min member count for size axis. Default 15. | |
| minIncomingNamespaces | No | Min incoming-namespace count for coupling axis. Default 5. | |
| minOutgoingNamespaces | No | Min outgoing-namespace count for coupling axis. Default 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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Find all classes/structs implementing an interface or extending a class. Returns an envelope with items, totalCount, truncated, and limit.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (default: 200). Items are sorted by file, then line. | |
| symbol | Yes | Type name (simple or fully qualified) |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. 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.
Find classes and structs that exceed member count or line count thresholds. Returns an envelope with items sorted worst-first (highest size first), totalCount, truncated, and limit (default 100).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (default: 100). Items are sorted by size desc (worst first). | |
| project | No | Optional project name filter | |
| maxLines | No | Maximum lines before flagging (default: 500) | |
| maxMembers | No | Maximum members before flagging (default: 20) |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Check .NET naming convention compliance: PascalCase types/methods/properties, camelCase parameters, I-prefix interfaces, _ prefix private fields. Returns an envelope with items, totalCount, truncated, limit (default 500), and a byRule summary.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (default: 500). Items are sorted by rule, then file. | |
| project | No | Optional project name filter |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Find every call site referencing [Obsolete]-marked symbols in the solution, grouped by deprecation message and severity. Sharper than find_attribute_usages for migration-planning workflows: tells you 'we have 5 distinct deprecations pending; this one has 80 sites and is an error; that one has 3 sites and is a warning.' Includes both source-marked and metadata-marked obsoletes (third-party NuGet deprecations are surfaced too). Symbols with zero usages are omitted (no migration needed). Sort: errors first, then by usage count descending, then by symbol name. Test projects skipped. Project filter is case-insensitive.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Optional: restrict to a single project by name (case-insensitive). | |
| errorOnly | No | If true, only [Obsolete(..., true)] error-level deprecations are returned. Default false. |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Find all references to a symbol (type, method, property, field, or event) across the solution, each tagged with a kind. Kinds: read, write, readwrite (compound assignment / ++ / ref), invocation, method_group, object_creation, cast, type_check (is / patterns / as-tests), typeof, base_type, type_constraint, type_argument, declaration, attribute, nameof, xml_doc, and usage (rare fallback). Pass kinds to return only some (e.g. ["write","readwrite"] for mutation sites). Envelope adds a byKind summary. Multiple references on one line are reported separately with a column.
| Name | Required | Description | Default |
|---|---|---|---|
| kinds | No | Optional kind filter - only references of these kinds are returned (see the kind list above) | |
| limit | No | Maximum number of items to return (default: 500). Items are sorted by file, line, column. | |
| symbol | Yes | Symbol name: simple type (`MyClass`), fully qualified (`Namespace.MyClass`), or member (`MyClass.MyProperty`) |
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.
Is 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains output 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.
Does 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds all references to a symbol across the 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.
Does 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.
Detect dynamic/reflection-based usage like Type.GetType, Activator.CreateInstance, MethodInfo.Invoke. Returns an envelope with items, totalCount, truncated, limit (default 500), and a byKind summary.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (default: 500). Items are sorted by file, then line. | |
| symbol | No | Optional type name to filter results (omit to scan entire solution) |
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.
Is 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.
Given 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, 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.
List test methods that exercise the given production symbol. Recognises xUnit, NUnit, and MSTest. Set transitive=true to follow helper methods up to maxDepth levels (default 3, max 5).
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Symbol name as Type.Method (simple or fully qualified) | |
| maxDepth | No | Maximum walk depth when transitive=true. Clamped to [1, 5]. Default 3. | |
| transitive | No | Walk through helper methods to find indirect tests. Default false. |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Find every place an exception type is thrown across the solution — throw new T(...), throw expr; and bare throw; rethrows (whose type comes from the enclosing catch). The exception type may live in source or in metadata, so System.ArgumentNullException works as well as your own MyApp.DomainException. Set includeDerived to also match subclasses of the requested type. Every throw in the file is reported, including throws inside lambdas and local functions, attributed to the member that contains them — use get_exception_flow instead when the question is which exceptions escape a specific method. Returns an envelope with items, totalCount, truncated, limit and a byType / byProject summary, sorted by file, line, column.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (default: 500). | |
| exceptionType | Yes | Exception type to search for (e.g. `System.InvalidOperationException` or `MyApp.DomainException`). | |
| includeDerived | No | Also match types deriving from the requested one. Default false (exact type only). |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use 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.
Report public methods and properties that no test method transitively reaches (within 3 helper hops). Output sorted by cyclomatic complexity descending, with a coverage summary including a riskHotspotCount (uncovered with complexity >= 5). Recognises xUnit, NUnit, MSTest. Reference-based static analysis — does not parse runtime coverage data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Find potentially unused types and members (dead code detection). Checks public symbols for references across the solution. Filters out test methods, MCP tools, source-generator output, MEF-composed services, and interop-laid-out fields. Returns an envelope with items, totalCount, truncated, limit (default 500), and a summary including byKind + filteredOut counts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (default: 500). Items are sorted by project, then file. | |
| project | No | Optional project name filter | |
| includeInternal | No | Include internal symbols (default: false) |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Emits a test-class skeleton (parseable C#) for a method or type. Pass a type FQN like 'MyApp.Services.OrderService' to get a full test class with one stub per public method, or a method FQN like 'MyApp.Services.OrderService.PlaceOrder' to get a single stub. Returns framework, suggested file path, class name, full file contents (as text), and TodoNotes for things to wire up (e.g. constructor dependencies). The tool does NOT write to disk — agent decides what to do with the text. Pairs naturally with find_uncovered_symbols / get_test_summary. Stubs include happy-path Fact, Theory + InlineData for primitive-param methods, and Assert.Throws assertions per distinct direct-throw exception type. Async (Task-returning) methods detected automatically. Properties, indexers, operators, and constructors are excluded from per-method enumeration. Framework auto-detected from solution test projects (tie → xUnit); override with framework='xunit' / 'nunit' / 'mstest'.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | FQN of a type or method to generate a test skeleton for. | |
| framework | No | Optional framework override: 'xunit', 'nunit', or 'mstest'. Auto-detected if null. |
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.
Is 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains the return 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.
Does 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.
Does 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.
Does 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.
Transitive caller and/or callee graph for a method symbol, depth-bounded with cycle detection. Output is an adjacency-list dict per direction (callees and/or callers), where each visited symbol maps to its outgoing edges. Direction: 'callees' (what this method transitively calls), 'callers' (who reaches this method), or 'both'. External (BCL/NuGet) callees appear as terminal leaves with isExternal=true. Declared signature only on callee side — no virtual dispatch resolution; agent uses find_implementations separately if needed. Callers side resolves dispatch naturally via Roslyn SymbolFinder. Hard cap on total visited nodes (default 500) — sets truncated=true if hit; edges to truncated targets are still recorded against the source node. Use this instead of recursive find_callers / analyze_method calls when you need depth > 1.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Method symbol (e.g. 'Greeter.Greet' or 'MyNamespace.MyClass.MyMethod') | |
| maxDepth | No | Max traversal depth from root. Default 3. | |
| maxNodes | No | Hard cap on total visited nodes. Default 500. | |
| direction | No | 'callees' (default), 'callers', or 'both'. | callees |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
List available code actions (refactorings and fixes) at a position in a C# file. Optionally specify endLine/endColumn to select a range for extract-method style refactorings. Returns action titles that can be passed to apply_code_action. Returns an envelope with items sorted by kind then title, totalCount, truncated, and limit (default 100).
| Name | Required | Description | Default |
|---|---|---|---|
| line | Yes | Line number (1-based) | |
| limit | No | Maximum number of items to return (default: 100). Items are sorted by kind then title. | |
| column | Yes | Column number (1-based) | |
| endLine | No | End line for text selection (1-based, optional) | |
| filePath | Yes | Full path to the C# source file | |
| endColumn | No | End column for text selection (1-based, optional) |
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.
Is 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.
Given 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value by 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.
Does 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.
Does 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.
Get available code fixes for a specific diagnostic at a file location. Returns structured text edits that can be reviewed and applied. Returns an envelope with items sorted by title, totalCount, truncated, and limit (default 100).
| Name | Required | Description | Default |
|---|---|---|---|
| line | Yes | Line number where the diagnostic occurs | |
| limit | No | Maximum number of items to return (default: 100). Items are sorted by title. | |
| filePath | Yes | Full path to the source file | |
| diagnosticId | Yes | Diagnostic ID (e.g., 'CA1822', 'CS0168') |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Calculate complexity for members (methods, constructors, properties, indexers, operators). Reports both 'complexity' (cyclomatic - the number of paths, starts at 1) and 'cognitive' (how hard the code is to follow, starts at 0 - a 0 is not a bug), plus 'maxNesting'. The 'metric' parameter selects which of the two the threshold filters on and the sort uses. Returns an envelope with items sorted worst-first, totalCount, truncated, limit (default 100), and a summary with max/avg/overThreshold plus maxCognitive.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (default: 100). Items are sorted by the selected metric desc (worst first). | |
| metric | No | Which metric drives the threshold and the sort: 'cyclomatic' (default) or 'cognitive'. Both are always reported. | cyclomatic |
| project | No | Optional project name filter | |
| threshold | No | Minimum complexity threshold, applied to the selected metric (default: 10) |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
List compiler errors and warnings across the solution, optionally including analyzer diagnostics. Analyzer diagnostics require the solution to be trusted (see 'trust_solution'). Returns an envelope with items, totalCount, truncated, limit, and a severity summary.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (default: 1000). Items are sorted severity-desc, then file, then line. | |
| project | No | Optional project name filter | |
| severity | No | Minimum severity: 'error' or 'warning' (default: warning) | |
| includeAnalyzers | No | Include analyzer diagnostics (default: false — requires trust_solution to be called first) |
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.
Is 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds 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.
Does 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.
Does 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.
Scan IServiceCollection extension methods for DI registrations of a type. Returns an envelope with items sorted by service name, totalCount, truncated, and limit (default 200).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (default: 200). Items are sorted by service name. | |
| symbol | Yes | Type name to search for (simple or fully qualified) |
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.
Is 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.
Given 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (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.
Which exceptions can escape a method — the 'is calling this safe?' question. Walks the method's callees depth-first (cycle-safe, depth- and node-bounded) collecting every explicit throw, then propagates each one back up the call chain, testing the enclosing try/catch at the throw and at every call site on the way out. Each item reports escapes, the path of methods from the analysed method to the one that raises it, and — when it is stopped — caughtIn, caughtFile, caughtLine. A handler with a when filter sets hasFilter and the exception is still reported as escaping, because the filter may decline at runtime. origin is thrown for a real throw site in source, or documented for an exception XML doc tag on a metadata (BCL/NuGet) callee — set includeDocumented to false to drop the latter. Throws inside lambdas and local functions are excluded: they escape when that body runs, not at this method's boundary — use find_throw_sites for a plain textual scan of throws. Static analysis only: no reflection, no virtual-dispatch resolution, and no implicit runtime failures such as null dereferences. Hitting maxDepth or maxNodes sets truncated.
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | Method symbol to analyse (e.g. `OrderService.Place` or `MyNamespace.MyClass.MyMethod`). | |
| maxDepth | No | Max callee depth to walk from the analysed method. Default 3. | |
| maxNodes | No | Hard cap on methods visited. Default 500. | |
| includeDocumented | No | Include exceptions documented by `exception` XML tags on metadata callees. Default true. |
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.
Is 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.
Given 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool vs alternatives: 'use 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.
Answer 'what extension members can I call on this type?' — every extension method and C# 14 extension property applicable to a receiver type, from solution source AND referenced metadata (so BCL LINQ such as Where, Select, Chunk is included). Applicability is decided by the compiler's own reduction, not by name matching: this IEnumerable<T> is reported for string (which is IEnumerable<char>) while this IEnumerable<string> is not. Each entry carries the reduced call-site signature (receiver dropped, generic inference applied, return type first: IEnumerable<int> Where<int>(Func<int, bool>), int Tripled), kind (method or property), declaring type, namespace, origin (source or metadata), source file/line for source members, XML doc summary, and isStatic. Read isStatic before writing the call: false means an instance call (value.Doubled()) and is the normal case even though every extension method is DECLARED static; true means a C# 14 static extension member, called on the type itself (int.Zero). Results are NOT filtered by using scope — the tool has no call-site position, so every applicable member is reported and its namespace is given for you to add the import. Pass a type name: simple (Widget), fully qualified (MyApp.Widget), a C# keyword (int, string), a constructed generic (List<int>), an array (string[]), a nullable (int?), or a tuple ((int, string)). Sort: source before metadata, then declaring type, then name.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Receiver type — e.g. `Widget`, `MyApp.Widget`, `int`, `List<int>`, `string[]`, `int?`, `(int, string)` | |
| limit | No | Maximum number of items to return (default: 100) | |
| nameFilter | No | Optional case-insensitive substring filter on the member name — e.g. `chunk` |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Get a summary of a C# file: which types are defined in it and any compiler diagnostics. Useful for quickly understanding a file's contents without reading it. Also accepts .razor/.cshtml markup, resolving it to the C# document its source generator produced.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Full path to the source file (.cs, or .razor/.cshtml) |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Inspect generated source code from source generators. Returns an envelope with items sorted by project then file path, totalCount, truncated, and limit (default 200).
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | File path (or partial match) to filter by | |
| limit | No | Maximum number of items to return (default: 200). Items are sorted by project, then file path. | |
| generator | No | Generator name to filter by |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Answer 'how do I construct this type?' in one call — accessible constructors, static factory methods declared anywhere in the solution, and DI registrations. Constructors report every parameter's type and name, declared accessibility, whether the constructor is compiler-supplied (isImplicit — a struct or a class with no declared constructor still has a usable parameterless one), and whether it is obsolete. Factories are static members returning the type, including ones declared on a DIFFERENT type such as WidgetFactory.Create(), with Task<T>/ValueTask<T> unwrapped and flagged isAsync. Instance builder methods are excluded because the builder itself would need constructing. Pass fromProject to get accessible computed for that project, which honours InternalsVisibleTo — this is how you find out whether your test project can reach an internal constructor. Without it, accessible is null, meaning NOT COMPUTED — which is not the same as false, so do not read a null as 'you cannot call this'. requiredMembers lists members that must be set in an object initializer. diRegistrations shows where the type is registered in a container — a registered type is usually meant to be resolved rather than constructed by hand. For interfaces, abstract classes and static classes, instantiable is false and note explains why; use find_implementations to find concrete types.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Type to construct — simple (`Widget`) or fully qualified (`MyApp.Widget`). | |
| fromProject | No | Optional project name whose viewpoint decides `accessible` (e.g. `MyApp.Tests`). |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Return the full declaration source (XML docs, attributes, signature, body — original formatting) of one or more members by name: methods (all overloads returned), constructors (request as Widget.Widget or fully qualified Ns.Widget.Widget; nested types need full qualification), properties, indexers (request as Type.this or Type.this[]), fields, events. Batch-friendly: pass many names in one call instead of reading whole files. Per-item statuses: ok, notFound, ambiguous (with candidates), metadata (use peek_il or inspect_external_assembly), unsupportedKind (whole types — use get_type_overview). Items keep request order.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (default: 100) | |
| symbols | Yes | Member names: simple (`MyClass.MyMethod`) or fully qualified (`Ns.MyClass.MyMethod`) |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
List NuGet package references for projects in the solution
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Optional project name filter (omit to list all) |
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.
Is 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.
Given 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.
Does 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource '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.
Does 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.
Return every user-defined operator and conversion operator on a type in one call — source AND metadata. Each entry includes the operator kind (such as +, ==, implicit, explicit, plus all comparison and bitwise operators), full signature, parameter names/types/modifiers, return type, accessibility, an IsCheckedVariant flag for .NET 7+ checked operators (op_CheckedAddition etc.), XML doc summary, and source location (empty for metadata). Includes compiler-synthesized record equality operators. Returns declared operators only — operators do not inherit in C#. Pass a type name, simple or fully qualified (e.g. 'Vector2', 'MyApp.Money', 'System.Decimal'). Sort: kind ordinal ASC, then parameter count ASC, then signature ordinal ASC.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Type name (simple or fully qualified) — e.g. Vector2, MyApp.Money |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Return every overload of a method (or constructor) in one call — source AND metadata. Each overload includes the full signature, parameter names/types/modifiers (ref/out/in/params/optional with defaults), return type, accessibility, modifiers (static/virtual/abstract/override/async/extension), generic type parameters, XML doc summary, and source location (empty for metadata). Pass 'Type.Method' for ordinary methods or 'Type.Type' for constructors. Operator overloads are excluded — use get_operators for those. Sort: parameter count ASC, then signature ordinal ASC.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Method or constructor symbol (e.g. 'Greeter.Greet', 'Greeter.Greeter', 'System.Console.WriteLine'). |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Return the project reference graph (direct and transitive dependencies)
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project name or .csproj filename |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'get_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.
Aggregate 7 health dimensions per project in one call: complexity hotspots, large classes, naming violations, unused symbols, reflection usage, async violations, and disposable misuse. Returns counts per dimension plus the top-N hotspots inline (default 5) so the caller can prioritise without follow-up calls. Use this when answering 'how is this project doing?' / 'where should I focus?' / 'what's the technical debt picture?'. Underlying defaults: complexity threshold 10, large-class limits 20 members / 500 lines, unused symbols excludes internals. Test projects are skipped. Project filter is case-insensitive. Sort: projects ASC by name; hotspots sorted by severity proxy per dimension (cyclomatic complexity desc, line count desc, severity enum desc for async/disposable).
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Optional: restrict to a single project by name. Default: whole solution, grouped per project. | |
| hotspotsPerDimension | No | How many hotspots to include per dimension. Default: 5. Pass 0 for counts-only output. |
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.
Is 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.
Given 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by 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.
Does 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.
Does 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.
Enumerate every public and protected type and member declared in production projects of the active solution. Returns a deterministically-sorted (name ASC) flat list of API entries (kind, fully-qualified name, accessibility, project, file, line) plus per-kind/per-project/per-accessibility summary buckets. Skips test projects, generated code, compiler-generated members, internal symbols, and protected members on sealed types (unreachable). Inherited members are not repeated under derived types — only declared members appear.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
List source generators and their output per project. Returns an envelope with items sorted by project then generator name, totalCount, truncated, and limit (default 100).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (default: 100). Items are sorted by project, then generator name. | |
| project | No | Optional project name filter |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives 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.
One-shot context dump for a type: namespace, base class, interfaces, injected dependencies, public members
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Type name (simple or fully qualified) |
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.
Is 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists 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.
Does 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. 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.
Get the current status of a background task by its taskId.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | The taskId returned by start_background_task |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Per-project inventory of test methods. Each test reports framework (xUnit/NUnit/MSTest), attribute kind ([Fact]/[Theory]/[Test]/[TestCase]/[TestMethod]/[DataTestMethod]), data-driven row count, location, and the production symbols it references. Complements find_tests_for_symbol (which goes test → production); this goes project → tests. Use to answer 'what does this test suite cover?' or to break down test counts by framework/attribute. Production projects, generated code, and BCL/framework calls are filtered out of the per-test referenced-symbols list. Project filter is case-insensitive. Sort: tests by (file, line); projects by name ASC.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Optional: restrict to a single test project by name (case-insensitive). |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Walk up (base classes, interfaces) and down (derived types) from a type
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Type name (simple or fully qualified) |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Get a comprehensive overview of a type in one call: full context (namespace, base class, interfaces, members, DI dependencies), type hierarchy (bases, interfaces, derived types), and diagnostics in the file. More efficient than calling get_symbol_context + get_type_hierarchy + get_diagnostics separately.
| Name | Required | Description | Default |
|---|---|---|---|
| typeName | Yes | Type name (simple name or fully qualified) |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Find the source file and line where a symbol is defined. Returns an envelope with items, totalCount, truncated, and limit.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (default: 50). Items are sorted by file, then line. | |
| symbol | Yes | Symbol name: simple type (MyClass), fully qualified (Namespace.MyClass), or member (MyClass.DoWork) |
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.
Is 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately 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.
Does 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 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.
Inspect a referenced closed-source assembly. mode='summary' returns namespaces + type counts; mode='namespace' returns public types and members for the given namespace.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | 'summary' (default) or 'namespace' | summary |
| assemblyName | Yes | Assembly name, e.g. 'Newtonsoft.Json' or 'Microsoft.Extensions.DependencyInjection.Abstractions' | |
| namespaceFilter | No | Required when mode='namespace' |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
List background tasks that are running or completed within the last 5 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (default: 50) |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
List all solutions loaded by this server, showing which one is currently active. Each entry includes any projects that were skipped during load (e.g. legacy non-SDK-style projects), with the kind and reason for each skip. Returns an envelope with items sorted by solution path, totalCount, truncated, and limit (default 50).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (default: 50). Items are sorted by solution path. |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Return the current trust state: session-scoped paths, persistent paths, trusted roots, and analyzer policy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Is 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description 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.
Does 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.
Does 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.
Load a .sln/.slnx solution at runtime and make it the active solution. Both include and rootProjects match against the project FILE NAME without extension (the .csproj/.vbproj base name), NOT the assembly name. Pass include (case-insensitive glob array, supporting only * and ? wildcards — character classes like [...] are NOT supported) or rootProjects (EXACT, case-sensitive file names) to load only a subset; the loader walks ProjectReference transitively from those seeds to keep the workspace semantically complete. A filter that matches NO project is an ERROR (the call fails) — it does NOT silently fall back to a full load; if unsure of exact names, do a no-filter load first and call list_solutions to discover them. If the same path is already loaded, providing a new filter disposes the previous workspace (replace semantics). If the solution is already loaded with no filter, it simply activates it (~instant). New solutions take ~3 seconds to load and compile. For very large solutions (hundreds of projects) that take minutes to open, pass background: true to return a taskId immediately instead of blocking; poll it with get_task_status until it succeeds (its result carries the loaded/skipped counts). The new solution only becomes active once the background load finishes, so other tools keep working against the current solution meanwhile.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Full path to the .sln or .slnx file to load | |
| include | No | Optional case-insensitive glob patterns against project file name without extension (e.g. 'MyApp.*') | |
| background | No | If true, load on a background task and return a taskId immediately (poll with get_task_status) instead of blocking until the solution is ready. Default false. | |
| rootProjects | No | Optional exact project file names without extension; both arrays act as seeds for a transitive ProjectReference closure |
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.
Is 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.
Given 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value 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.
Does 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.
Does 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.
Return ilasm-style IL for a single method in a referenced closed-source assembly. Input must be a fully-qualified method name with parameter types.
| Name | Required | Description | Default |
|---|---|---|---|
| methodSymbol | Yes | Fully-qualified method name with parameter types, e.g. 'Newtonsoft.Json.JsonConvert.SerializeObject(object)' |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Force a full reload of the analyzed solution — re-opens the .sln, recompiles all projects, and rebuilds all indexes. Use after changing Directory.Build.props, adding/removing NuGet packages, or when diagnostics seem stale.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Safely rename a type or member across the entire solution (Roslyn Renamer). Cascades to references, constructors, overrides, nameof, and XML doc crefs. Defaults to preview mode (returns edits without writing files); set preview=false to apply. New compiler errors the rename would introduce are reported as Conflicts, and apply mode refuses to write them unless force=true. Locals/parameters and file renames are not supported.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Apply even when Conflicts are reported (default: false) | |
| symbol | Yes | Symbol to rename: simple type (MyClass), fully qualified (Namespace.MyClass), or member (MyClass.MyMethod) | |
| newName | Yes | New name — a bare C# identifier, e.g. 'OrderProcessor' | |
| preview | No | Preview only — return edits without writing to disk (default: true) | |
| renameInStrings | No | Also rewrite occurrences inside string literals (default: false) | |
| renameOverloads | No | Rename all overloads of a method together (default: true; false renames a single arbitrary overload) | |
| renameInComments | No | Also rewrite occurrences inside comments (default: true) |
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.
Is 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.
Given 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by 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.
Does 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.
Does 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.
Map a pasted .NET stack trace to file/line/symbol against the loaded solution, undoing compiler name mangling: async/iterator state machines (<M>d__N.MoveNext), lambdas (<>c / <>c__DisplayClass), local functions (g__Name|), generic arity. Handles Exception.ToString() output, log-prefixed lines, inner-exception chains, and Ben.Demystifier-style traces. Frames without 'in file:line' get the declaration site; frames with it keep the exact location. External frames resolve with origin=metadata. Items are in original trace order.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (default: 500) | |
| stackTrace | Yes | The stack trace text, pasted as-is (multi-line) |
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.
Is 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.
Given 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add much 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.
Does 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.
Does 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.
Remove a previously trusted solution path or trusted root. Removes both session and persistent entries.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path of the solution or trusted root to revoke |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. 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.
Search for types, methods, properties, and fields by name (case-insensitive substring match). Returns an envelope with items sorted by match quality (exact → prefix → substring), totalCount, truncated, limit (default 200), and a byKind summary.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (default: 200). Items are sorted by match quality. | |
| query | Yes | Search query (substring match against symbol names) |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Switch the active solution. All subsequent tool calls will operate on the selected solution. Use a partial, case-insensitive name (e.g. 'MyProject' matches 'C:/code/MyProject/MyProject.sln'). Returns the full path of the newly active solution.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Partial or full solution name/path to match |
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.
Is 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description 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.
Does 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.
Does 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.
Does 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.
Queue a long-running tool to run in the background. Returns a taskId; poll with get_task_status. Allowed tools: rebuild_solution.
| Name | Required | Description | Default |
|---|---|---|---|
| toolName | Yes | Tool name to run in the background. Currently allowed: rebuild_solution. |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Mark a solution path (or directory root) as trusted for analyzer execution. Required before get_diagnostics will load Roslyn analyzer DLLs from the solution. Always confirm with the user before calling this tool — analyzer DLLs run as in-process code.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to a .sln/.slnx file, or a directory when scope='addRoot' | |
| scope | No | 'session' (in-memory only, default), 'persistent' (write to trust.json), or 'addRoot' (trust the directory and all solutions under it) | session |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Unload a previously loaded solution to free memory. Use a partial, case-insensitive name (e.g. 'DcpCore' matches the full path). If the unloaded solution was active, another loaded solution becomes active. Use this when you're done analyzing a codebase and want to reclaim memory.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Partial or full solution name/path to match |
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.
Is 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description 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.
Does 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.
Does 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.
Does 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.18.0get_file_overview1 field changedInput schema / properties / filePath / descriptionPrevious value: -"Full path to the C# source file"New value: +"Full path to the source file (.cs, or .razor/.cshtml)"analyze_change_impactanalyze_control_flowanalyze_data_flowanalyze_methodapply_code_actionchange_signaturecheck_architecturefind_async_violationsfind_attribute_usagesfind_breaking_changesfind_callersfind_catch_blocksfind_circular_dependenciesfind_disposable_misusefind_event_subscribersfind_god_objectsfind_implementationsfind_large_classesfind_naming_violationsfind_obsolete_usagefind_referencesfind_reflection_usagefind_tests_for_symbolfind_throw_sitesfind_uncovered_symbolsfind_unused_symbolsgenerate_test_skeletonget_call_graphget_code_actionsget_code_fixesget_complexity_metricsget_di_registrationsget_diagnosticsget_exception_flowget_extension_methodsget_file_overviewget_generated_codeget_instantiation_optionsget_method_sourceget_nuget_dependenciesget_operatorsget_overloadsget_project_dependenciesget_project_healthget_public_api_surfaceget_source_generatorsget_symbol_contextget_task_statusget_test_summaryget_type_hierarchyget_type_overviewgo_to_definitioninspect_external_assemblylist_running_taskslist_solutionslist_trusted_pathsload_solutionpeek_ilrebuild_solutionrename_symbolresolve_stack_tracerevoke_trustsearch_symbolsset_active_solutionstart_background_tasktrust_solutionunload_solutionScored across 67 tools
Most tools are distinct in purpose, but there is some overlap among query tools (e.g., find_references vs find_callers vs analyze_change_impact) and overview tools (get_type_overview vs get_symbol_context). Descriptions clarify the differences, so confusion is unlikely but not impossible.
All tool names follow a consistent snake_case verb_noun pattern (find_references, get_diagnostics, rename_symbol, change_signature, etc.). The naming is predictable and uniform, making the API easy to navigate.
With 67 tools, the server is extremely heavy. Although it covers a broad domain (analysis, refactoring, testing, dependencies), many tools are highly specific and could be consolidated (e.g., multiple find_* analyzers). This exceeds any reasonable threshold for typical usage.
The tool set provides comprehensive coverage of the code analysis domain: symbol lookup, references, diagnostics, code fixes, refactoring, test generation, architecture checks, dependency graphs, and more. No obvious gaps exist for the stated purpose of deep Roslyn-based analysis.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Lean 4 MCP server: compile, prove theorems, and formalize math with Mathlib.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Hosted code graph over MCP: exact callers, dependencies, and cross-repo blast radius for AI agents.
