home/docs

Documentation

Sidekit is a local daemon that keeps live, structured knowledge of a .NET solution's build and test state and exposes it to coding agents over MCP. It answers what an agent actually needs — what builds, what to run, what failed — as compact JSON rather than console output.

No license key, no sign-up, no activation. Sidekit is licensed under PolyForm Shield 1.0.0 and never prompts for anything. Install it and it works.

Quickstart

Three steps. Each links to its full reference.

1. Install the tool

One command. It checks for the .NET 10 SDK before changing anything, and re-running it later is how you upgrade.

macOS · Linux
curl -fsSL https://sidekit.net/install.sh | sh
Windows · PowerShell
iwr -useb https://sidekit.net/install.ps1 | iex
Pre-release: no version has been published yet. These are the real commands and will not change, but until the first release is tagged the installer has nothing to resolve. Full install notes, including how to do it by hand.

Then sidekit doctor in a .NET repository — it probes your environment and names anything that would degrade. Detail is in Install.

2. Wire it into your agent

Sidekit speaks MCP over stdio and binds to its launch directory, so the config needs no absolute paths and can be committed to the repository.

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

Cursor and GitHub Copilot use the same shape with one key renamed. See Agent host recipes.

3. Tell the agent to use it

This step is the one people skip, and skipping it wastes the other two. An agent that already knows dotnet test will keep running dotnet test unless its instructions say otherwise. The recipes page carries a ready-made block for CLAUDE.md, .cursorrules or .github/copilot-instructions.md.

What one change looks like

The reference pages cover each tool on its own. This is the shape of a whole edit — four calls, none of them large, and no console output anywhere in the loop.

Your agent edits src/Core/Calc.cs, then asks whether it still builds.

get_status
{ "generation": 12, "ready": true, "state": "BuildPassed",
  "capabilities": { "runner": "mtp", "coverageResolution": "file" } }

Green. So which tests are worth running for what it just changed?

select_tests
{ "resolution": "project",
  "testProjects": [ "tests/Core.Tests/Core.Tests.csproj" ],
  "changed": 1 }

One project, not the whole suite — and resolution says how that was decided, so the agent knows this is a safe superset rather than an exact answer.

Run it.

run_tests
{ "ran": true, "total": 24, "passed": 23, "failed": 1, "skipped": 0,
  "durationMs": 1840,
  "failures": [ { "test": "Core.Tests.Adds_Negatives",
                 "message": "Expected -1 but found 1" } ],
  "capabilities": { "runner": "mtp" } }

One failure, with the first line of why. If it needs the stack, it asks for it — and does not re-run anything to get it.

get_failures — includeStacks: true
{ "hasRun": true, "failed": 1,
  "failures": [ { "test": "Core.Tests.Adds_Negatives",
                 "message": "Expected -1 but found 1",
                 "stack": "at Core.Calc.Add(Int32, Int32) in src/Core/Calc.cs:line 14" } ] }
That is the entire loop. Four answers, each a few hundred bytes at most, and the agent knows the build is green, which tests mattered, which one broke and where. The equivalent in raw dotnet output is thousands of tokens, most of it restore and build chatter. How the answers stay small.

What it answers

QuestionTool
Does it compile, and what broke?get_status
Which tests should I run for this change?select_tests
Run them, and tell me the outcome.run_tests
What failed, and why?get_failures
Which tests cover this file or line?get_tests_for_file
What could this change break?get_blast_radius
Is this failure real, or flaky?get_flaky_tests
Where is this symbol declared?find_symbol
Who uses this symbol?find_usages
Why is something behaving oddly?doctor

Reference