Skip to main content
Glama

resharper-cli-mcp

CI works with jb OpenSSF Scorecard NuGet NuGet downloads

resharper-cli-mcp is an MCP server that gives a C# coding agent ReSharper's solution-wide inspections (resharper_inspect) and its code cleanup (resharper_cleanup). It wraps JetBrains' jb, managing its cache and returning LLM-friendly markdown sized to a context window. It is unofficial — not affiliated with or endorsed by JetBrains. The server shells out to a jb you install yourself and bundles no JetBrains software.

What the server adds

jb is built for a batch job: one run against one checkout, a report written to a file. An agent hits the same solution several times an hour, and what each call costs comes down to whether ReSharper's solution-wide index is already built. So the server owns the cache directory and runs a lifecycle over it:

  • The first run happens before you ask for it. A speculative inspection starts as soon as a client connects, skipped when a run against that cache succeeded in the last hour; a tool call arriving mid-pass cancels it and takes the cache within a second or two. RESHARPER_MCP_PREWARM=off turns it off.

  • Runs are serialized per solution. A cross-process lock keeps every client on one cache generation; a second concurrent jb forks a cold copy of its own and leaves it behind on disk. A jb you start yourself is outside that queue, so give it its own --caches-home.

  • A fresh checkout is seeded from a warm one. Caches are keyed to the solution's absolute path, so a new worktree or clone starts cold. When a call finds no cache and a same-named sibling checkout has a warm one, the server copies it across, best-effort and never over a cache a successful run produced. The copy still has to be re-keyed, so a seeded run lands between warm and cold.

  • SARIF becomes markdown that fits the client. Issues come back grouped by file, re-rendered at progressively lower detail until they fit the client's output budget, with every issue still counted and every file still named at each step. detail caps that ladder when you want a rollup without overflowing the budget to get one. When the summary is not enough, report=Markdown writes the complete listing to a file and the response names it.

Related MCP server: lsp-tools-mcp

Quickstart

The server needs the .NET 10 SDK and JetBrains' ReSharper Command Line Tools. Both install as .NET global tools, and neither needs an IDE.

dotnet tool install -g JetBrains.ReSharper.GlobalTools
dotnet tool install -g Zphil.ReSharperCli

The server looks for jb on PATH and then in ~/.dotnet/tools. An MCP client often starts the server without your shell's PATH, so a jb that answers in your terminal can still be invisible to it.

Register the server with your MCP client under the command resharper-cli-mcp. For Claude Code, add it to .mcp.json:

{
  "mcpServers": {
    "resharper": {
      "command": "resharper-cli-mcp"
    }
  }
}

The server finds a single .sln/.slnx in its working directory; when that directory holds zero or several, set JB_SOLUTION_PATH in the config's env block.

llms-install.md is the same setup written as a checklist, with the configuration block for each of the common clients. Point an agent at it to have the server installed for you.

VS Code, Visual Studio, Cursor and LM Studio can add the server in one click, once both tools are installed:

Install in VS Code Install in Visual Studio Add to Cursor Add to LM Studio

Other clients

Every client runs the same command, resharper-cli-mcp, with no arguments. Only the file and the key around it change.

Visual Studio

Visual Studio 2022 17.14 and later, and Visual Studio 2026, read an .mcp.json beside the solution, so a checked-in file registers the server for everyone working on it. The top-level key is servers, and the transport is named:

{
  "servers": {
    "resharper": {
      "type": "stdio",
      "command": "resharper-cli-mcp"
    }
  }
}

Rider and Junie

Junie reads ~/.junie/mcp/mcp.json for every project, or .junie/mcp/mcp.json for one. Rider's AI Assistant takes the same JSON under Settings | Tools | AI Assistant | MCP:

{
  "mcpServers": {
    "resharper": {
      "command": "resharper-cli-mcp"
    }
  }
}

Running the server alongside a JetBrains IDE means two ReSharper engines over one solution, each with its own cache. Point one of them elsewhere with JB_CACHE_HOME if disk use matters.

Codex CLI

