Reported issues for dotnet-sherlock-mcp

Pod holds 17 of 17 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to dotnet-sherlock-mcp.

Most discussed

Too many file watches on Linux

I don't know why, but the sherlock-mcp on my ubuntu system has reached the (already increased) max inotify threshold. I tracked it down to the sherlock, which consumes massive amount of inotify.

Read the thread · 2026-04-28 · closed · external user · 1 comment

Signature rendering polish (umbrella)

Consumer report

Signature rendering nits.

Nullable<int> → int? (and IList<RecordedEvent> etc. are already fine — just this one)

overwrite = True / combineSubstreams = False — C# literal should be lowercase.

public abstract on interface members is redundant noise.

Snapshot\u00601 in FullName leaks backtick-arity encoding to the user; consider normalizing display to Snapshot<> or keeping Snapshot\1` but not letting the unicode-escaped form through JSON.

Read the thread · 2026-04-18 · closed · 1 comment

Add direct NuGet package -> assembly lookup tool

Consumer report

NuGet-aware lookup. I knew "Sharp.Events v41.0.1" but had to find ~/.nuget/packages/... manually. A find_assembly_by_nuget_package(packageId, version?, tfm?) that probes ~/.nuget/packages/<id>/<v>/lib/<tfm>/ would save a lot of grep. Or have assemblyPath accept sharp.events:41.0.1 shorthand.

Validation

ResolvePackageReferences already exists (src/server/Tools/ProjectAnalysisTools.cs:66-82) but it requires a project file path. There is no direct package-

Read the thread · 2026-04-18 · closed · 1 comment

Add reverse-lookup tools: implementations, returns, references

Priority: High — flagged by an AI consumer as the most-requested missing capability.

Consumer report

Cross-reference queries are missing. The three most valuable questions I had no tool for:

"What implements IEventStreamReader?"

"What methods return Snapshot<T>?"

"What references RecordedEvent?"

I ended up using strings over the DLL via Bash. find_implementations_of(typeName), find_references_to_type(typeName), find_methods_returning(typeName) would b

Read the thread · 2026-04-18 · closed · 1 comment

Add projection (summary|full) parameter to listing endpoints

Consumer report

Response size on listing endpoints. get_types_from_assembly for a mid-size assembly blew past the token limit (147KB for Sharp.Events — forced me to dump to a file and parse with Python). The per-type payload includes attributes + base type + interfaces + generic params + nested types, which is great for a detail view but overkill for a listing. Consider a projection: \"summary\"|\"full\" parameter — summary returns {FullName, Namespace, Kind} only. Similar for `get_t

Read the thread · 2026-04-18 · closed · 1 comment

AttributeUtils leaks RuntimeType to System.Text.Json

Priority: High — flagged by an AI consumer as a session-blocker.

Consumer report

Attribute dumping can't serialize Type values. Repeated Serialization and deserialization of 'System.RuntimeType' instances is not supported on e.g. Sharp.Events.RecordedEvent and EventApplicator methods. [JsonConverter(typeof(X))] puts a Type into ConstructorArguments, which System.Text.Json can't handle. Project Type args to `{ "typeFullName": t.FullName, "assemblyName": t.Assembly

Read the thread · 2026-04-18 · closed · 1 comment

Switch tool surface from default ALC to MetadataLoadContext

Priority: High — flagged by an AI consumer as a session-blocker.

Consumer report

Load context is the biggest issue. I hit Could not load file or assembly 'Newtonsoft.Json, Version=13.0.0.0' multiple times on get_type_methods/get_type_properties (Sharp.Events types whose attributes touch Newtonsoft). Cause: server/Tools/*.cs uses Assembly.LoadFrom into the default ALC with no resolver wired up. You already have DependencyResolvingLoadContext and reference `System.Reflection.M

Read the thread · 2026-04-18 · closed · 1 comment

Transitive assembly resolution issue

The assembly resolver in dotnet-sherlock sometimes cannot load transitive dependencies even though the DLL existed in the same directory. This appears to be an assembly binding/resolution issue within the MCP tool when the target assembly has dependencies on other assemblies.

Read the thread · 2026-01-14 · closed · 1 comment

Most recent

Upgrade ModelContextProtocol SDK from 0.3.0-preview.2

Why

src/server/Sherlock.MCP.Server.csproj pins ModelContextProtocol at 0.3.0-preview.2. Preview-to-newer upgrades in this SDK have had breaking changes around WithToolsFromAssembly, attribute namespaces, and DI parameter injection into static tools — the upgrade likely touches all 7 tool files mechanically.

Plan

Land the end-to-end MCP integration tests first (separate issue) — they are the only realistic regression net for transport-level changes.
Check the current stable

