Glider is a family of local MCP servers that give coding agents facts about your code instead of guesses. Scout searches any repository from a resident index. Glider provides compiler-backed navigation, diagnostics, and refactoring for C#/.NET. TGlider does the same for TypeScript and JavaScript. GliderTrace runs .NET commands and tests and keeps the runtime evidence queryable.
Every product runs on your machine and connects to any MCP client that can launch stdio servers. The home page has the full picture and each product’s install command.
The products ship under the GliderMCP EULA, included with every package. It grants a free license with full functionality, no license key, and no time limit for individuals. That license covers personal use, work on open-source projects, education, and non-commercial research. It also covers evaluation, including up to 30 days inside an organization.
Commercial use will require a paid license once paid plans are on sale. Until then — the early-availability period — commercial use is permitted free of charge under the same agreement. See Pricing for the current state.
Each released version has a limited validity window: it expires one month after its release date and does not start after that. The window exists so old releases with known defects retire; it does not limit the license grant, and updates are free for free-license use.
Update the package your MCP client launches, then restart the client. For the .NET tools run dotnet tool update --global glider (or glider-trace). For the npm packages run npm install -g tglider or npm install -g @glidermcp/scout@latest. If you installed Scout with the install script or Homebrew, those npm commands do not update that binary. Rerun the install script, or run brew upgrade glidermcp/tap/scout. On the npx launch paths, pin @latest, for example npx -y tglider@latest. Plain npx can reuse a cached, expired version.
Grep finds matching text, line by line, every time. Scout keeps a resident index of your working tree, so it skips the directory walk and the ignore rules on every search. Its literal, word, and regex modes still read file content from disk. The index also reaches searches grep cannot do: ranked fuzzy matches, semantic and hybrid search, and ast-grep structural patterns.
Glider and TGlider go further: they find code relationships that no text search can compute. That includes real definitions, references, implementations, overrides, callers, diagnostics, and change impact.
Glider’s search_text searches the documents the workspace has loaded, as the compiler last ingested them — the file watcher keeps that in step with disk, so results track saved files, not an editor’s unsaved buffer. data.coverage always reports loadedDocuments. That is not only C#: additional files and analyzer config a project declares (an .editorconfig, for instance) are loaded documents too. What is out of scope is any file no loaded project references.
For those, add Scout as its own MCP server and use its find tool: it indexes the repository across all languages, honoring your ignore rules. Its strict match modes aim to be exhaustive over the indexed files, but a scan that exceeds its time or match budget stops early and says so — check exhaustive and meta.partial before reading a zero-hit result as proof of absence. It also reaches fuzzy, structural, and symbol-outline searches that Glider does not provide. The two are separate servers and neither calls the other — use Glider’s semantic tools for C# symbols, references and refactors, and Scout for text and for everything Glider does not load.
TGlider has no text-search tool at all, so the same advice applies to TypeScript and JavaScript: add Scout as its own MCP server.
The LLM does not automatically know your local codebase. Without tools, it guesses from opened files and search results. The Glider products give it structured facts about the loaded workspace.
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.
The servers send anonymous usage data: a random install id, product and version, OS and architecture, and runtime version. They also send tool names with a duration bucket and outcome, and error categories as type names only. Glider adds coarse workspace shape counts; TGlider and GliderTrace send no workspace event at all. The data 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.
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. Client and transport details differ by product — see the Compatibility pages for Glider, Scout, TGlider, and GliderTrace.
Most MCP clients support a project-scoped config file that only starts Glider inside that repository. Claude Code uses .mcp.json at the repo root — run claude mcp add --transport stdio glider --scope project -- glider --default-timeout 30m. Cursor uses .cursor/mcp.json, VS Code and GitHub Copilot use .vscode/mcp.json, Gemini CLI uses .gemini/settings.json, OpenCode uses opencode.json, and Pi uses .mcp.json.
Claude Desktop is the exception: it reads one global claude_desktop_config.json and has no per-project scope. To tie it to a specific project, add --solution (a path to your .sln, .slnx, or .csproj) to that server’s args, or add one named entry per solution. For genuine per-project configuration, use a client such as Claude Code that supports project scope. TGlider follows the same pattern with --workspace.
Yes, when local .NET/MSBuild tools can load the project or solution. Use Windows with Visual Studio/MSBuild for solutions that depend on Windows-only .NET Framework targets. See Compatibility for the full matrix.
Yes, for supported refactoring and file-write workflows. Prefer preview-first changes where available, especially when editing shared code. Scout is the exception: it never modifies your source files. It does write its own index under .glider/scout, and it adds .glider/ to the repository’s local Git exclude file.
Glider and GliderTrace need the .NET 10 SDK installed locally; both are NuGet global tools. TGlider needs Node.js 24+. Scout needs Node.js 18+ for the npx path, or no runtime at all via the install script or Homebrew. All of them need an MCP-compatible client.
For the .NET tools, run dotnet --version before installing. If dotnet tool install succeeds but glider is not found, confirm that your .NET tools directory is on PATH.
Yes, for everything except Scout. Run glider --transport http --default-timeout 30m to start a Streamable HTTP MCP server at http://localhost:5001/mcp. TGlider defaults to port 5002 and GliderTrace to 5003, each serving /mcp. Scout is stdio-only in this release.
The products work with any MCP-compatible model and client that can call their tools.
Tool selection varies by model, client, system prompt, and task. The site does not publish a reproducible model comparison.
Add an explicit project instruction that defines when the agent should use Glider, Scout, TGlider, GliderTrace, or a CLI command.
By default Glider starts empty and waits for the agent to call the load tool. Some agents check server_status first, see solutionLoaded: false (“No solution loaded. Use load first.”), and stop instead of loading.
Preload the workspace at startup so server_status shows it loaded — or, on a large workspace, still loading in the background under workspaceLoading (Glider also reports an ETA there) — from the first message. For Glider, add --solution <path-to-.sln/.slnx/.csproj> to the launch args; for TGlider, add --workspace <repo-dir>. The agent can then wait for that load to finish instead of doing a separate load round-trip or refusing because nothing is loaded yet.
Use an absolute path (kept in local or user scope, since it is machine-specific), or a relative path resolved against the launch directory in a shared project config. You can still call load later to switch workspaces.
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"]
}
}
}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).
Glider rejects a call that carries an argument name the tool does not declare, instead of ignoring it. The error names the unrecognized argument, suggests the parameter you probably meant, and lists everything the tool accepts, marking which are required.
This is deliberate. A dropped argument is the worst failure an agent can get: search_symbols called with maxResults — which is not a parameter — used to return a large unbounded result computed from take's default, looking like success. A loud error costs one round trip; a confident wrong answer costs the whole session.
Most tools that return a list page with skip and take. A tool that returns more than one set pages each set with its own prefixed pair: get_type_hierarchy takes derivedSkip and derivedTake, analyze_change_impact takes callersSkip, callersTake, implementationsSkip, and implementationsTake, and find_package_usages takes symbolsSkip, symbolsTake, filesSkip, and filesTake.
If you are unsure of a name, tools/list is the authority. Glider generates the error message from that same schema, so the two cannot disagree.
The rule applies to operations nested inside batch exactly as it does to a direct call, and a tool that takes no arguments still rejects one.