codex mcp add resharper -- resharper-cli-mcp

Cline

Cline stores its servers in cline_mcp_settings.json, which the MCP Servers panel opens under Configure MCP Servers:

{
  "mcpServers": {
    "resharper": {
      "command": "resharper-cli-mcp"
    }
  }
}

Install as a Claude Desktop extension

Claude Desktop installs local MCP servers as MCP Bundles. Download resharper-cli-mcp-<version>.mcpb from the latest release, double-click it, and set Solution file to the .sln or .slnx you want analysed. Claude Desktop starts the server outside your repository, so there is no working directory for it to discover one in. Run cap sets how long one jb run may take before the server kills it; ten minutes by default, which a first run against a large solution can exceed.

The bundle holds the server and neither of its prerequisites. Install the .NET 10 runtime and the ReSharper Command Line Tools first, as under Quickstart: the bundle launches the server with dotnet, and every tool call shells out to jb.

Install as a Claude Code plugin

This repository doubles as a single-plugin marketplace, so the tools, the derive_style_guide prompt, and both guide resources arrive in one step:

/plugin marketplace add andypgray/resharper-cli-mcp
/plugin install resharper-cli-mcp@resharper-cli-mcp

The plugin starts the server with dotnet dnx, which fetches a pinned Zphil.ReSharperCli version from NuGet on first use. The marketplace commit you install therefore determines the server you run. Each release moves that pin, so run claude plugin update resharper-cli-mcp@resharper-cli-mcp to pick up a newer server. You still need the .NET 10 SDK and the ReSharper Command Line Tools; ReSharper's caches live in the plugin's own data directory, outside your source tree.

Tools

Tool

Mutates files

What it does

resharper_inspect

no

Runs ReSharper InspectCode and returns the issues, grouped by file.

resharper_cleanup

yes

Runs ReSharper CleanupCode to reformat and normalize the given files in place.

resharper_reset_cache

no (deletes caches)

Drops the solution's ReSharper cache so the next run rebuilds its analysis from cold.

Scope resharper_inspect with the files glob (entries may be solution-relative or absolute) and raise severity (Suggestion, Warning, Error; default Warning) to control how much comes back. Each issue carries a file, line, severity, rule ID, and message:

Found 2 issue(s) across 1 file(s):

### /repo/src/HomeController.cs
- **Line 8** [WARNING] `RedundantUsingDirective`: Using directive is not required by the code and can be safely removed.
- **Line 24** [SUGGESTION] `FieldCanBeMadeReadOnly.Local`: Field can be made readonly.

A solution-wide sweep lands on the reduced rendering by construction, which collapses issues repeating a rule within a file to one example message. To work through findings one at a time, pass report=Markdown: resharper_inspect writes every issue with its own message to a file under the system temp directory, names that file at the top of its response, and deletes it after seven days. It is off by default, and markdown is the only format — jb writes one report per run and this server needs the SARIF to build the summary. detail runs the other way, naming the most detailed level the response may use, from Full down to a one-line Minimal; it caps rather than pins, so the response still steps lower to fit, and the note says which of the two happened. detail=Minimal report=Markdown surveys a legacy solution in a single call.

resharper_cleanup changes style, never behavior: formatting, using directives, var style, modifier order, redundant qualifiers and parentheses, braces. Write correct logic and let cleanup do the polish: call it once, at the end of a task, with every changed file batched into the one call. It reports which files it actually changed on disk.

For a legacy codebase where the fallback Built-in: Full Cleanup profile would churn code you did not touch, define a narrower profile (for example Custom: No Reordering) in the solution's .sln.DotSettings and name it under SilentCleanupProfile. Every call then uses it, including calls from an agent that does not know it exists.

Run times

Each run is capped at 10 minutes; RESHARPER_MCP_TIMEOUT_SECS moves the cap. Narrowing a call with files will not make it finish sooner: resolving symbols across projects takes the whole solution model, so files decides what is reported, not how much is analysed. When an MCP client's own tool-call timeout is shorter than a cold run needs, the client gives up first; in Claude Code, raise it with a per-server "timeout" in .mcp.json or MCP_TOOL_TIMEOUT. The resharper://guides/setup resource carries all of this at troubleshooting depth, for an agent to pull when a call cannot find jb, times out, or comes back shortened.

