Skip to main content
Glama
Sign In
resharper-cli-mcp

resharper-cli-mcp

by andypgray
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

ReSharper Inspect Code

resharper_inspect
Read-onlyIdempotent

Run solution-wide ReSharper static analysis on a C# solution to report warnings, errors, and suggestions, with optional file scoping and a full Markdown report.

Instructions

Run ReSharper code inspection (static analysis, lint) over a C# solution and return the warnings, errors and suggestions it finds.

Input Schema

NameRequiredDescriptionDefault
filesNoAnt-style globs narrowing the findings to matching files, for example src/**/*.cs. The analysis stays solution-wide, so a scoped run is no faster. Each is relative to the solution root, or absolute. jb matches them against the files that belong to a project in the solution, so one that is on disk but in no project matches nothing, which nothing here can detect. An element joining several paths with ; or , is split into separate paths.
detailNoCap on the detail the response carries: Full lists every issue on its own line, and Minimal is one line of totals. Rendering starts at this level and never goes above it, but still steps below it when the result does not fit the output budget. The DETAIL REDUCED note says which of the two happened. Response shaping only: the same analysis runs whatever the level, so a lower level does not make a call finish sooner. Pair detail=Minimal with report=Markdown for a cheap verdict in the response and every finding in the file.Full
reportNoWrite the complete itemised findings to a file, and name it in the response. Markdown lists every issue with its own message, which is what the response listing collapses once a solution-wide run exceeds the output budget. The file lands in a directory this server owns and is pruned after 7 days; the response carries the summary either way.None
severityNoMinimum severity to report. Error is ReSharper's compilation-error level, not a tier of high-priority warnings; raising to it usually reports nothing.Warning
solutionPathNoPath to the .sln, .slnx or .slnf to run against. Overrides JB_SOLUTION_PATH and working-directory discovery.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.8.0
    • changedInput schema / properties / solutionPath / description
      Previous value: -"Path to the .sln/.slnx to run against. Overrides JB_SOLUTION_PATH and working-directory discovery."New value: +"Path to the .sln, .slnx or .slnf to run against. Overrides JB_SOLUTION_PATH and working-directory discovery."
  2. Changed1 schema field changedv1.7.2
    • changedInput schema / properties / detail / description
      Previous value: -"Cap on the detail the response carries: Full, the default, lists every issue on its own line, and Minimal is one line of totals. Rendering starts at this level and never goes above it, but still steps below it when the result does not fit the output budget. The DETAIL REDUCED note says which of the two happened. Response shaping only: the same analysis runs whatever the level, so a lower level does not make a call finish sooner. Pair detail=Minimal with report=Markdown for a cheap verdict in the response and every finding in the file."New value: +"Cap on the detail the response carries: Full lists every issue on its own line, and Minimal is one line of totals. Rendering starts at this level and never goes above it, but still steps below it when the result does not fit the output budget. The DETAIL REDUCED note says which of the two happened. Response shaping only: the same analysis runs whatever the level, so a lower level does not make a call finish sooner. Pair detail=Minimal with report=Markdown for a cheap verdict in the response and every finding in the file."
  3. Changed1 schema field changedv1.7.0
    • changedInput schema / properties / files / description
      Previous value: -"Ant-style globs scoping the analysis to specific files, for example src/**/*.cs. Each is relative to the solution root, or absolute. jb matches them against the files that belong to a project in the solution, so one that is on disk but in no project matches nothing. An element joining several paths with ; or , is split into separate paths."New value: +"Ant-style globs narrowing the findings to matching files, for example src/**/*.cs. The analysis stays solution-wide, so a scoped run is no faster. Each is relative to the solution root, or absolute. jb matches them against the files that belong to a project in the solution, so one that is on disk but in no project matches nothing, which nothing here can detect. An element joining several paths with ; or , is split into separate paths."
  4. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only that it returns warnings, errors and suggestions; it says nothing about runtime cost, the fact that analysis is solution-wide regardless of any file scoping, or that findings may be written to a pruned report file — all of which live only in the schema.

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

Conciseness4/5

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

One front-loaded sentence with a clear verb and scope, and no wasted words. It is appropriately sized given the schema carries the detail, though it stops short of any structure that would help an agent decide between sibling tools.

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

Completeness4/5

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

With no output schema, the description does state what comes back (warnings, errors, suggestions), which is the key missing piece an agent would otherwise lack. The remaining complexity — detail levels, report file emission, solution resolution — is exhaustively documented in the parameter schema, so the definition is close to complete.

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

Parameters3/5

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

Schema description coverage is 100% and each of the five parameters carries a detailed, non-obvious explanation in the schema itself. The description mentions no parameter names or semantics, so it adds nothing here, but the schema baseline of 3 applies.

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

Purpose4/5

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

The description names a specific verb+resource pair ("Run ReSharper code inspection") and clarifies the domain with parentheticals ("static analysis, lint") plus the target ("a C# solution"). It is clearly distinct from resharper_cleanup and resharper_reset_cache by implication, but never names or contrasts those siblings explicitly.

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

Usage Guidelines3/5

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

Usage is implied by "over a C# solution" but there is no statement of when to prefer this over resharper_cleanup, nor any prerequisites (e.g. a solution must be locatable via solutionPath or JB_SOLUTION_PATH). The agent must infer the routing from the tool names alone.

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

Deploy Server

Other Tools