glider

Compiler-backed C#/.NET code intelligence for coding agents. Explore symbols and call graphs, inspect diagnostics, analyze complexity, dependencies, and impact, and safely edit and refactor solutions through MCP.

NuGet

Version: 10.0.0

Version published: last month

Total downloads: 135K

Maintainers: 1

Created: 9 months ago

Source

Glider - Semantic C# MCP Server

Glider is a semantic C#/.NET MCP server for code navigation, diagnostics, analysis, and refactoring.

Install

Prerequisite: .NET 10 SDK. Source builds in this repository use the SDK version pinned by ../../global.json.

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

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

--default-timeout supports ms, s, and m suffixes. Use 0 to disable 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 running so load can be retried. While it runs, server_status reports progress under workspaceLoading, including an ETA based on this workspace's previous load time. Relative paths resolve against the launch directory; prefer absolute paths in shared configs. --workspace sets the root directory for file watching/auto-sync. When omitted, Glider watches the enclosing git repository root of the loaded file (or its directory when outside a repository) — useful when the solution sits in a subfolder but related code lives in sibling folders of the same repository. In a large monorepo this wide watch root also means edits to unrelated files elsewhere in the repo can trigger a workspace refresh; pass --workspace with a narrower directory (or --no-watch) if that becomes noisy. If the watcher can't start for the chosen root (for example when the OS inotify limit is exhausted), the workspace still loads — auto-sync is simply disabled and the reason is reported in the load result's fileWatcher.error. --no-watch disables file watching/auto-sync for the startup load. It cannot be combined with --workspace.

Why you might need them:

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?"

Text Search Scope

search_text searches the documents the workspace has loaded, as the compiler last ingested them — the file watcher keeps that in step with disk, and sync/reload force it, so results track saved files rather than an editor’s unsaved buffer. data.coverage always reports loadedDocuments. That is not only C#: AdditionalDocuments and AnalyzerConfigDocuments a project declares are searched too. Files that no loaded project references are out of scope.

For repo-wide, all-language text search, add Scout as its own MCP server and call its find tool. It indexes the repository across all languages (honoring your ignore rules) and also reaches fuzzy, structural, and symbol-outline routes that Glider does not provide. Its strict modes aim to be exhaustive but stop early on a time or match budget, reporting exhaustive: false when they do. The two are separate servers; neither calls the other.

Configure Your MCP Client

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

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. For deeper operational guidance and tool-selection heuristics, use the repository docs.

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 already correct but the wrong MSBuild toolset is still being used, add --msbuild-path and point it at the desired Visual Studio or SDK MSBuild location.
On Windows, stable Visual Studio installs are preferred for legacy/.NET Framework solutions.