What is Glider?

Glider is a local MCP server that helps coding agents navigate, analyze, and refactor C#/.NET codebases using semantic code information instead of plain text search.

Why not just use grep or ripgrep?

Grep finds matching text. Glider finds code relationships: real definitions, references, implementations, overrides, callers, diagnostics, and change impact.

Why not just rely on the LLM?

The LLM does not automatically know your local codebase. Without tools, it guesses from opened files and search results. Glider gives it structured facts about the loaded solution.

Does my code leave my machine?

No. Prompts, source code, file paths, symbol names, and customer data are never sent to Glider servers. The MCP server runs locally and analyzes files in your workspace.

The products do send anonymous usage telemetry (versions, OS, tool names, error categories) by default to help us improve them. It contains nothing that identifies you or your project, and you can turn it off — see What we collect.

What telemetry does Glider send, and how do I disable it?

Glider sends anonymous usage data: a random install id, product and version, OS and architecture, runtime version, tool names with a duration bucket and outcome, error categories (type names only), and coarse workspace shape counts. It never includes code, prompts, paths, or names. Country is derived at the edge and your IP is never stored.

To disable it, run the server with the --no-telemetry flag (or set DO_NOT_TRACK=1 in the environment that launches it). The full field list is on the What we collect page.

Which clients work with Glider?

Any MCP-compatible client. The install docs include setup guides for Claude Code, Cursor, GitHub Copilot, Codex, Gemini CLI, OpenCode, Pi, and generic MCP clients. See Compatibility for client and transport details.

Does it support .NET Framework?

Yes, as long as the project or solution can be loaded and analyzed successfully with your local .NET/MSBuild tools. Windows with a stable Visual Studio/MSBuild installation is the most reliable setup for legacy .NET Framework solutions. See Compatibility for the full matrix.

Can it change files?

Yes, for supported refactoring and file-write workflows. Prefer preview-first changes where available, especially when editing shared code.

What do I need to install Glider?

You need the .NET 10 SDK installed locally and an MCP-compatible client.

Run dotnet --version before installing. If dotnet tool install succeeds but glider is not found, confirm that your .NET tools directory is on PATH.

Can I use HTTP transport?

Yes. Run glider --transport http --default-timeout 30m to start a Streamable HTTP MCP server at http://localhost:5001/mcp. This is useful for clients that connect over HTTP.

Which model should I use with Glider?

For backend-heavy C#/.NET work and workflows with frequent MCP tool calls, we currently see the best results with GPT-5.5. It consistently reaches for Glider tools such as find_code, find_references, and get_diagnostics instead of falling back to plain text search.

Some Anthropic Claude models are more conservative about invoking MCP tools by default and may prefer built-in file search. If you use Claude, an explicit instruction in your project rules (for example, "prefer Glider MCP tools for C# navigation and diagnostics") usually improves tool adoption.

Glider works with any MCP-compatible model and client. This is guidance based on observed defaults, not a requirement.

Can I run multiple Glider instances for different solutions?

Yes. Add one named server entry per solution in your MCP config and point each at a different solution with --solution. Each entry starts its own Glider process with its own loaded workspace.

--workspace sets the root directory for file watching and auto-sync. If you omit it, Glider watches the enclosing git repository root of the solution file, so sibling folders in the same repository stay in sync. Pass --no-watch to disable file watching entirely.

With HTTP transport, also give each instance a distinct --port (for example --transport http --port 5001 and --transport http --port 5002), and point each client entry at its own URL.

{
  "mcpServers": {
    "glider-backend": {
      "command": "glider",
      "args": ["--default-timeout", "30m", "--solution", "C:/repos/shop/backend/Backend.sln"]
    },
    "glider-services": {
      "command": "glider",
      "args": ["--default-timeout", "30m", "--solution", "C:/repos/shop/services/Services.sln", "--workspace", "C:/repos/shop"]
    }
  }
}

Why is the first query after loading a large solution slow?

The initial semantic analysis of a workspace is built on demand. On large solutions that used to make the first query after a load noticeably slower than the rest.

Glider now warms that analysis in the background automatically after every load and explicit reload. Progress is reported by server_status under workspaceWarmup, including how many projects are warmed and an estimated time remaining. Semantic tools work during the warm-up — early calls are just slower until it completes.

Background reloads triggered by file watching do not restart the warm-up, so editing files never causes repeated warm-up work. Pass --no-warmup at startup to disable warm-up entirely (first queries then build the analysis on demand).