When you ask an AI coding agent to understand a C# solution, you quickly hit two problems:

  • Text search is not semantic. Grep cannot reliably answer questions about symbols, types, overloads, or implementations.
  • The agent burns context and time doing many small tool calls (search -> open file -> search again -> open file again).

Glider MCP is my attempt to fix both. It is a Roslyn-powered Model Context Protocol (MCP) server that gives MCP clients (like Claude Code) compiler-grade understanding of your codebase: symbols, types, relationships, diagnostics, and safe refactors.

Official docs and installation guides: glidermcp.com/installation

Setup (Claude Code)

Glider is a .NET global tool (requires .NET 10.0+):

dotnet tool install --global glider

Then add it to Claude Code (project scope is recommended so it only runs inside that repo):

claude mcp add --transport stdio glider --scope project -- glider

For the full, up-to-date instructions (including PATH troubleshooting) for all other MCP clients, use the official guide: glidermcp.com/installation/

Why Glider is useful (especially in real codebases)

1) Fewer tool calls with batching

Glider includes a batch tool so Claude Code can run multiple operations in one request. In practice, this cuts down the loop of calling a tool, waiting, then calling another tool when you are exploring a new area.

Example prompt idea:

Run a batch: get_type_info for UserController, then find_usages of Login (summaryOnly), then summarize the results.

2) Less context bloat (summary output + paging)

A lot of tools are designed to be token-friendly:

  • summaryOnly when you just need counts first (e.g., diagnostics, type search, symbol usages)
  • paging via skip/take when results are large
  • predictable, structured results (file path + line/column + line text) instead of dumping whole files

This helps LLMs stay within context limits and keeps the conversation focused on decisions, not raw data.

3) Things grep cannot do

Because Glider uses the Roslyn compiler platform (not regex), it can answer questions that are either painful or impossible with plain text search:

  • Resolve symbols the same way the compiler does (namespaces, usings, generics, partial types, overloads).
  • Find real implementations and real usages (not string matches that only look similar).
  • Get accurate type info and method signatures (including parameter types and locations).
  • Surface compiler diagnostics across the loaded solution/project.
  • Perform safe, semantic refactors (rename symbols, move types/members) and preview the diff before applying changes.
  • Jump into external code: view NuGet/framework definitions via SourceLink or decompilation.

4) An API surface designed for agents (not just a bag of tools)

A lot of MCP servers start as thin wrappers around existing CLI tools. That can be useful, but it often produces noisy outputs and ad-hoc parameters.

Glider is designed like a real API:

  • consistent sorting/paging/filtering options where it matters
  • timeouts for long-running operations (timeout_ms)
  • change safety features for refactors (preview vs apply, limits for reference updates)
  • stable, well-documented tool contracts

The goal is simple: make LLMs faster and more reliable, with less prompt engineering.

5) Local-first by design

Glider runs on your machine and analyzes your local workspace. Privacy is a core design goal: glidermcp.com/privacy

Conclusion

If you build software in C# long enough, you start to appreciate tools made with love for correctness. Glider is that kind of tool.