Read the thread · 2026-06-11 · closed · 0 comments

End-to-end MCP integration tests over stdio

Why

Integration coverage is currently a single Linux inotify test. Nothing exercises the actual MCP wire protocol: tool discovery, invocation, envelope shape, pagination round-trips. This is also the prerequisite regression net for the ModelContextProtocol SDK upgrade.

Proposal

Add a fixture in src/integration-tests that launches the built server as a child process over stdio and drives it with the ModelContextProtocol client package (McpClientFactory + StdioClientTransport):

Read the thread · 2026-06-11 · closed · 0 comments

Persistent on-disk assembly index for reverse lookup

Why

IndexStore and NoopAssemblyIndexService are placeholder stubs ("Minimal in-memory placeholder for future on-disk store"). Reverse lookups now scan in parallel with shared contexts (Phase A), but repeat queries against large solution-wide scopes still re-walk every type. An on-disk index makes repeat reverse lookups near-instant.

Build this only if Phase A parallelism proves insufficient on real workloads — measure first.

Sketch

Per-assembly index file under `~/.sherlock-m

Read the thread · 2026-06-11 · open · 0 comments

GetTypeHierarchy: populate DerivedTypes via optional searchScope instead of silent empty array

Problem

TypeAnalysisService.GetTypeHierarchy always returns an empty DerivedTypes array (documented internal stub). Consumers can't tell "no derived types" from "not computed" — the empty array is actively misleading to an LLM.

Proposal

Two-part fix:

Add optional searchScope (additional assembly paths) parameter to the GetTypeHierarchy tool. When provided, populate derived types via ReverseLookupService.FindImplementations (already does exactly this scan).
When absent (t

Read the thread · 2026-06-11 · closed · 0 comments

AnalyzeSolution returns zero projects for .slnx solutions

Problem

ProjectAnalysisService.AnalyzeSolutionFileAsync parses solutions with a regex that only understands the classic .sln format. The new XML .slnx format — which this very repository uses (src/Sherlock.MCP.slnx) — silently returns zero projects.

Fix

Branch on file extension in AnalyzeSolutionFileAsync:

.sln → existing regex path.
.slnx → XDocument parse of <Project Path="..."/> elements (including <Folder> nesting), filtered to the supported `.csproj/.vbproj/

Read the thread · 2026-06-11 · closed · 0 comments

Add GetAssemblyInfo tool: assembly-level attributes, TFM, and references

Why

There is no tool for assembly-level metadata: target framework, version attributes, InternalsVisibleTo, or referenced assemblies. These are cheap to extract and frequently needed for orientation before deeper analysis.

Proposal

New GetAssemblyInfo tool in ReflectionTools:

ctx.Assembly.GetCustomAttributesData() + existing AttributeUtils.Convert (already extracts constructor/named args structurally).
Assembly.GetReferencedAssemblies() for names/versions.
Summary pro

Read the thread · 2026-06-11 · closed · 0 comments

IL call analysis: GetMethodCalls tool and analysisDepth=il for FindReferencesTo

Why

FindReferencesTo is signature-surface only (base types, interfaces, method returns/params, field/property/event types). It cannot answer "who actually calls X?" or "what does this method call?" — method bodies are invisible. This is the single biggest capability unlock for LLM code-navigation workflows.

Proposal

New src/runtime/IlAnalysisService.cs using System.Reflection.Metadata directly (already in the dependency closure via System.Reflection.MetadataLoadContext):

Read the thread · 2026-06-11 · closed · 0 comments

Add FindExtensionMethodsFor tool: discover extension methods for a target type

Why

For LINQ-style APIs the interesting surface isn't on the type itself — it's extension methods declared elsewhere. There is currently no way to answer "what extension methods exist for IEnumerable<T>?" without scanning every static type manually.

Proposal

New FindExtensionMethodsFor tool alongside the other reverse-lookup tools (src/server/Tools/ReverseLookupTools.cs + ReverseLookupService).

Scan static classes for methods carrying `System.Runtime.CompilerServices.Extens

Read the thread · 2026-06-11 · closed · 0 comments

Add SearchMembers tool: assembly-wide member search by name fragment

Why

Today the LLM must know the declaring type before it can find a member (GetTypeMethods etc. all require typeName). The most common real question is the inverse: "where is ParseConnectionString defined?" There is no way to search an assembly for a member by name without enumerating every type first.

Proposal

New SearchMembers tool in a new src/server/Tools/SearchTools.cs, backed by a new ISearchService/SearchService in src/runtime.

Parameters: assemblyPath, `

Read the thread · 2026-06-11 · closed · 0 comments

The remaining reports are on the project's issue tracker.