A run in flight reports itself every ten seconds as an MCP progress notification: first the wait for another run on the same cache, then the cache state jb opened, then a running count of the files it has analysed, each with the elapsed time and the cap. That last one is what tells a slow run from a hung one, and a caller watching "8 minutes 2 seconds, cap 10 minutes" can raise RESHARPER_MCP_TIMEOUT_SECS before the call fails rather than after. Notifications go only to a client that asks for progress by sending a progressToken with the call; one that does not gets the same result and no notifications.

Configuration

Set these in the MCP client config's env block. All are optional. Each JB_ variable becomes something jb itself is told; the RESHARPER_MCP_ ones govern this server's own behaviour and never reach jb.

Variable

Purpose

JB_SOLUTION_PATH

Solution to use when the working directory has zero or several; the solutionPath tool argument overrides it for one call.

JB_SETTINGS_PATH

Explicit .DotSettings file for jb, mounted as a Custom layer above the solution's and every project's own settings.

JB_CACHE_HOME

ReSharper cache directory (default ~/.jb-cache).

JB_EXTENSIONS

Semicolon-separated ReSharper plugin IDs to load.

JB_EXTENSION_SOURCE

Custom NuGet source for those plugins.

RESHARPER_MCP_TIMEOUT_SECS

Cap in seconds on one jb run, and on the wait for one already in flight (default 600, clamped to 60–86,400).

RESHARPER_MCP_PREWARM

off disables the background cache pre-warm above.

RESHARPER_MCP_LOG_LEVEL

Level for the rolling file log (default Warning).

MAX_MCP_OUTPUT_TOKENS

Client output budget the reduction ladder renders to fit (2.5 characters per token; 25,000 characters when unset).

Solution discovery tries, in order: the solutionPath argument, JB_SOLUTION_PATH, then a single .sln/.slnx in the working directory (top level only, no parent walk).

Settings discovery tries, in order: JB_SETTINGS_PATH, a .DotSettings file beside the solution, then GlobalSettingsStorage.DotSettings in the JetBrains shared directory. jb mounts the last two on its own, so the server passes --settings only for a JB_SETTINGS_PATH outside them (naming an already-mounted file would demote every project's own .DotSettings). On top of whichever settings apply, jb reads .editorconfig from the source tree automatically.

Logs roll daily under %LOCALAPPDATA%\Zphil.ReSharperCli\logs on Windows, and the platform-equivalent path elsewhere.

What ReSharper enforces

resharper_inspect obeys inspection severities (what gets reported); resharper_cleanup enforces code style through its cleanup profile (what gets rewritten). The two axes do not share a switch: setting a rule to DO_NOT_SHOW hides its issue, and cleanup goes on normalizing that style. The full model ships as an on-demand MCP resource, resharper://guides/configuration, for an agent to pull just before changing what ReSharper enforces.

For an existing codebase the derive_style_guide MCP prompt walks an agent through deriving an intentional style guide from the code you already have, .editorconfig-first, with ReSharper-only knobs spilling into .sln.DotSettings. If you have access to Resharper or Rider, JetBrains' first-party Detect Code Style Settings is the better baseline; the prompt is the path for headless use.

Cleanup reminder hook

The single end-of-task cleanup is easy for an agent to forget. This Claude Code PostToolUse hook appends a one-line reminder to the agent's context after each .cs/.razor edit; it never edits code or calls the tool itself, so the agent decides when to clean up. Add it to .claude/settings.json:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "grep -qiE '\"file_path\"[[:space:]]*:[[:space:]]*\"[^\"]*\\.(cs|razor)\"' && printf '%s' '{\"hookSpecificOutput\":{\"hookEventName\":\"PostToolUse\",\"additionalContext\":\"When this task is done, batch every edited .cs/.razor file into one resharper_cleanup call.\"}}' || true"
          }
        ]
      }
    ]
  }
}

