Agent host recipes

Sidekit is an MCP server over stdio. Every host below speaks that protocol, so the wiring is three lines of JSON in each. The parts worth writing down are the one property that keeps the config free of absolute paths, and how to get the agent to actually use the server instead of shelling out to dotnet test.

This page assumes sidekit is installed and sidekit doctor is green. If it isn't, start at Install.

Why these configs carry no absolute paths

sidekit mcp binds to its launch directory when no -w is given, and all three hosts start a stdio server with the working directory set to the project root. So none of the recipes below need an absolute path, and each can be committed to a repository that several people clone to different places.

Pass -w <path> explicitly only when the workspace is not the launch directory — a solution in a subdirectory, or one host process serving a repository it is not rooted in.

Claude Code

Project scope, committed and shared with the team — .mcp.json at the repository root:

{
  "mcpServers": {
    "sidekit": {
      "command": "sidekit",
      "args": ["mcp"]
    }
  }
}

Claude Code asks each user to approve a project-scoped server the first time it sees it. The equivalent from the CLI, where -- separates Claude's own flags from the server command:

claude mcp add sidekit --scope project -- sidekit mcp
claude mcp get sidekit

Use --scope user for every project on the machine, or omit --scope for just this one.

Cursor

.cursor/mcp.json in the project, or ~/.cursor/mcp.json for every project:

{
  "mcpServers": {
    "sidekit": {
      "command": "sidekit",
      "args": ["mcp"]
    }
  }
}

VS Code — GitHub Copilot agent mode

{
  "servers": {
    "sidekit": {
      "type": "stdio",
      "command": "sidekit",
      "args": ["mcp"]
    }
  }
}

Copilot only calls MCP tools in agent mode. Select Sidekit's tools from the tool picker in the Chat view.

Tell the agent when to reach for it

Wiring the server up is not enough. An agent that already knows dotnet test will keep running dotnet test — and pay thousands of tokens for a wall of build output — unless its instructions say otherwise. Put something like this in CLAUDE.md, .cursorrules, or .github/copilot-instructions.md:

## Test intelligence

This repository runs a Sidekit MCP server. Prefer it over raw `dotnet` commands:

- **To find code**, `find_symbol` for a declaration and `find_usages` for everything
  that touches it, rather than grepping the repository.
- **Before editing**, `get_tests_for_file` or `get_blast_radius` to see what a file
  is guarded by and what it can break.
- **After editing**, `get_status` for build truth — it is warm and costs a few
  tokens, unlike a `dotnet build`.
- **To test a change**, `select_tests` for the affected projects, then `run_tests`
  on those. Do not run the whole suite by hand.
- **On failure**, `get_failures` for root-cause-clustered detail. Never re-run tests
  to see the output again.
- **If a failure looks non-deterministic**, `get_flaky_tests` before believing it.
- **If anything behaves oddly**, `doctor` — it names what is degraded and how to fix
  it, rather than leaving you to guess.

That list is the token economy the whole project exists for: get_status answers an unchanged workspace in tens of bytes, where dotnet build costs kilobytes to say the same thing. See Token economy.

Verifying the wiring

Ask the agent to run doctor through the server. A healthy report is every check Ok; anything else names the problem and the remedy. Two failures are worth knowing on sight.

sdk Fail — “No .NET SDK could be resolved”

The host launched the server with a PATH that has no dotnet. GUI-launched editors do not inherit a shell profile, so a dotnet installed by a version manager is often invisible to them.

workspace Fail — “No solution or project found”

The launch directory was not the project root. Add -w /path/to/repo to args.

Next

With the server answering, the MCP tools reference covers what each tool takes and returns.