MCP server & connectors

damn.dev connects to the wider tool ecosystem in two directions: it can expose its agents over MCP, and it can ingest activity from outside workers.

The MCP server#

damn.dev ships a stdio-based MCP server that exposes an agent's identity, memory, and governance context to MCP clients like Claude Code, Codex, and Cursor. Point your MCP client at it and your editor's agent reads the same identity and memory your damn.dev agent has.

Each credential is minted in Settings → MCP, shown once, revocable, and records when it was last used. It scopes the session to a workspace rather than letting the client declare its own.

One credential per worker#

You can issue a credential to a worker in your Registry rather than to yourself. Then a read is recorded as that worker, with you accountable for it — which is the true fact, and a different one from you read workspace memory.

Three things follow, and they are the reason to bother:

• Revoke one tool without touching the others. One credential per worker means killing the Cursor key leaves Claude Code and Codex working.
• "Last used" names something. Three tools sharing one credential can't tell you which of them read anything.
• Credentials can be time-boxed, and retiring a worker revokes its credentials automatically — a key never outlives the identity it names.

Per-person credentials aren't going anywhere: a human at a terminal is not a worker, and that is still the right shape for your own use.

Choosing what a worker may read#

By default a worker's credential can read any agent in its workspace. Grant it specific agents and it becomes an allow-list: reading anything else is refused, with a message saying so rather than an empty result. That makes sentences like "Cursor on the contractor's laptop may read the Support agent and nothing else" something you can actually set.

Two behaviours worth knowing before you use it:

• Changes apply to sessions already running, not at the next restart. Narrow a worker's scope and its next read stops.
• Removing a worker's last grant returns it to reading everything, because "no grants" means "nobody has decided". Tightening access by removing grants one at a time loosens it on the final one — so remove the agents you don't want and keep at least one you do.

Grants are operator-managed, recorded in your audit log, and shown on the worker's row in the Registry.

Credentials that go quiet#

A credential unused for 60 days is revoked automatically and the revocation is recorded, so a forgotten key on a reimaged laptop doesn't stay live indefinitely. A credential you use stays put. If you want a firm end date instead, set an expiry when you issue the credential — or change it later; expiries can be extended, shortened, or removed.

On a machine where damn.dev is running, the desktop app can write a new credential straight into the tool's own config — no copy-paste of a secret. It backs the file up first and leaves your other settings alone, and disconnecting removes exactly what it added.

Two directions, two decisions — letting a tool read your workspace over MCP is not the same as connecting it so damn.dev can watch and gate what it does. Each is asked for separately, and you can have either without the other.

Ceiling — a worker credential makes a read attributable, scopeable and revocable. It does not make the key unstealable — anyone who can read the config file can copy it — and it does not observe what the editor then does with what it read. Read scope, time limits and per-worker blast radius are the mitigations, not secrecy.

Connectors — bringing outside workers in#

The other direction: outside AI workers report their activity into your Registry and audit log. From Oversight → Registry → Connect, you get the one-time setup for:

• Claude Code — a hook that reports tool use (and can enforce a best-effort gate).
• Hermes / MCP agents — an interposition proxy that gates MCP calls.
• OpenTelemetry / CLI tools — a standard OTLP endpoint, plus a damn-dev run <cmd> wrapper for CLI tools with no config hook.

A single one-command installer can wire several of these at once, using a universal connector token.

Note — What each connector enforces vs. merely observes is covered honestly in Governing AI you don't run — read that before relying on any of them for control rather than visibility.

A note on the internal API#

Most of the backend speaks tRPC and is internal plumbing — it can change between releases and is not a published, stable contract. The stable, meant-for-integration surface is the MCP server and the connector ingestion endpoints above. See the Integration & API reference.

Next#

• Integration & API reference — the stable endpoints in detail.
• Governing AI you don't run — the honesty labels per connector.