dotMCP.win-x64 0.7.0

dotMCP

MCP server that exposes a C# solution as a semantic graph over Roslyn, instead of requiring an LLM agent to grep files and re-parse text on every step.

What it's for

Connect this server to an MCP-capable client (Claude Code, VS Code + Copilot, Cursor, etc.) so the agent can navigate, analyze, and edit a C# solution through typed tool calls (get_type, get_call_graph, find_writes, rename_symbol, concurrency_audit, search_code, find_duplicates, tests_run, and more) instead of raw file search-and-replace.

All tool responses are TOON-encoded (Token-Oriented Object Notation, spec v3): the same facts as JSON with camelCase keys and nulls omitted, at a fraction of the token cost — uniform result lists collapse into one header plus tabular rows.

See the repository at https://github.com/QsROg8320/SharpMCP — .claude/skills/dotmcp-tools/SKILL.md there documents all 66 tools with real tested examples, argument constraints, and known gaps.

The repository also ships a standalone sharpmcp-trace CLI — no MCP client needed — for reachability-corridor analysis and auto-instrumented entry/exit logging between methods; see sharpmcp-trace CLI below.

Usage via NuGet (dnx)

VS Code / clients that use a "servers" config block:

{
  "servers": {
    "dotMCP": {
      "type": "stdio",
      "command": "dnx",
      "args": ["dotMCP@0.4.0", "--yes"]
    }
  }
}

qwen-code / Pi Coding Agent / other clients that use a plain "mcpServers" block (do not include "servers" or "type" here — those are VS Code-specific and will be rejected by these clients):

{
  "mcpServers": {
    "dotMCP": {
      "command": "dnx",
      "args": ["dotMCP@0.4.0", "--yes"]
    }
  }
}

Requires the .NET 10 SDK (for the dnx command) on the machine running the MCP client.

Unpacking the bundled skill (Claude Code)

The package embeds the full tool reference (SKILL.md: every tool with argument constraints and real captured request/response examples). The server can deploy it into your Claude Code skills directory on startup — opt-in, it never writes outside its working directory unless you ask:

1. Set DOTMCP_DEPLOY_SKILL=true in the server's environment, e.g.:

   {
     "mcpServers": {
       "dotmcp": {
         "command": "dnx",
         "args": ["dotMCP@0.4.0", "--yes"],
         "env": { "DOTMCP_DEPLOY_SKILL": "true" }
       }
     }
   }
   

2. On every server start the skill is (re)written to ~/.claude/skills/dotmcp/SKILL.md — upgrades refresh it automatically. Set DOTMCP_SKILLS_DIR to redirect the skills root (the dotmcp/SKILL.md part stays).

3. Restart Claude Code (or start a new session); the dotmcp skill is picked up automatically and teaches the agent every tool below.

Tools at a glance (66)

Workspace — workspace_open open a .sln/.slnx/.csproj (mandatory first call); get_structure namespace/type hierarchy with doc one-liners; get_diagnostics compiler errors/warnings for solution/project/type/method.

Navigation — get_type type card (member signatures, doc, usedBy/uses); get_method full method with symbol map, callers/callees, version token; get_source any node as C# text; get_lines raw line range of a file; get_symbol "what is this?" incl. NuGet/BCL symbols; search_symbols ranked name search; search_text search string literals/comments/XML doc; search_code regex over the raw code text (the grep of the graph).

Usages — find_usages all references classified read/write/invocation/argument; find_local_usages usages of a local/parameter inside its method; type_usages where a type appears (fields, params, returns, generics); get_instantiations where and with what arguments a type is constructed.

Code graph — get_method_nodes CFG nodes of a body; replace_node swap one CFG node; get_reaching_conditions path conditions to a node; get_call_graph callers/callees tree; reach is there a call path A→B; get_type_hierarchy base/derived tree; find_implementations interface/abstract implementors; impact_of transitive blast radius of changing a member.

