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

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

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.

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.