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.

claude_desktop_config.json
{
  "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.

Any MCP client
command: npx -y @irl/mcp-server
env:     IRL_TAGTEAM_API_KEY=irltag_live_…
         IRL_TAGTEAM_API_URL=https://tagteam-api.successagenticlabs.com   # optional

Tools

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_capabilityDescribe 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_tagWhat 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_capabilitiesEvery 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_tagThrow a Tag from a standard Recipe and a location. The shortest correct request.
throw_tagThrow a Tag, stating the work, proof requirements and window yourself.
list_recipesEvery standard job available, with what each one requires as proof.
describe_recipeOne 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_statusWhere the Tag is in its lifecycle right now.
tag_resultThe structured answer — outcome, checklist, per-lock verification, evidence hashes.
rule_on_proofApprove or reject submitted proof.
raise_disputeFreeze 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_partnersHow much verified supply exists near a point. Counts, never identities.
check_coverageWhether this platform can actually deliver at a location.

At scale

Many locations, or the same location repeatedly. Every location stays independently auditable.

create_campaignOne Recipe across many locations, each funded and verified on its own.
campaign_statusProgress and spend across a campaign.
create_scheduleRecurring Tags with a hard budget and a single next run.
pause_scheduleStop 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_identityWho 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_missionWould 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_limitsEvery ceiling this Corner is subject to, and whether creation is paused.
account_statusPlan, 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.

Tool call
throw_recipe_tag({
  recipe: "PROPERTY_OCCUPANCY_CHECK",
  location: { lat: 33.749, lng: -84.388 }
})
Later, once the bell has rung
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.

Give it hands.