The command uses grep and printf, so it needs a POSIX shell (on Windows, Git Bash).

Privacy Policy

resharper-cli-mcp collects nothing. It has no telemetry, no analytics, no accounts and no remote logging, and it makes no network calls of its own. Every tool call shells out to the jb on your machine, and the issues and cleanup summaries it produces go back over stdio to the MCP client that launched the server.

The diagnostic log described under Configuration is the only thing written to disk. It keeps 7 daily files and can contain absolute paths and the rule IDs and messages read from your solution. It stays on the machine, and deleting it at any point is safe.

PRIVACY.md is the full policy: what is collected, how your source code is processed, the local logs and how long they are kept, the two network paths around the server, and where to ask about it.

Contributing

Contributions are welcome. Bug reports reproduced on a public solution, MCP client-compatibility fixes, and improvements to discovery or output formatting land best. See CONTRIBUTING.md for the development setup (.NET 10 SDK) and the two-seam test architecture. To report a security issue privately, see SECURITY.md.

License

MIT; see LICENSE.

JetBrains and ReSharper are trademarks of JetBrains s.r.o. This project is an independent wrapper of their ReSharper Command Line Tools, which ship under JetBrains' own license.

Available Tools

3 tools
resharper_cleanupReSharper Cleanup CodeA
DestructiveIdempotent

Run ReSharper code cleanup to reformat and normalize files in place.

ParametersJSON Schema
NameRequiredDescriptionDefault
filesYesFile paths to clean up. 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. Wildcards are allowed and expanded by jb; a non-wildcard path that does not exist fails the whole call before anything is rewritten. An element joining several paths with ; or , is split into separate paths.
profileNoReSharper cleanup profile name. Defaults to the profile the solution declares, else full cleanup.
solutionPathNoPath to the .sln/.slnx to run against. Overrides JB_SOLUTION_PATH and working-directory discovery.

TDQS

A4/5.0
Behavior3/5

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

Annotations already carry destructiveHint=true and idempotentHint=true, so the 'in place' phrase in the description confirms the mutating nature rather than introducing new information. The description does not contradict the annotations and adds a small amount of context, but it does not disclose side effects like overwriting formatting or requiring a backup.

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

Conciseness5/5

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

The description is one short, direct sentence that names the action, target, and in-place mutating effect. Every word contributes, with no filler or redundant rephrasing.

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?

The schema handles the complex path-matching and profile-default semantics, and annotations cover the unsafe/idempotent behavior. The only missing piece is a description of return values or post-condition reporting, but no output schema exists and this is not essential for invoking the tool correctly.

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 the property descriptions are rich: files explains path matching, wildcards, splitting, and failure behavior, while profile explains defaults. The tool description itself adds no parameter-level detail, so it meets the baseline for an already fully documented schema.

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 pairs a specific verb ('Run') with a specific resource ('ReSharper code cleanup') and states the observable effect ('reformat and normalize files in place'). This clearly distinguishes the tool from siblings: cleanup modifies formatting, whereas resharper_inspect analyzes issues and resharper_reset_cache manages the cache.

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?

The description clearly frames the tool as the choice for reformatting and normalizing files in place, which gives an agent usable context for selection. It does not explicitly name alternatives or state when not to use it, but the behavior is distinct enough from the sibling tools that the usage intent is unambiguous.

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

resharper_inspectReSharper Inspect CodeA
Read-onlyIdempotent

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

ParametersJSON Schema
NameRequiredDescriptionDefault
filesNoAnt-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.
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.

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the minimal description is consistent and does not add contradictory claims. The phrase 'static analysis' is aligned with read-only behavior but adds little beyond annotations. No mention of performance, report-side effects in the tool description itself, though parameter descriptions do disclose file output and pruning behavior.

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

Conciseness5/5

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

The description is a single, front-loaded sentence with zero filler. It states the action, target, and outcome immediately. Every word earns its place, and there is no redundant restatement of the title.

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?

