Three steps to connect an agent

Last updated 25 October 2026

Point your MCP client at your workspace's endpoint, send the key as a bearer token, and call check_action before the agent promises anything. Nothing to install, no change to how your agent is orchestrated, and the tool list you are shown is decided by what the key is rather than by anything you configure.

Step one — get a key

POST /request-access with your company's web address and the email of the person responsible for the agent. That person is emailed, and following the email is what makes them the owner — there is no link that grants ownership to whoever holds it, because a link like that can be pasted into a chat or a log and whoever read it next would own your company's register.

An owner issues the key on their own workspace's keys screen. It is shown once, and revoking it is on the same page.

Step two — point your client at the endpoint

endpoint — https://app.reynforce.com/t/<your workspace>/mcp
header — Authorization: Bearer <your key>

That is the whole connection. Every MCP client already sends a bearer token, so there is nothing here your client does not do.

Step three — read a claim's state, then ask before you promise

Your key holds register:read and check, and the tool list you get back is decided by that rather than by anything you configure:

search_claims — the claims your company stands behind, each with its owner, the date it was last checked, and its state
check_action — may I say this — you describe the action, and what comes back is a decision, the register's own reading of every claim you cited, and a list of what the check did not evaluate

A signed-in person is additionally shown propose_claims, assign_owner, accept_claim, confirm_claim, raise_contest, start_agent_draft, update_agent_draft, agent_draft, finish_link, setup_instructions — every one of them changes what the company stands behind, and only a person can do that. An agent key cannot hold the scope they need, so there is nothing to switch on.

Read the state before citing a claim. One that is overdue, unowned or disputed is unusable, and repeating it anyway is the failure this exists to prevent — so escalate and tell the buyer rather than answering around it.

The record is a side effect of the check, not something you send. There is no tool that files a commitment, so you can be wrong about your own action and still cannot be wrong about the record. There is deliberately no way to ask without leaving a trace: an agent that can ask would this be allowed with nothing written down can ask until the answer is yes.

Every answer carries observation_only: true today. It records; it does not block. That travels in the answer rather than on this page, so an agent honouring it now keeps working unchanged the day it becomes false.

Before you have a key

There is a register you can read without one, belonging to an invented company — see /demo.html, and /docs.html for the longer account of the connection, the two tools and what an answer carries.

If you are not speaking MCP

/openapi.json is the HTTP door's description, generated from the schema a request is validated against. No host answers that door today: a deployment serves the register screen and /mcp, and the document says so rather than naming a host that would answer nothing.