glider 10.3.0

There is a newer version of this package available.
See the version list below for details.
{
  "servers": {
    "glider": {
      "type": "stdio",
      "command": "dnx",
      "args": ["glider@10.3.0", "--yes"]
    }
  }
}
                    
This package contains an MCP Server. The server can be used in VS Code by copying the generated JSON to your VS Code workspace's .vscode/mcp.json settings file.
dotnet tool install --global glider --version 10.3.0
                    
This package contains a .NET tool you can call from the shell/command line.
dotnet new tool-manifest
                    
if you are setting up this repo
dotnet tool install --local glider --version 10.3.0
                    
This package contains a .NET tool you can call from the shell/command line.
#tool dotnet:?package=glider&version=10.3.0
                    
nuke :add-package glider --version 10.3.0
                    

Glider - Semantic C# MCP Server

Glider is a semantic C#/.NET MCP server for code navigation, diagnostics, analysis, and refactoring. It gives your coding agent what your IDE gives you: go to definition, find references, safe rename. These are compiler-backed facts, not text search and guesswork. Your agent spends fewer tokens and returns better answers.

Install

Prerequisite: .NET 10 SDK.

dotnet tool install --global glider

If install fails, run dotnet --version first. If dotnet is missing or below 10, install .NET 10 from: https://dotnet.microsoft.com/download/dotnet/10.0

Capabilities

  • Solution/project lifecycle: load, sync, reload, unload
  • Discovery and inspection: find_code, search_symbols, resolve_symbol, get_symbol_info, get_symbol_at_position
  • References and hierarchy: find_references, find_overrides, find_implementations, get_type_hierarchy, find_callers
  • Diagnostics and code search: get_diagnostics, diagnostic_hotspots, semantic_query, search_text
  • Refactoring and edits: rename_symbol, move_type, move_member, organize_usings, format_document, write_file
  • Dependency and impact analysis: analyze_change_impact, get_cascade_impact, get_project_graph, find_package_usages
  • Batch execution: batch

For general code navigation, find_code is the recommended first tool to try. The full tool reference lives at https://glidermcp.com/glider/tools.

Text Search Scope

search_text searches only the loaded solution or project. It skips a file that no loaded project references.

For repo-wide, all-language search, add Scout as its own MCP server and call its find tool. It is the fastest search you can give a coding agent. In our benchmarks, on a warm index, it answered every text search faster than ripgrep (1.9–2.2×). It ran 42–51× faster than GNU grep.

Scout also answers questions no text search can express. An agent asks in plain English: "where request retries are limited". Scout finds the code even when the code uses none of those words. Your agent no longer guesses at grep patterns. Structural search matches the shape of the code, not its text. Fuzzy search finds a file from a name you remember only in part.

Plain-English search is opt-in. Start Scout with --semantic, or set semantic.enabled = true in its config. Scout then embeds the workspace once, in the background. That pass took about 10 hours for 0.87 GB of code in our benchmark. Lexical search does not wait for it. The text index is ready in seconds, and Scout answers plain-English questions with text search until the embeddings are ready.

Run Modes

Stdio (default)

glider

HTTP

glider --transport http

Default HTTP MCP endpoint: http://localhost:5001/mcp

Useful flags:

glider --default-timeout 30m
glider --build-host netframework
glider --msbuild-path "C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin"
glider --port 8080
glider --solution "C:\repos\app\src\App.sln"
glider --solution "C:\repos\app\src\App.sln" --workspace "C:\repos\app"
glider --solution "C:\repos\app\src\App.sln" --no-watch
glider --verbose
glider --help
glider --version

Flag reference

  • --default-timeout — supports ms, s, and m suffixes. Use 0 to disable the server-side timeout.

  • --build-host — accepts auto, netframework, and netcore. It changes Roslyn's remote build-host selection, not the Glider server runtime.

  • --msbuild-path — points Roslyn's remote build-host process at a specific MSBuild installation by setting its MSBUILD_EXE_PATH environment.

  • --solution — loads a .sln, .slnx, or .csproj automatically at startup, so agents don't need to call the load tool first.

    • The load runs in the background: the server answers MCP requests immediately, and a failed load leaves the server alive so you can retry load.
    • While it runs, server_status reports progress under workspaceLoading, with an ETA from this workspace's previous load time.
    • Relative paths resolve against the launch directory; prefer absolute paths in shared configs.
  • --workspace — sets the root directory that the file watcher monitors for auto-sync.

    • When omitted, Glider watches the git repository root of the loaded file. Outside a repository, it watches the file's own directory. This helps when the solution sits in a subfolder and related code lives in sibling folders.
    • In a large monorepo, this wide root also detects edits to unrelated files, and each edit can trigger a workspace refresh. Pass --workspace with a narrower directory, or --no-watch, if the refreshes become too frequent.
    • The workspace still loads if the watcher cannot start, for example when the OS reaches its inotify limit. Glider disables auto-sync and reports the reason in the load result's fileWatcher.error.
  • --no-watch — disables the file watcher and auto-sync for the startup load. Do not combine it with --workspace.

