# 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//mcp` | | header | `Authorization: Bearer ` | 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//v1/observe`, and `examples/curl/check-action.sh` is that request in full. ## 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 and marked every platform-side step **untested**, because we have not read any of their documentation — eleven of their documentation hosts were measured on 11 October 2026 and all eleven refused the request. | platform | status | |---|---| | Claude, and any MCP client | **[untested]** | | Clay | **[untested]** | | n8n | **[untested]** | | CrewAI | **[untested]** | | LangGraph | **[untested]** | | Dust | **[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.