Although there is no output schema, the parameter descriptions compensate by explaining response behavior: detail caps the listing, report writes a file with findings, and the response carries a summary. Combined with annotations and detailed schemas, an agent has almost everything needed to invoke the tool correctly. The main gap is a precise description of the return object structure, but the information provided is sufficient for most call decisions.

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%, so the baseline is 3. The tool description itself contains no parameter information, but the input schema thoroughly documents each parameter with examples, edge cases (e.g., files not belonging to a project), enum meanings, and interactions between detail, report, and severity. The description does not need to compensate, so a 3 is appropriate.

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?

Description uses a specific verb and resource: 'Run ReSharper static analysis on the solution and return the code issues it finds.' This clearly differentiates the tool from siblings like resharper_cleanup (which would modify code) and resharper_reset_cache (which would manage caches). The scope ('on the solution') and output ('code issues') are unambiguous.

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

Usage Guidelines2/5

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 resharper_cleanup or resharper_reset_cache. It does not mention 'use when you want to review issues without modifying code' or any exclusion criteria. The agent must infer intent from the sibling names and the word 'inspect', which is not enough for a clear routing decision.

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

resharper_reset_cacheReSharper Reset CacheA
DestructiveIdempotent

Delete this solution's ReSharper analysis cache so the next inspect or cleanup rebuilds it from cold. The cure for inspect reporting compilation errors the compiler itself does not: a stale index serves those until the cache is dropped. Costs the next call a full cold analysis, so it is not routine maintenance.

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

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already mark the tool destructive, and the description adds what exactly gets destroyed (the ReSharper analysis cache) and the behavioral consequence: the next inspect or cleanup call will rebuild from cold. It also explains the stale-index failure mode, giving the agent a clear mental model beyond the annotation flags.

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

Conciseness5/5

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

The description is three sentences with no wasted words: it states the action, explains the diagnostic trigger, and flags the cost. The most important operational fact (delete cache) is front-loaded, and the maintenance warning is placed last where it can temper misuse.

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 one-parameter destructive tool with no output schema, the description is complete. It tells the agent what is deleted, why an agent might want to call it, what the next invocation will experience, and why it should not be used routinely. Annotations already carry the safety profile, so nothing critical is missing.

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?

The schema already fully documents solutionPath, including override behavior and discovery fallback, so the description does not need to add parameter details. The description mentions solution-level scope generically but adds no parameter-specific semantics beyond what the schema provides, matching the baseline for 100% schema description coverage.

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 opens with a specific action and resource: 'Delete this solution's ReSharper analysis cache'. It clearly distinguishes this cache-reset tool from the sibling inspection and cleanup tools by naming the cache as the target and framing the tool as a remedy for stale index issues.

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?

The description gives clear context for when to use the tool: when inspect reports compilation errors that the compiler itself does not, due to a stale index. It also warns 'not routine maintenance' and explains the cold-analysis cost. It references the sibling operations indirectly but does not explicitly contrast with when to choose cleanup or inspect instead.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 3 tool updatesv0.1.0
    • First observedresharper_cleanup
    • First observedresharper_inspect
    • First observedresharper_reset_cache

TDQS

A4/5.0
Disambiguation5/5

Each tool maps to a distinct ReSharper operation: resetting a stale cache, running cleanup formatting, and running static inspection. There is no plausible overlap or boundary confusion among the three.

Naming Consistency4/5

All tools share the consistent resharper_ prefix and lowercase snake_case style. The minor inconsistency is that reset_cache uses a verb+object form while cleanup and inspect are single verbs, but the pattern remains predictable.

Tool Count5/5

Three tools is modest but well-scoped for a ReSharper CLI server covering inspection, cleanup, and cache maintenance. Each tool earns its place without redundancy or bloat.

Completeness4/5

The set covers the core ReSharper workflow: analyze, clean, and rebuild from a fresh cache. It lacks more advanced ReSharper CLI capabilities, such as duplicate finding or project-level configuration, but for the stated purpose there are no obvious dead ends.

Maintenance

ActivityActive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/andypgray/resharper-cli-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server