Analysis — complexity cyclomatic + cognitive ranking; find_duplicates structural duplicate clusters (canonicalized tokens); concurrency_audit ranked suspicious-concurrency findings (lock asymmetry, check-then-act, blocking under lock...); find_dead_code uncallable/unused/unreachable; entry_points execution roots; get_effects reads/writes/IO/sync/blocking/spawns/purity of a method; find_writes / find_reads field access sites with lock context; get_argument_values what values flow into a parameter; event_flow raise/subscribe map of an event; trace_value where a value comes from / flows to; decompile C# of NuGet/BCL symbols; run run the project; tests_list / tests_for / tests_run discover, map, and execute tests (TUnit/xUnit/NUnit/MSTest); coverage line + branch coverage of the code exercised by the tests in scope (Cobertura via Coverlet or the Microsoft.Testing.Platform collector), with uncovered branch sites and a CRAP-score risk ranking; probe temporary counters through a test run; trace_test per-test execution paths.

Editing (guarded) — add_type new type (with usings support); add_member add method/property/field/event; replace_method_body swap statements; replace_member replace a whole declaration (attributes, signature, base(...)); move_member relocate a member; move_file relocate/rename a file on disk, syncing its namespace to the destination folder and fixing up every external reference across the solution; update_doc rewrite XML doc; delete_member / delete_file safe-delete with usage guard; change_signature change parameters atomically across all call sites; rename_symbol solution-wide rename; find_replace regex edit inside a member/type or a whole file (doc: scope). Every edit re-parses before applying, reports semantic/ripple diagnostics plus a unified diff, and leads with an explicit warning if the code no longer compiles.

Project ops — changes_list / changes_diff what changed since the last commit; commit snapshot; revert_file undo one file; package_add / package_remove / package_list NuGet references; project_create / project_remove projects; asset_list / asset_read / asset_write non-code files (configs, json, ...).

Environment variables

• DOTMCP_RELOAD_DEBOUNCE_SECONDS — quiet period of the file watcher before external edits trigger a workspace reload (default 60).
• DOTMCP_DEPLOY_SKILL=true — opt-in: deploy the bundled Claude Code skill doc on startup.
• DOTMCP_SKILLS_DIR — overrides the skills directory for that deployment.

sharpmcp-trace CLI (standalone)

A separate command-line tool — not an MCP server, no client/agent needed — built on the same Roslyn engine as dotMCP. It answers "can method A reach method B, through what, and are there cycles along the way?", then can rewrite every method on that path to log its own entry, exit, and thrown exceptions (parameters, fields, locals, return value) so you can watch a real run trace through unfamiliar code.

Install as a .NET global tool:

dotnet tool install --global dotMCP.Trace

(or run without installing: dnx dotMCP.Trace --yes -- <command> ...)

find — look up a method id

sharpmcp-trace find "OrderService.Place" --solution ./MyApp.sln

Prints id | signature | project for every fuzzy match, so you can copy the exact id into --point below instead of guessing it.

paths — reachability corridor + cycles (read-only)

sharpmcp-trace paths --solution ./MyApp.sln \
  --point "M:MyApp.Api.OrdersController.Post(MyApp.Order)" \
  --point "M:MyApp.OrderService.Place(MyApp.Order,System.Int32)"

• --point is repeatable (give 2 or more): an exact M: id, a file.cs:line location, or a fuzzy name (ambiguous matches print candidates instead of guessing). An interface method as a point expands to all of its implementations in the solution.
• No --point at all → defaults to --scope solution (or pass --scope <projectId> for one project): seeds from the project's conventional entry points (Main, tests, controller actions), falling back to every declared method with --seed all-methods if there are none (typical for a pure library).
• Reports, per ordered pair of points, whether it's reachable and how large the corridor is; only one pair needs to be reachable. Also reports any cycle found inside the corridor (purely informational — never changes what gets instrumented).
• Nothing is written to disk by this command.

log — insert entry/exit/throw logging

sharpmcp-trace log --solution ./MyApp.sln \
  --point "M:MyApp.Api.OrdersController.Post(MyApp.Order)" \
  --point "M:MyApp.OrderService.Place(MyApp.Order,System.Int32)" \
  --log-file ./trace.log

Runs the same corridor analysis as paths, then rewrites every method in it to log ENTRY (parameters + fields), EXIT (+ locals declared before that point + return value), and THROW (+ the exception) — both to the console and to --log-file. Idempotent: a method that's already instrumented is skipped and reported as already-instrumented, so re-running log after adding a new point is safe.

unlog — remove the logging

sharpmcp-trace unlog --solution ./MyApp.sln

Finds every file carrying the instrumentation marker and reverts it with git checkout -- (requires the instrumented files to still be tracked/committed in git — this is a revert, not a structural undo).