Dotnet Sherlock MCP

Sherlock MCP for .NET

Sherlock MCP for .NET is a comprehensive Model Context Protocol (MCP) server that provides deep introspection capabilities for .NET assemblies. It enables Language Learning Models (LLMs) to analyze and understand your .NET code with precision, delivering accurate and context-aware responses for complex development scenarios.

This tool is essential for developers who want to harness LLM capabilities for:

• Deep codebase analysis - Understanding complex .NET architectures and dependencies
• Precise type information - Getting detailed metadata about types, members, and their signatures
• Automated documentation - Extracting and utilizing XML documentation and attributes
• Custom tooling - Building sophisticated tools that interact with .NET assemblies
• Code generation - Creating accurate code based on existing type structures

Key Features

• Comprehensive MCP Server: Provides 47 specialized tools for .NET assembly analysis, with an optional 24-tool core profile whose other tools load on demand in groups
• Advanced Assembly Introspection: Deep reflection-based analysis of types, members, and metadata
• Rich Member Analysis: Detailed inspection of methods, properties, fields, events, and constructors
• Smart Filtering & Pagination: Advanced filtering by name/attributes with efficient pagination for large datasets
• XML Documentation Integration: Automatic extraction of summary, parameters, returns, and remarks
• Performance Optimized: Caching, pagination, and memory-efficient processing
• Stable JSON API: Consistent envelopes with versioning and structured error codes
• Modern .NET: Targets .NET 8, 9 and 10
• Project Integration: Solution and project file analysis with dependency resolution
• Workflow Prompts: explore_package, explain_type and who_calls prompts give one-click entry points into common analysis workflows
• Current MCP SDK: Built on ModelContextProtocol 2.1.0 (GA)
• Current MCP Specification: Speaks protocol revision 2026-07-28, and negotiates down automatically for clients on earlier revisions

What's New in 2.15.0

• Read and compare code: get_member_source returns a member's original source through its PDB or Source Link, decompile_member / decompile_type decompile to C#, and compare_api_surface diffs two assembly or package versions and flags breaking changes.
• Framework patterns: find_endpoints, find_service_registrations, find_ef_entities and find_handlers list ASP.NET Core endpoints, DI registrations, EF Core entities and MediatR handlers.
• Accurate resolution: framework types resolve against the target framework's reference pack, dependencies resolve from the project's project.assets.json (get_package_graph shows the restored graph), and project tools evaluate projects with MSBuild.
• Agent ergonomics: open_assembly handles, workflow prompts (explore_package, explain_type, who_calls), Mermaid diagrams for hierarchies and call graphs, and on-demand tool groups with discovery hints under the core profile.
• Windows-friendly: inspected assemblies are no longer locked, so rebuilds succeed while the server is running. See CHANGELOG.md for full details.

Installation

Run with dnx (.NET 10 SDK)

With the .NET 10 SDK, dnx downloads the package from NuGet and runs it directly — no install step:

dnx -v q --yes Sherlock.MCP.Server@2.15.0

--yes skips the interactive confirmation prompt, which an MCP client launching the server over stdio can't answer. -v q stops dnx from printing a "Skipping NuGet package signature verification." notice to stdout the first time it downloads a version, which would otherwise corrupt the MCP stream and fail that first connection. Both are dnx options, so they must come before the package id; anything after it is passed to the server. Pinning the version keeps launches reproducible; bump it when you want to upgrade. The package is published with the McpServer package type, so it is also listed as an MCP server on NuGet.org.

Install as a global tool

On any supported SDK (.NET 8 or later), install the global tool from NuGet (adds sherlock-mcp to your PATH):

dotnet tool install -g Sherlock.MCP.Server

Alternatively, during development you can run the server locally:

dotnet run --project src/server/Sherlock.MCP.Server.csproj

Configure Your MCP Client

Sherlock runs as a standard MCP server that communicates over stdio.

Claude Code plugin

This repository is also a Claude Code plugin marketplace. The sherlock plugin bundles the server (launched with dnx, so it needs the .NET 10 SDK) and a skill that teaches the agent the locate → orient → drill-in → relationships workflow:

/plugin marketplace add jcucci/dotnet-sherlock-mcp

/plugin install sherlock@dotnet-sherlock-mcp

The plugin starts the server with the core tool profile, which matches the tools the skill covers. The agent can add the other tools by group with load_tools when it needs them (see Tool groups). To expose every tool from the start, set SHERLOCK_TOOL_PROFILE=full in the environment Claude Code is launched from.

