Glider setup options

Workspace and worktrees

We recommend the project configuration in the installation guide. It selects a workspace and preloads its solution or project with --solution.

For a large solution, select a relevant .csproj first. Use load to select another solution or project later.

Check server_status while the workspace loads. Wait for readiness before you request semantic results.

A project load can include referenced projects outside its file access root. Load the containing solution to inspect those files. The watched directory does not expand file access.

Project scope determines which client loads a configuration. The path arguments determine which files the server can access.

The default absolute paths select one fixed checkout. Update those paths in each worktree; avoid committing machine-specific paths.

For portable relative paths, set the server launch directory to the worktree root. Relative paths resolve from that directory, not the configuration file.

Git does not copy ignored configuration files into new worktrees. Copy local files when needed, and use one server process per active worktree.

Compare git rev-parse --show-toplevel with server_status before you query or change code. Correct a mismatched path and reconnect.

Several agents and server resources

For several agents in the same workspace, start one Glider HTTP server and connect each client to its endpoint.

This avoids duplicate compiler state and file watchers. Each stdio client can otherwise start its own server process.

All clients share the loaded solution and workspace state. Assign one coordinator for workspace changes and code edits.

Share a server only between agents with the same workspace and permissions. Use separate instances for different worktrees. Give HTTP instances separate ports.

HTTP transport does not guarantee safe concurrent edits. Coordinate changes that affect another agent’s results.

Choose one connection configuration per product. Remove duplicate manual and plugin entries, including stdio entries alongside an HTTP connection.

Duplicate servers consume memory and file descriptors. If your client reports too many open files, check its server registrations and active instances.

Agent instructions

Add this instruction to your project instructions after the connection works. Use CLAUDE.md for Claude Code or AGENTS.md for Codex.

For another client, use its documented project instruction file.

Install the product skill described in the skills and plugins section below. It guides workspace checks, tool selection, and result interpretation.

Use Glider for compiler-backed C#/.NET navigation, diagnostics, dependencies, impact analysis, edits, and refactors. Use find_code when the symbol or location is unknown. Read a known source range directly. Apply authorized, unambiguous edits directly when the scope is clear. Preview inspection-only requests, unclear scope, or broad refactors that need inspection. Before semantic work, call server_status and confirm the loaded solution or project belongs to the current repository or worktree. Changing directories does not retarget Glider. Call load with the intended .sln, .slnx, or .csproj if the loaded workspace differs.

Claude Code specialists

For substantial C# tasks, use the specialists supplied by the Glider and GliderTrace plugins. Their role instructions give each task explicit tool guidance.

The C# specialist uses Glider for semantic work. The runtime verifier uses GliderTrace for tests and runtime evidence.

Assign one owner for source edits. Let the verifier check a stable change, and coordinate shared workspace and process changes.

These agents inherit available tools and client permissions. Their instructions guide tool choice; they do not isolate the server.

For a small task, use the product skill in the main conversation. A separate team is optional.

For manual MCP connections, the standalone skill guide below also explains how to install these agent definitions.

Use glidermcp:csharp-specialist to implement this C# change and check affected compiler diagnostics.

Updates and expired packages

The recommended connection checks NuGet for the latest stable package at each server start. It downloads a new version when needed.

Each server keeps its version until it restarts. Other active agents can continue with their current version.

The launcher caches package files. The --no-http-cache option requests fresh feed metadata on each start; network access is required.

The explicit @* selects the latest stable package and bypasses a local tool manifest pin.

Check dotnet --version from the server launch directory. A project global.json can select an SDK older than .NET 10 without tool exec.

Select the .NET 10 SDK for the launcher, or use the global-install alternative below. Keep the project SDK requirements.

For a fixed version, replace glider@* with glider@<version> in the client arguments. Omit the angle brackets.

For offline use, install a fixed version globally and configure the client to launch that executable directly.

To migrate a manual entry, set command to dotnet and replace args with the configuration from the installation guide.

Keep your existing server flags after the -- separator, including workspace, solution, transport, port, and timeout options.

Edit the existing registration and restart it. Avoid duplicate plugin and manual connections.

Existing global installations can remain. The automatic launcher uses its own package cache.

Packages expire after release. Update before expiry. Package expiry is separate from the license.

