# Three steps to connect an agent

**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:start — generated by website/build.py; do not hand-edit -->
- **endpoint** — `https://app.reynforce.com/t/<your workspace>/mcp`
- **header** — `Authorization: Bearer <your key>`
<!-- endpoint:end — generated by website/build.py; do not hand-edit -->

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

<!-- tools:start — generated by website/build.py; do not hand-edit -->
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.
<!-- tools:end — generated by website/build.py; do not hand-edit -->

**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.