Each user runs these commands once; restart Claude Code (or run /reload-plugins) afterwards. To pick up a new release, run /plugin marketplace update dotnet-sherlock-mcp. If you previously registered Sherlock with claude mcp add, remove that entry (claude mcp remove sherlock) so the tools aren't loaded twice.

Team setup

To offer the plugin to everyone working in a repository, commit the following to that repository's .claude/settings.json. Claude Code prompts each teammate to install it when they trust the folder, so nobody has to type the commands above:

{

"extraKnownMarketplaces": { "dotnet-sherlock-mcp": { "source": { "source": "github", "repo": "jcucci/dotnet-sherlock-mcp" } } }, "enabledPlugins": { "sherlock@dotnet-sherlock-mcp": true } }

Teammates still need the .NET 10 SDK on their PATH for dnx.

Using dnx

• Claude Code:

claude mcp add sherlock -- dnx -v q --yes Sherlock.MCP.Server@2.15.0

• VS Code (.vscode/mcp.json):

{

"servers": { "sherlock": { "type": "stdio", "command": "dnx", "args": ["-v", "q", "--yes", "Sherlock.MCP.Server@2.15.0"] } } }

Using the global tool

• Cursor: Settings → MCP / Custom tools → Add tool → Command: sherlock-mcp
• Claude Desktop / other MCP clients: Add a server entry pointing to the sherlock-mcp command. Example JSON entry (refer to your client’s docs for exact file location/format):

{

"servers": { "sherlock": { "command": "sherlock-mcp" } } }

No arguments are required. The server self-registers all tools when launched.

Tool profiles

Large tool lists cost agents context and discoverability (Claude Code switches to deferred Tool Search once tool descriptions grow past roughly 10% of the context window). Sherlock can start with a smaller surface:

Select a profile with the --profile argument or the SHERLOCK_TOOL_PROFILE environment variable (the argument wins). An unknown profile name stops the server with an error.

{

"servers": { "sherlock": { "command": "sherlock-mcp", "args": ["--profile", "core"] // or: "env": { "SHERLOCK_TOOL_PROFILE": "core" } } } }

Tool groups

Under the core profile every other tool belongs to a group that the agent can load when it needs it:

• `load_tools`: with no arguments, lists every group, its tools and whether it is loaded. With groups=['frameworks', …], it adds those tools to the server's tool list and returns each loaded tool's name, description and input schema. The server then sends notifications/tools/list_changed. Under protocol revision 2026-07-28 that only reaches clients that asked for it through subscriptions/listen.
• `invoke_tool`: calls a loaded tool by name with its arguments object and returns that tool's own result. Clients that never refresh their tool list can still use loaded groups this way. Calling a tool whose group isn't loaded fails with ToolNotLoaded and names the group.
• Discovery hints: core results can carry hints[], each { tool, reason, group }, pointing at a related tool. Examples:
• get_type_info on a type with nested types or generic parameters, or one that is a DbContext, controller or MediatR handler;
• find_implementations_of / find_references_to / find_extension_methods_for on those framework types or IServiceCollection;
• decompile_member → decompile_type;
• get_project_output_paths → analyze_project and get_package_graph.

Dependency errors suggest get_package_graph. group is null for core tools.

• Tool list caching: under core, tools/list is marked cacheScope: private, since a session's tool list grows as groups load. Under full, it stays public.

The full profile lists every tool and omits load_tools and invoke_tool.

Auto-Configure for .NET Projects

You usually don't need to paste anything. Sherlock ships its usage guidance in the MCP instructions field returned at initialize, and most MCP clients (including Claude Code) surface that to the agent automatically — so the guidance stays correct and versioned with the package, with no copy-paste to maintain.

The snippets below are optional reinforcement. Keep them short and principle-based rather than enumerating tool names and workflows: a static list pasted into your repo will drift as Sherlock's tools evolve, whereas the tools' own descriptions (and the server instructions) always match the version you're running.

Tool names are exposed in snake_case (get_type_members, search_members, …); argument names stay camelCase (projection, nameContains).

Claude Code (CLAUDE.md)

If you installed the Claude Code plugin, its skill already covers this. Otherwise, you can add a short, optional pointer to your project's CLAUDE.md:

## .NET Assembly Analysis

Use the Sherlock MCP tools (get_type_members, search_members, …) for .NET type/assembly questions instead of guessing. Locate DLLs with the find_assembly_by_* / `get_project_outp