Transport, not a second product
MCP
MCP is a transport for the same operations the REST API serves. There is one endpoint and it speaks HTTP. Nothing is installed on your machine, and the host still decides whether to call the gate before it acts.
Remote endpoint
POST https://api.afaprotocol.com/v1/mcp, JSON-RPC 2.0, methods initialize, tools/list and tools/call. Authenticate with X-API-Key: afa-beta-... or Authorization: Bearer afa-beta-.... The remote endpoint is in this build's API description.
curl -sS -X POST "https://api.afaprotocol.com/v1/mcp" -H "X-API-Key: afa-beta-EXAMPLE-e4qs" -H "Content-Type: application/json" \
-d '{"jsonrpc": "2.0", "id": 1, "method": "tools/list"}'Check: the response lists the tools in the table below. A 404 means this deployment does not serve the endpoint yet.
What a key needs
Any API key of the account may call initialize and tools/list. Each tool then needs the capability of the REST route it wraps, and only that one. A key without it is refused with scope_missing naming the capability it lacks, exactly as the route would.
Check: a key scoped to events:read lists every tool and calls afa_events_list; the same key calling afa_record_event is refused and the refusal names events:write.
Connect a host
Give the host the URL and the key header. Any host that speaks the streamable HTTP transport can use it; the two forms below are the ones most hosts accept.
claude mcp add --transport http afa https://api.afaprotocol.com/v1/mcp --header "X-API-Key: afa-beta-EXAMPLE-e4qs"Or, in a host that takes a JSON server list:
{
"mcpServers": {
"afa": {
"headers": {
"X-API-Key": "afa-beta-EXAMPLE-e4qs"
},
"url": "https://api.afaprotocol.com/v1/mcp"
}
}
}Check: the host lists afa_health among its tools and calling it returns the same body GET /v1/health returns.
Tools
| Tool | What it does |
|---|---|
| aa_intent_delta | See the details below. |
| aa_interference_scan | Detect concurrent exclusive-scope conflicts across a set of authority envelopes supplied in the request, within a time window. |
| afa_chain_verify | Verify your signed settlement blocks: each block hash recomputes and each block links to the one before it. |
| afa_dedup_check | See the details below. |
| afa_delegation_get | Fetch a machine-to-machine grant with its computed validity. |
| afa_delegation_grant | Issue a scoped, time-bound, use-capped grant from one machine to another and anchor it in your chain. |
| afa_delegation_list | List the machine-to-machine grants you issued or received, each with its computed validity. |
| afa_delegation_revoke | Revoke a machine-to-machine grant by id. |
| afa_event_get | Fetch one of your events with its ancestry along the previous-hash chain. |
| afa_event_lineage | Return the ordered ancestry of an event up to its genesis along the parent linkage. |
| afa_events_list | Search your events by type, tool, decision and time window, newest first. |
| afa_governance_enact | Put a ratified proposal into effect; from then on an enacted deny rule is consulted by the sub-agent grant gate. |
| afa_governance_list | List your governance proposals newest first, optionally filtered by status or by subject sub-agent. |
| afa_governance_propose | Record a proposal to change policy for one sub-agent subject; it is refused below the configured evidence threshold. |
| afa_governance_ratify | Approve a proposed proposal as a different identity from its proposer; the same identity is refused. |
| afa_grant_create | Create a sub-agent grant; a malformed grant is refused before anything is stored. |
| afa_grant_revoke | Revoke a sub-agent grant by id and exact sub-agent name; the response re-reads the status the gate now reports. |
| afa_grant_status | Check whether a sub-agent currently holds a live grant and, if not, why not. |
| afa_grant_use | Record tool calls consumed against a grant's budget; a use that would cross the budget is refused whole. |
| afa_grants_list | List your sub-agent grants, newest first, each with its current state. |
| afa_health | Report service liveness, the service version and which storage backend is serving. |
| afa_notifications_list | List your notification dispatch records, newest first, optionally filtered by severity. |
| afa_record_event | See the details below. |
| afa_service_pubkey | Return the service public key an auditor pins to verify delegation tokens offline. |
| afa_skill | Return the customer skill: how to authenticate, what each capability does, and the rules. |
| afa_surfaces | List every capability and which surfaces (REST, hosted MCP, SDK, console) offer it. |
| afa_usage | Return event aggregates for your account inside a time window. |
| afa_verify_checkpoint | Verify an exported checkpoint record, optionally against one exact pause; nothing is stored. |
| afa_verify_envelope | Verify an exported intent-envelope record against a public key; nothing is stored. |
| afa_verify_scientific_campaign | Verify a payload-free scientific campaign chain and return its signed stage and claim-state summary. |
| afa_webhook_delete | Remove your webhook registration. |
| afa_webhook_get | Return your current webhook registration. |
| afa_webhook_set | Register or replace the webhook URL that receives signed notification payloads. |
Tool details
aa_intent_delta- Compute a structured diff between two authority envelopes supplied in the request: added and removed scope, actor and action changes, and plan changes.
afa_dedup_check- Ask whether an identical tool call already sits in your ledger inside the cache window, with a membership proof for scoped hits.
afa_record_event- Append one event to your chain; the previous hash, the sequence and any registered signing key are checked before it is stored.
What is also served today
GET /v1/mcp/tools and POST /v1/mcp/call expose two pure tools, aa_intent_delta and aa_interference_scan, that compute a result from envelopes in the request body and touch no stored state. Details are in the API reference.
Limits
A tool call is one HTTPS request. Nothing runs when the network is down, because nothing runs on your machine. The transport does not make a host ask before it acts; that decision belongs to the host's own configuration.