dotnet-read

Reading and navigating C# with dotnet-toolkit

Every question below is answered by a Roslyn-backed MCP tool that reads the compiler's own model. Grep, Glob, find, cat, sed and bare Read on a .cs file are wrong here, not just slower — they cannot see interface, virtual or delegate dispatch, count comment and string matches as real hits, silently under-report when output is truncated, and hand back one fragment of a partial class with no signal that the rest exists. A PreToolUse hook adds an advisory note when Read or a shell read reaches a compiled .cs file, but does not block it — Grep/Glob are watched by no hook at all. The router below, not hook enforcement, is what actually keeps you on the right tool.

Tool names are prefixed mcp__plugin_dotnet-toolkit_dotnet__.

Step 0 — call workspace_status before any read

First MCP call of the session, always. It is free, takes no arguments, records no telemetry, and gives you two things nothing else can:

1. Readiness. Until the workspace is loaded, semantic tools answer from the syntax tier or refuse outright. A zero-hit from get_references, get_call_hierarchy, get_call_slice, get_type_hierarchy or get_semantic_diff against a cold workspace is workspace state, not absence — never report it as "nothing uses this".

2. pluginRoot. The plugin's install directory, and the only supported way to reach a file that ships with the plugin. Join it yourself:

   • a tool manual → <pluginRoot>/docs/tools/<tool>.md
   • a coding standard → <pluginRoot>/standards/<name>.md

   Never write ${CLAUDE_PLUGIN_ROOT} into a path. The harness substitutes it into .mcp.json args, hook commands and skill content, but not into a rule or an agent definition, so it stays literal and the read fails. Read the joined path — the guards only block .cs.

Re-call it whenever a response comes back stale or degraded (see Workspace readiness below).

Step 1 — load the tool by its exact name