@getsnare/mcp

Snare's MCP server. Point any MCP client at it to read and act on issues, events, traces and fix runs — or to run a Snare on your own machine, with your own model.

Install

You need a Snare token. Make one at getsnare.tech/settings/api-tokens.

Claude Code

claude mcp add snare --env SNARE_API_TOKEN=snr_... -- npx -y @getsnare/mcp

Cursor, Windsurf, Codex, opencode

Add this to the client's MCP config file:

{
  "mcpServers": {
    "snare": {
      "command": "npx",
      "args": ["-y", "@getsnare/mcp"],
      "env": { "SNARE_API_TOKEN": "snr_..." }
    }
  }
}

Over HTTP

For clients that take a URL instead of a command:

https://getsnare.tech/api/mcp

Send the token as Authorization: Bearer snr_....

What it can do

| Set | Tools | | --- | --- | | issues | List, search, read, comment, assign, change status and severity, merge, split, see who is in the workspace | | events | Occurrences with their stacks, traces, session recordings, affected users | | snares | Launch a fix run, watch it, answer its questions, steer it, stop it, read its diff, check what is left on the plan | | local | Run a Snare here, on your own agent | | feedback | Bug reports and feature requests from your users | | memory | Project rules, standing instructions, what Snare has learned | | workspace | Projects and how the workspace is doing | | setup | Install the SDK |

All of them are on by default. Narrow it with SNARE_MCP_TOOLSETS when you want a smaller catalogue:

SNARE_MCP_TOOLSETS=issues,events
SNARE_MCP_TOOLSETS=all

Every tool's description is text the model reads on every turn, so narrowing leaves more room for the problem you are working on. Turning a set off means the model cannot see it at all — it will say Snare cannot do that, rather than that you switched it off.

Permissions

A token carries scopes, and the server only registers tools that token can use. A read-only token sees read-only tools; the rest are not offered at all, so the model never picks one it will be refused for.

Two tools spend a Snare from your plan: launch_snare and start_local_snare. The token page marks both scopes.

Pick scopes when you make the token. Read only suits an agent that answers questions about production. Triage adds commenting, assigning and status changes without spending anything.

Running a Snare locally

start_local_snare runs Snare's fix loop against the repository you have open, using your own model.

Snare decides the stages, checks each answer against that stage's contract, scores the result and meters the run. Your agent does the reading and the editing. It is the same loop as a cloud run — the model and the machine are yours.

Your agent calls start_local_snare, then local_snare_step in a loop until the run reports done. Each instruction says what to do and what to send back.

Three things to know before you start one:

• It changes files in your working tree. Commit or stash first.
• It spends a Snare from your plan, the same as a cloud run.
• Snare cannot enforce its safety rules on your machine. In its own sandbox they block a command before it runs. Here they are instructions to your agent. Snare will not ask your agent to do something it would have blocked, but it cannot stop your agent doing it anyway.

Snare Lite and investigations do not run locally yet. Use launch_snare for those.

Configuration

| Variable | Default | | --- | --- | | SNARE_API_TOKEN | required | | SNARE_MCP_TOOLSETS | all | | SNARE_BASE_URL | https://getsnare.tech/api/v1 | | SNARE_DASHBOARD_URL | derived from SNARE_BASE_URL |

Each has a command-line equivalent (--token, --toolsets, --base-url, --dashboard-url) which takes precedence.

Licence

MIT