claude-roslyn-lsplisted

# Roslyn C# workflow The MCP server's `initialize` instructions already state the conventions that span every tool — 1-based positions, workspace-relative paths, symbols addressed by name or by `path:line:col`, edits written straight to disk — and each tool's schema describes its own arguments. Neither can say which tool to reach for *instead of* the one you were about to reach for, or what order the calls go in. That is this file. ## Before you grep A question about a C# **symbol** has an exact answer, and text search does not know it. Grep finds a name; it cannot tell an override from a coincidence, it misses every call through an interface, and it reports the same identifier in a comment, a string and an unrelated namespace. - *Where is this declared, and what is its signature?* — `resolveSymbol`. It takes a name (`IScheduler.Start`, matched as a dot-segment suffix), so you do not need a line number to start from, and ambiguity comes back as every candidate rather than as a guess. - *Who calls it? What breaks if I change it?* — `findReferences`, with the source line beside each hit and a per-file summary. This is the call that decides whether a change is a two-line edit or a refactoring. - *What does this type have on it?* — `getTypeMembers`, which answers without reading the file at all, and answers for a type in a NuGet package or the BCL just as well as for one in the checkout. - *Then the built-in `LSP` tool, by position* — hover, go to definition, type d