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

Beyond annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true), the description discloses that files are modified 'in place' and that every call analyzes the whole solution regardless of file count — a meaningful scope/performance trait. The parameter schema additionally reveals atomic failure behavior (a non-existent non-wildcard path fails the entire call before anything is rewritten).

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 purpose verb in the first sentence and a single high-value operational rule in the second. No filler; 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?

With no output schema and a destructive in-place action, the description plus fully-detailed parameter schema covers purpose, side effects, batching behavior, defaults, and failure modes. The only minor gap is the absence of an explicit statement of what a successful call returns or how to verify 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% with rich descriptions (relative/absolute paths, wildcard expansion, ';'/',' separators, failure modes, profile defaults, solutionPath overriding JB_SOLUTION_PATH). The main description adds the batching strategy that clarifies how to use the files parameter, lifting it above the high-coverage 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 opens with a specific verb and resource — 'Run ReSharper code cleanup to reformat and normalize files in place' — which precisely states what the tool does. It clearly distinguishes itself from siblings resharper_reset_cache (cache reset) and resharper_inspect (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?

The second sentence gives explicit operational guidance — 'Each call analyses the whole solution whatever the file count, so make one call per task with every modified file in it' — telling the agent exactly how to batch calls. It does not explicitly contrast with sibling tools, but the purpose statement makes selection clear enough.

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

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

The report parameter explicitly says 'Write the complete itemised findings to a file' and mentions pruning after 7 days, which is a write side effect. This contradicts the annotation readOnlyHint: true, so behavioral transparency is seriously undermined.

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 main description is concise and front-loaded, and the parameter descriptions are information-dense. Some phrases are slightly verbose, but nearly every sentence adds useful detail.

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

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

With no output schema, the description reasonably explains what the response contains: issue listings, summary lines, detail reduction notes, and optional report filenames. It does not cover failure modes such as invalid solution paths, but the expected behavior is mostly complete.

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

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

All five parameters have thorough, meaningful descriptions that go well beyond the schema: files explains glob matching and performance implications, detail clarifies rendering versus analysis, report explains file output and retention, severity disambiguates Error, and solutionPath explains override 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 states a specific verb and resource: 'Run ReSharper static analysis on the solution and return the code issues it finds.' This makes the tool's purpose immediately clear and distinct from typical maintenance or cleanup 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?

Parameter descriptions provide practical guidance, such as pairing detail=Minimal with report=Markdown for a cheap verdict and noting that solutionPath overrides environment discovery. However, it does not explicitly compare against sibling tools like resharper_cleanup or resharper_reset_cache.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, which the description reinforces. Beyond that it adds genuinely useful behavior: the cold-analysis performance cost of the next call, the build-first prerequisite, and the surprising fact that a deleted checkout's cache outlives it. No contradiction with annotations.

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

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

The description is long but front-loaded with purpose and every sentence earns its place — usage boundaries, prerequisites, cost, and an edge case. Slightly denser than strictly necessary, but not bloated or repetitive. A 4 is fair.

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 destructive tool with subtle failure modes, the description covers purpose, when-to-use, when-not-to-use, consequences, and an edge case. No output schema is needed since this is a void side-effect operation, and the single parameter is fully handled. Nothing an agent needs to invoke it safely is missing.

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 real value beyond the schema by explaining the deleted-checkout case for solutionPath ('pass its old solution path as solutionPath to reclaim it'), which the schema alone would not convey. That pushes it to 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?

States a specific verb+resource ('Delete this solution's ReSharper analysis cache') and the purpose (rebuild from cold on next inspect/cleanup). It implicitly distinguishes from the siblings inspect/cleanup by framing the cache as the thing they consume, so an agent can tell them apart without opening schemas.

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?

Gives explicit when-to-use ('cure for inspect reporting compilation errors a successful build does not'), when-not-to-use ('on a checkout that was never built or restored the errors are real'), and a cost warning ('not routine maintenance'). It even handles the deleted-checkout edge case. This is exemplary usage guidance.

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