MCP
Your agent hires a human without leaving its loop.
Model Context Protocol server, twenty-one tools, one API key. The agent decides it needs something checked in the physical world, calls a tool, and carries on — with nobody at a keyboard.
Install
Two minutes, one key.
The server is a stdio MCP process. Point any MCP-capable client at it and give it your key.
Claude Code and Claude Desktop
This is the path we run ourselves — the autonomous demo drives this exact binary.
{
"mcpServers": {
"irl-tagteam": {
"command": "npx",
"args": ["-y", "@irl/mcp-server"],
"env": {
"IRL_TAGTEAM_API_KEY": "irltag_live_…"
}
}
}
}Everything else
MCP is a standard, and any client implementing it can drive this server with the same command and environment variable. LangChain, CrewAI and the Microsoft Agent Framework all have MCP adapters — but we have not tested those integrations ourselves, so we are not going to print instructions implying we have. If you get one working, tell us and we will document it properly.
command: npx -y @irl/mcp-server
env: IRL_TAGTEAM_API_KEY=irltag_live_…
IRL_TAGTEAM_API_URL=https://tagteam-api.successagenticlabs.com # optionalTools
Twenty-one, grouped by what an agent wants.
Before you spend
Deliberately first. An agent reading this list top to bottom meets "what can you do" and "what would this cost" before it meets "spend money", which is the order it should think in. None of them creates anything or charges anything.
find_capability | Describe the work in your own words and find out which Recipe does it. Returns nothing rather than a closest guess, and flags a genuine tie instead of breaking it. |
estimate_tag | What a Tag would cost and how long it would plausibly take. The price is exact; the timing is history, or null when there is none. |
check_capabilities | Every supported operation, what proof it requires, what a Partner will refuse to do — and whether a given place can be served at all. |
Asking for work
Two ways to throw a Tag. The Recipe form is shorter and is the one to reach for first.
throw_recipe_tag | Throw a Tag from a standard Recipe and a location. The shortest correct request. |
throw_tag | Throw a Tag, stating the work, proof requirements and window yourself. |
list_recipes | Every standard job available, with what each one requires as proof. |
describe_recipe | One Recipe in full, including the checklist a Partner will be held to. |
Following it
Where a Tag is, and what came back. `tag_result` is the one your agent consumes.
tag_status | Where the Tag is in its lifecycle right now. |
tag_result | The structured answer — outcome, checklist, per-lock verification, evidence hashes. |
rule_on_proof | Approve or reject submitted proof. |
raise_dispute | Freeze the money pending human review. |
Checking supply
Narrower questions than check_capabilities: how much supply exists at a point, and whether this platform can deliver there.
find_partners | How much verified supply exists near a point. Counts, never identities. |
check_coverage | Whether this platform can actually deliver at a location. |
At scale
Many locations, or the same location repeatedly. Every location stays independently auditable.
create_campaign | One Recipe across many locations, each funded and verified on its own. |
campaign_status | Progress and spend across a campaign. |
create_schedule | Recurring Tags with a hard budget and a single next run. |
pause_schedule | Stop a schedule from firing again. |
Knowing your own authority
What this agent is, what it may spend, and whether a mission would be allowed. Reporting and dry runs only — nothing here can change a ceiling, because the MCP server is untrusted client code.
agent_identity | Who this agent is, its ceilings, its permissions, what it has spent, and its record. A null trust score means too few missions to say — never "untrustworthy". |
evaluate_mission | Would this be allowed? Runs the same code that gates the money, in dry-run mode. Approved, blocked, or held for a person, with every check and the reason. |
Knowing the rules
What this Corner is allowed to do. Reporting only — these tools cannot change a ceiling.
spending_limits | Every ceiling this Corner is subject to, and whether creation is paused. |
account_status | Plan, quota and current standing. |
In practice
What the agent actually says.
The agent does not need to understand capture sessions, geofences or the ledger. It names a standard job and a place.
throw_recipe_tag({
recipe: "PROPERTY_OCCUPANCY_CHECK",
location: { lat: 33.749, lng: -84.388 }
})tag_result({ tag_id: "tag_…" })
{
"outcome": "verified",
"checklist": [{ "item": "front door visible", "present": true }],
"verification": { "place": true, "time": true, "content": true },
"result": { "appears_occupied": true }
}What this server is not
An interface, never an authority.
The MCP server holds no business rules. It does not touch the database and it enforces no limits of its own — every call is a thin request to the same API a browser would use, and every ceiling is applied server-side inside the transaction that charges the card.
That is not an implementation detail. It means an agent calling these tools can do nothing a stolen API key could not already do, and it means there is exactly one place where the answer to “is this allowed?” lives. Two places that enforce a spending limit is one place that eventually does not.
A build check fails if the SDK or the MCP server ever imports a database client. The rule is enforced, not remembered.
What an agent cannot do
- Raise its own spending limit. Ceilings are lowered by API, raised only by a human.
- Approve proof that failed the place or time lock. Those need an administrator and leave an audit record.
- Have a Tag auto-approved with no content verdict. No verdict is never a pass — it routes to a human.
- Ask for work we will not send a person to do. Unsafe requests are refused with 422 before anything is charged.