Glider

Claude Code Setup

Configure GliderTrace with Claude Code CLI.

Claude Code

Prerequisite: .NET 10 SDK must be installed before running dotnet tool install --global glider-trace.
dotnet tool install --global glider-trace
Most MCP clients can run glider-trace directly if your .NET tools directory is on PATH.
# bash/zsh
export PATH="$PATH:$HOME/.dotnet/tools"
which glider-trace
Use stdio for local GliderTrace setup. Project-scoped servers only run when you are in that project. See Claude Code MCP docs: code.claude.com/docs/en/mcp.
claude mcp add --transport stdio glider-trace --scope project -- glider-trace --workspace .
Global config runs in every Claude Code project. Use this only if you want GliderTrace available everywhere.
claude mcp add --transport stdio glider-trace --scope user -- glider-trace
The GliderTrace plugin is published from glidermcp/glidermcp.com and bundles the product skill plus stdio MCP config.
/plugin marketplace add glidermcp/glidermcp.com
/plugin install glider-trace@glidermcp
If you prefer Streamable HTTP, start GliderTrace yourself and point Claude Code at http://localhost:5003/mcp. Port 5003 avoids colliding with another local MCP server that uses 5001.
# Terminal 1
glider-trace --transport http --port 5003

# Terminal 2
claude mcp add --transport http --scope project glider-trace http://localhost:5003/mcp
Start a new Claude Code session and check for GliderTrace tools. If you need startup output, re-add GliderTrace with --verbose.
claude
# Then ask: "What GliderTrace tools are available?"
Use a project-local config: Claude Code .mcp.json, Codex .codex/config.toml (trusted projects), Cursor .cursor/mcp.json, or VS Code .vscode/mcp.json. Include portable config files in version control, or copy local config files into each worktree. Git does not copy ignored files. Use absolute paths only when you intentionally want one fixed checkout, such as a global Claude Desktop configuration.

Open the client at the selected worktree root. Relative server arguments use the server launch directory, not the config file directory. Project scope alone does not guarantee that directory. If the client starts elsewhere, configure its MCP working directory or use a Git-root launcher.

Run git rev-parse --show-toplevel in the client terminal, then ask trace_status for the server workspace. Confirm that the loaded solution or workspace belongs to that worktree before you query or change code. For a wrong root, restart GliderTrace with --workspace set to the intended worktree.

An existing HTTP server keeps its own workspace when the client changes directories. Use separate servers and ports for simultaneous worktrees.
git rev-parse --show-toplevel
Use this alternative when the client starts inside the worktree but below its root. It requires Git and a POSIX shell. Replace the existing server entry; do not add a second instance. For Glider, replace src/App.slnx with your solution path. On Windows, use the relative configuration above and set the MCP launch directory to the worktree root. This launcher cannot identify your worktree if the client starts outside its directory tree.
{
  "mcpServers": {
    "glider-trace": {
      "command": "sh",
      "args": [
        "-c",
        "repo_root=$(git rev-parse --show-toplevel) && exec glider-trace --workspace \"$repo_root\""
      ]
    }
  }
}
After connecting GliderTrace, add this product-specific instruction to your MCP client system prompt or project instructions so the agent chooses the right tool surface first.
When you need runtime evidence for .NET code, prefer glider-trace mcp before ad hoc shell runs. Use GliderTrace for test runs, workspace command runs, failure summaries, exception and stack evidence, stdout/stderr summaries, counters, traces, dumps, GC dumps, and artifact indexing. Use plain CLI commands only for simple file operations or commands where no captured evidence or session history is needed.
↑/↓ NavigateEnter OpenSpace Expand