Why you might need --build-host and --msbuild-path:

  • Use --build-host netframework when Roslyn auto-selects the wrong host family for legacy Windows solutions. This is common for older ASP.NET, desktop, test, and non-SDK projects that evaluate better inside the .NET Framework build host than the .NET Core one.
  • Use --msbuild-path when the host family is correct but Roslyn still picks the wrong toolset inside that host. This matters when multiple MSBuild installs exist on the machine and a solution only loads cleanly with one specific Visual Studio or SDK toolset.
  • In practice, --build-host answers "which Roslyn build-host process should evaluate the project?" and --msbuild-path answers "which MSBuild install should that process use once it starts?"

Configure Your MCP Client

Use installation and host-specific setup guides on the website:

Version Expiration

Each Glider version expires 1 month after release date.

dotnet tool update --global glider

Troubleshooting

  • If glider is not found after install, ensure ~/.dotnet/tools is on PATH.
  • If load fails with MSBuild initialization errors, rerun with --verbose and inspect returned diagnostics.
  • For legacy .NET Framework web, desktop, or test solutions on Windows, retry with --build-host netframework when auto selects an incompatible Roslyn build host.
  • If the host kind is correct but Roslyn picks the wrong MSBuild toolset, add --msbuild-path. Point it at the Visual Studio or SDK MSBuild location you want.
  • On Windows, prefer a stable Visual Studio install for legacy .NET Framework solutions.

License

Free for personal use, open-source work, education, and a 30-day organizational evaluation under the GliderMCP EULA. Commercial use requires a paid license once plans are on sale; until then the EULA permits it free of charge. The full terms are in the LICENSE file inside this package.

Product Compatible and additional computed target framework versions.
.NET net10.0 is compatible.  net10.0-android was computed.  net10.0-browser was computed.  net10.0-ios was computed.  net10.0-maccatalyst was computed.  net10.0-macos was computed.  net10.0-tvos was computed.  net10.0-windows was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

This package has no dependencies.

Version Downloads Last Updated
10.4.0 0 8/28/2026
10.3.1 61 8/27/2026
10.3.0 54 8/27/2026
10.2.2 124 8/23/2026
10.2.1 118 8/20/2026
10.2.0 111 8/20/2026
10.1.2-preview.19 60 8/19/2026
10.1.1 240 8/7/2026
10.1.0 137 8/5/2026
10.0.0 136 8/3/2026
9.1.0 161 7/28/2026
9.0.0 131 7/27/2026
8.4.0 129 7/24/2026
8.3.0 142 7/23/2026
8.2.0 170 7/17/2026
8.1.1 124 7/15/2026
8.1.0 19,022 7/13/2026
8.0.0 173 7/10/2026
8.0.0-preview.17 77 7/9/2026
7.4.0 220 7/1/2026
Loading failed

## [10.3.0] - 2026-08-27
Features:
- add the send_feedback tool (dd49736)
Bug Fixes:
- decide a preview's project edit from the evaluated compile items (5df5eb1)
- match a target against the specifications the project file names (5df5eb1)
- read the compile rules MSBuild settles, in the order it reads them (5df5eb1)
- send an unreadable compile rule back to the old reading (5df5eb1)
- stop the reading at the first rule it cannot read (5df5eb1)
- resolve a rooted item specification, and reuse the generated-file classifier (5df5eb1)
- give the classifier the full path, and match a plainly written item path (5df5eb1)
- compare paths the way the platform does, and read back MSBuild escapes (5df5eb1)
- decode an item specification before resolving its path (5df5eb1)
- leave an escaped wildcard to the older reading (5df5eb1)
- move the test projects to Microsoft.Testing.Platform (dd94827)
- run dotnet test where the MTP opt-in is discovered (dd94827)