The DidWork MCP server

An agent that reports on its own work has one source: its own execution. The MCP server gives it a second one. It forms a claim — this refund settled, this PR merged, this endpoint is up — and DidWork answers from the system that can actually prove it.

Published as @didwork/mcp and listed in the MCP registry as sh.didwork/didwork.

Install

npx -y @didwork/mcp

Stdio transport, no arguments. Every host below is a way of getting that command run with an API key in its environment.

The tools

Tool	What it does
`did_verify`	Send a claim, get a verdict with evidence
`did_get`	Fetch a verification by id — how you poll an `unknown`
`did_list`	Recent verifications for this key
`did_watch`	Re-verify a claim on an interval; hear when the verdict changes
`did_watches`	List running watches
`did_unwatch`	Stop one
`did_usage`	Verifications performed, by month
`did_inspect_tool`	Capability Trust: what a project's own agent tools can affect

Keys

The server looks for a key in three places, in order:

DIDWORK_API_KEY in the environment
the file named by DIDWORK_API_KEY_FILE
~/.didwork/api_key

The key file matters more than it sounds. An app launched from the Dock or Start menu never sees the environment variables your shell exports, so a key set in .zshrc is invisible to a desktop agent. The file works everywhere:

mkdir -p ~/.didwork
printf '%s\n' 'dk_your_key' > ~/.didwork/api_key
chmod 600 ~/.didwork/api_key

With no key at all the server still runs, and only http.ok claims verify — keyless, rate limited, and never stored.

Host configuration

For Cursor or Claude Code, one command writes the config and the rule for you, merging into whatever is already there:

npx @didwork/inspect init

The rest of this section is what it writes, for doing it by hand.

Claude Code

claude mcp add didwork -e DIDWORK_API_KEY=dk_your_key -- npx -y @didwork/mcp

Or install the plugin, which adds the rule and a Stop gate on top of the tools.

Cursor — .cursor/mcp.json, or the one-click link shown next to a new key in the console:

{
  "mcpServers": {
    "didwork": {
      "command": "npx",
      "args": ["-y", "@didwork/mcp"],
      "env": { "DIDWORK_API_KEY": "dk_your_key" }
    }
  }
}

Claude Desktop — the same object, in claude_desktop_config.json.

Anything else — any MCP host that can run a stdio server: command npx, args ["-y", "@didwork/mcp"].

The rule that matters

Tools alone change nothing; an agent with a verifier it never reaches for still grades its own work. Whatever the host calls its instructions file, this is the part that does the work:

Before reporting a task complete, verify each outcome you claim
with did_verify. Report done only on VERIFIED. Surface FAILED and
UNKNOWN instead of retrying silently.

The third sentence is the one that gets dropped and shouldn't be. UNKNOWN means the evidence could not be reached — which is not the same as the outcome being false, and nothing like it being true.

Claim types

Nearly forty types across Stripe, GitHub, GitLab, Linear, Jira, Sentry, Slack, email and any public URL. Provider-backed claims need that provider connected with read-only credentials at didwork.sh/console/providers; http.ok needs nothing. The full table with each type's exact semantics is in the docs.

Capability Trust

did_inspect_tool answers the question that comes before the work: what can this agent tool actually affect? It reads the MCP tool handlers in a TypeScript project and reports each tool's evidenced capabilities with file:line evidence, a risk level, a separate confidence level, and a DECLARATION_MISMATCH when the implementation exceeds what the tool declares.

Analysis is local and reads source only; nothing is uploaded and no key is needed. It is provided by @didwork/inspect, an optional peer — it carries the TypeScript compiler, so plain npx -y @didwork/mcp stays small. To enable it:

npx -y -p @didwork/mcp -p @didwork/inspect didwork-mcp

Needs @didwork/mcp 0.0.11 or later. Earlier versions declare the peer as ^0.0.1, which npm reads as >=0.0.1 <0.0.2 — so pairing them with a current @didwork/inspect fails outright with ERESOLVE rather than degrading. If you see that, upgrade the server.

Until then the tool answers in-band with that instruction rather than inferring anything. unknown means "not shown to be safe", never "low risk".

Troubleshooting

The tools do not appear. MCP servers load at host startup — restart it. Then check the host's MCP log for a spawn error; the usual cause is npx not being on the PATH that a GUI-launched app sees.

Every provider claim is unknown but http.ok works. That is the keyless signature: the server is running without a key. Use the key file above — especially for desktop apps, which never see your shell environment.

did_inspect_tool says it is not installed. Run the server with the -p @didwork/inspect form above.

Host-specific guides: Claude Code, Cursor. To gate merges on the same verdicts, DidWork for GitHub Actions.