BRYDGE

brydge-mcp

Check whether your agent's work actually happened.

This is BRYDGE as an MCP server. Before an agent acts, BRYDGE decides whether it may. Afterwards, BRYDGE reads the destination system's own records, such as your payment processor or ticket system, using its own credential. It then reports whether the work happened as permitted. What the agent says happened is kept beside that finding and never decides it.

Tools

The server also gives the model its instructions: ask first, cite the authorization, report, then verify before saying the work is done.

Set up BRYDGE first

Do these once, in BRYDGE:

1. Issue an API key on the Connect page.
2. Declare what the action is worth. BRYDGE charges a share of that value, and it will not check an action nobody has priced.
3. Register a destination for the action: where BRYDGE reads the records, and the read-only credential it uses. BRYDGE has a preset for Stripe refunds.
4. Issue a mandate to the agent for the action, on the agent's page in BRYDGE. Without one, every call goes to a person, and the agent acts only once they allow it (see When a person decides).

A mandate says what the agent may do; headroom says how much of it, in any 24 hours. A new agent starts with room for one action a day, and every report BRYDGE checks and finds true raises that.

Add it to your MCP client

Most clients take this configuration (Claude Desktop, Cursor, Windsurf and others):

{

"mcpServers": { "brydge": { "command": "npx", "args": ["-y", "brydge-mcp"], "env": { "BRYDGE_API_KEY": "brydge_sk_...", "BRYDGE_ACTOR": "agent:refund-ops" } } } }

On Windows, npx is a .cmd file, and only clients that start commands through a shell or through the MCP SDK can launch it by name. If your client reports spawn npx ENOENT, start it through the command shell instead:

{

"mcpServers": { "brydge": { "command": "cmd", "args": ["/c", "npx", "-y", "brydge-mcp"], "env": { "BRYDGE_API_KEY": "brydge_sk_...", "BRYDGE_ACTOR": "agent:refund-ops" } } } }

In Claude Code:

claude mcp add brydge -e BRYDGE_API_KEY=brydge_sk_... -e BRYDGE_ACTOR=agent:refund-ops -- npx -y brydge-mcp

The agent's name comes from this configuration, never from the model, so an agent cannot borrow another agent's permissions. Run one server per agent.

How an agent uses it

1. Ask first. Before a refund, payment or other change, the agent calls brydge_supervise with the action, the target and the facts, such as {"amount": 4200}.
2. Cite the authorization. If the answer is ALLOWED, the agent carries the action out and writes the authorization id where the destination keeps it. For a Stripe refund, that is metadata.brydge_authorization. BRYDGE finds the work by this id, and by nothing else.
3. Report. The agent calls brydge_report_outcome with what it believes happened.
4. Verify. Before saying the work is done, the agent calls brydge_verify.

brydge_supervise takes an idempotency_key, a name for one intended action such as refund:ch_123. Asking again with the same key and the same details is the same request: a retry gets the same answer, and once a person has answered an escalated one, it gets their answer. A key reused for a different action never gets another action's answer, because the server also hashes in what is being asked.

When a person decides

An escalated action waits for a person, in BRYDGE. The server does not wait with it: the model is told not to act, and to ask again once they have answered:

ESCALATED. Do not carry this out: a person decides. No mandate lets agent:refund-ops refund yet, so a person decides. A person has been asked. Ask again with the same idempotency key once they have answered: if they allow it, the answer is ALLOWED. Authorization: cmurkt5mw000i7dev66vu5afm.

When the model calls brydge_supervise again with the same idempotency_key, action, target and facts, BRYDGE answers with the person's decision:

A request with different details is a different action, so allowing a £42 refund never lets the agent refund £420.

Each authorization is for one action. A retry of an action already carried out gets the same ALLOWED back, and the model is told that if it already carried the action out, it must not do it again. If an action does run twice under one authorization, a check reports MISMATCH with DUPLICATE_EXECUTION.

What a check can find

brydge_verify reads the records when it is called. A check that finds something new is billed; asking again when nothing has changed is free. BRYDGE also checks every action by itself once the destination's reporting window has passed (60 minutes unless you set another), and brydge_get_finding reads that for free.

Protocol

The server speaks MCP over stdio. It serves clients on the 2026-07-28 revision and on the 2025 revisions from the same process, built on the official TypeScript SDK. When BRYDGE cannot be asked (a bad key, an action with no declared value, a rate limit, or BRYDGE being unreachable), the tool returns an error the model can read, and nothing is carried out.

Limits

• BRYDGE treats a target as one piece of work. A second record for the same target that carries a different authorization, such as a second partial refund of one charge, is reported as a MISMATCH.
• The server does not wait for a person. An escalated action ends with the model being told a person decides, and their answer reaches the agent only when the model asks again with the same idempotency_key and the same details. A request under a new key is decided afresh.
• The server does not see the action itself, so it cannot stop a second one. Whether an action was already carried out is for the model to remember; the server tells it when BRYDGE has answered the same request before.

Development

npm install

npm test # a real MCP client against the server in both protocol eras, and the built command over stdio npm run test:int # against a running BRYDGE; see tests/integration npm run build

License

MIT