Skip to main content
Glama

ReSharper Reset Cache

resharper_reset_cache
DestructiveIdempotent

Clears the ReSharper analysis cache so the next inspect or cleanup run rebuilds it from scratch. Use after a successful build to avoid stale results.

Instructions

Delete this solution's ReSharper analysis cache so the next inspect or cleanup rebuilds it from cold. The cure for inspect reporting compilation errors a successful build does not: a stale index serves those until the cache is dropped. Build first, because on a checkout that was never built or restored the errors are real and a reset only adds a cold analysis to the build it still needs. Costs the next call a full cold analysis, so it is not routine maintenance. A deleted checkout's cache outlives it: pass its old solution path as solutionPath to reclaim it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
solutionPathNoPath to the .sln/.slnx to run against. Overrides JB_SOLUTION_PATH and working-directory discovery.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.