# Connect Reynforce to your agent platform

**If your agent can make an HTTP request, it can use Reynforce.** One endpoint,
one bearer token, and no change to how your agent is orchestrated — we never run
your agent.

## The two values

| | |
|---|---|
| endpoint | `https://app.reynforce.com/t/<your-workspace>/mcp` |
| header | `Authorization: Bearer <your agent key>` |

That is an MCP server over Streamable HTTP. A platform that cannot speak MCP
does not need to: the same check is one POST to `/t/<your-workspace>/v1/observe`,
and `examples/curl/check-action.sh` is that request in full.

**Behind an MCP gateway, it is one more server the gateway serves.** Keep the
gateway deciding which agents may reach which tools; Reynforce answers whether
what the agent is about to tell a buyer is your company's to say.
</reynforce-and-mcp-gateways.md> says how the two fit together.

## What an agent key can do, and what it cannot

| tool | |
|---|---|
| `search_claims` | read the register. A claim's status comes back with it, so the agent can tell a current claim from a stale one |
| `check_action` | ask whether an action is permitted |

**An agent key cannot add a claim.** `propose_claims`, `assign_owner`,
`accept_claim`, `confirm_claim` and `raise_contest` need `register:write`, which
only a signed-in person holds. An agent proposes and asks; a person accepts.

**`check_action` writes a record, and that is not optional.** The record is a
side effect of the permission check rather than something the agent sends, so a
caller can be wrong about its own action and still cannot be wrong about the
record. There is deliberately no way to ask without leaving a trace: an agent
that could would ask until the answer was yes. `intent: "draft"` is the honest
version — the check is recorded and the touch is not, because nothing was
touched.

## The six platforms, and which of them anyone has tested

**None of them. Not one.** We have written down what to paste for all six,
and nobody here has connected any of them to a real account yet.

**Five of them we have read.** Their documentation hosts refused us when this
page was first written: eleven were measured on 11 October 2026, and all eleven
refused the request. On 21 October 2026 we read Claude Code's documentation
and CrewAI's from a GitHub runner instead, on 24 October Dust's, and on 25
October the README of LangChain's MCP adapters, which is how LangGraph reaches
a server, and n8n's own source for its MCP Client Tool node. The steps in
`examples/clients/` for those five quote the vendors' own pages rather than
our memory of them. For Clay we still have not read whether it speaks MCP, so
its platform-side steps are marked **untested**.

| platform | status |
|---|---|
| Claude, and any MCP client | read for Claude Code, not run |
| Clay | **[untested]** |
| n8n | read, not run |
| CrewAI | read, not run |
| LangGraph | read, not run |
| Dust | read, not run |

A setup guide that looks right and has never met its client costs the same as an
API adapter that has never met its service, and the person who pays it is you,
following our instructions. So the notes in `examples/clients/` say which single
question is unanswered for each one, rather than filling it in plausibly.

**One page rather than six.** Six pages whose differing sixth is *we have not
read this* would be six thin pages. When a platform's steps are read and
written, its section is worth a page of its own and gets one.

## The three things to check once it is connected

1. **The tool list.** An agent key should see exactly `search_claims` and
   `check_action`. If it sees `propose_claims`, you have given it a person's key.
2. **`not_checked` in the answer.** `allowed` with that list non-empty means
   something was never evaluated, and *not evaluated* is not *passed*. Triggers
   and budgets can both be in it.
3. **A cited claim's status in the answer**, not the one you sent. The register
   replaces it, because usability is derived and a caller does not grade its own
   citations.

## What we store

The action's shape, the decision, and — where the action carried a promise — the
**sentence that promise was made in, up to 1,000 characters**. Not the rest of
the message. Data at rest sits on Fly's encrypted disks; the encryption is
theirs, not ours. Records are kept for 24 months, an unclosed commitment is
never deleted on age, and every deletion is itself recorded.