glider 8.4.0

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

Full-workspace Text Search (Scout)

Glider's search_text tool works on its own over the loaded C# documents. To search every file under your solution root — the directory holding the loaded .sln/.csproj, so files above it stay out of scope — in any language, install Scout as a real scout binary on your PATH. Glider then delegates search_text to it automatically, and the response's data.backend reports scout (solution root, all languages) vs workspace (loaded C# documents).

Install Scout globally so it stays on PATH:

npm install -g @glidermcp/scout
# or, with no Node runtime:
curl -fsSL https://glidermcp.com/install.sh | sh
brew install glidermcp/tap/scout

An npx -y @glidermcp/scout MCP entry is not enough on its own — it runs Scout only for that moment and leaves no binary on PATH, so the delegation cannot find it. Point at an explicit binary with SCOUT_BINARY_PATH, or disable the delegation with --no-scout (or GLIDERMCP_NO_SCOUT=1).

server_status reports what was detected under data.scout — available, the resolved binaryPath, a reason when it is unavailable (not_installed, disabled_by_flag, disabled_by_env, or delegation_suspended when scout is installed but repeated failures stopped respawning it this session), and install commands when the binary is simply missing.

Configure Your MCP Client

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

• https://glidermcp.com/glider/installation
• https://glidermcp.com/glider/installation/codex
• https://glidermcp.com/glider/installation/claude-code
• https://glidermcp.com/glider/installation/copilot

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.

License

All Rights Reserved