Glider 13.2.0 and GliderTrace 1.4.0 accept a valid production paid-period grant after package expiry.

Check the latest stable version

dotnet tool exec "glider@*" --no-http-cache --verbosity quiet -- --version

Optional global installation

Set the client command to glider. Remove the launcher arguments from tool through the -- separator. Keep the server arguments that follow it.

dotnet tool install --global glider
glider --version

Update a global installation

Stop servers that use this global installation before you update it. Restart them afterward.

dotnet tool update --global glider
glider --version

If the connection fails

Executable not found: run dotnet tool exec "glider@*" --no-http-cache --verbosity quiet -- --version in your terminal. Restart the client after installation so it receives the updated PATH.

Check that dotnet is on PATH. If necessary, use its full path in your client configuration.

If a plugin uses npx, complete its package download with the same user and npm cache as the client. Reconnect afterward.

A cached npx package can still require a registry check. A tool timeout does not extend the initial connection timeout.

Connection refused or server missing: check the client configuration location, JSON or TOML syntax, project trust, and server logs.

Timeout: wait for initial workspace preparation. Increase the client startup or tool timeout only if its documentation supports that setting.

Wrong workspace or failed load: check server_status, correct the path in the connection entry, and restart the server.

If a server with this name already exists, edit its entry. Do not append another entry with the same name.

Activate a paid developer seat

Commercial use after the 30-day evaluation needs a subscription. One developer seat covers Glider and GliderTrace. Use Glider 13.2.0 or GliderTrace 1.4.0 or later.

First, buy a plan on the Pricing page. A personal plan assigns its seat to you automatically. On a team, an administrator invites you and assigns a seat after you accept.

Run auth login below. Approve this device in the browser. Then run license status to confirm the commercial license.

One sign-in licenses both Glider and GliderTrace on this computer. The license works offline through your paid period. After it ends, the server renews it at startup. If a server reports that renewal failed, run license refresh.

On macOS, Keychain lets only the product you signed in with renew the license or sign out. To let both products do this, sign in with auth login --credential-store file. It stores the sign-in in a private file instead of Keychain.

Run auth logout to release this device. With a global installation, run glider auth login and the other commands directly.

dotnet tool exec "glider@*" --no-http-cache --verbosity quiet -- auth login
dotnet tool exec "glider@*" --no-http-cache --verbosity quiet -- license status
dotnet tool exec "glider@*" --no-http-cache --verbosity quiet -- license refresh
dotnet tool exec "glider@*" --no-http-cache --verbosity quiet -- auth logout

HTTP and shared servers

Use HTTP for a separately managed server. TGlider HTTP accepts one initialized client session. See the multi-agent section for sharing limits. Start it in your project directory and keep the terminal open. For Glider, replace src/App.slnx with your solution or project path.

dotnet tool exec "glider@*" --no-http-cache --verbosity quiet -- --transport http --port 5001 --solution ./src/App.slnx --workspace . --default-timeout 30m

The server keeps its own workspace when a client changes directories. Use separate ports for simultaneous workspaces.

Keep this connection on localhost. Remote access requires separate authentication and network controls.

Replace the local server entry with this HTTP entry. Remove any plugin stdio entry for this product. Keep other client settings and servers.

.mcp.json

{
  "mcpServers": {
    "glider": {
      "type": "http",
      "url": "http://localhost:5001/mcp"
    }
  }
}

Product skills and plugins

Install the skill for each product you use. Claude Code and Codex plugins bundle the skill with a stdio connection. TGlider and Scout use npx and need Node.js/npm.

Already connected? Keep your manual entry and install only the skill. This preserves project preload and custom server arguments.

Glider and GliderTrace plugins require the .NET 10 SDK and NuGet access. They check for the latest stable package at each start.

For a new plugin connection, remove or disable an existing manual entry for that product. Start a new client session afterward. Portable plugins use their default workspace behavior. Use the installation guide for explicit paths.

In Claude Code:

/plugin marketplace add glidermcp/glidermcp
/plugin install glidermcp@glidermcp

In Codex, add the marketplace, then choose the product in the Plugin Directory or /plugins browser.

codex plugin marketplace add glidermcp/glidermcp