Skip to main content
Glama
andypgray

resharper-cli-mcp

by andypgray
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

ReSharper Inspect Code

resharper_inspect
Read-onlyIdempotent

Runs ReSharper static analysis on a .NET solution to identify code issues, with optional file filtering, severity thresholds, and detail levels.

Instructions

Run ReSharper static analysis on the solution and return the code issues it finds.

Input Schema

TableJSON 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, 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.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 to run against. Overrides JB_SOLUTION_PATH and working-directory discovery.

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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."
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior1/5

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.

Conciseness4/5

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.

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 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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server

Other Tools