Provides USDC settlement on Robinhood Chain, allowing paid API requests to be settled on-chain via EVM-compatible transactions after the upstream service responds successfully.
This server does not currently have a deployable release on Glama. Follow the repository's setup instructions to install and configure it for your MCP client, including any required credentials and local dependencies.
What is tab · Why tab · Mandates · New in 3.1 · New in 3.0 · How a payment works · Quickstart · For API providers · For agent developers · Companies · Settlement · x402 · Security model · Testing · Architecture · Roadmap
Related MCP server: Synergy MCP
tab is an open payment protocol for software agents.
It lets an agent discover a paid HTTP service, receive a price, authorize the purchase against rules set by its owner, pay, and receive the result. No human has to create an account, enter a card, or copy an API key.
Owners define those rules once, in a signed mandate:
Constraint | Purpose |
Total budget | Caps lifetime spend |
Maximum price per request | Blocks a single expensive call |
Allowed sellers | Restricts where money can go |
Spending window | Resets the budget each UTC day, or keeps one lifetime total |
Expiration | Ends the authority automatically |
The owner signs once. The agent then transacts on its own, and it cannot exceed what the owner authorized.
Owner
│
│ signs mandate
▼
Agent
│
│ HTTP request
▼
Gateway ────────► API
│
│ verifies mandate
│ enforces budget
│ settles payment
▼
USDGSoftware agents can already call APIs and use tools. Paying for those services is the part that still requires a person.
Today a human creates an account, enters payment information, generates an API key, configures billing, and hands credentials to the agent. tab replaces all of that with an HTTP payment.
Agent calls API
HTTP/1.1 402 Payment RequiredAccount signup, card on file, API key handoff, billing setup.
Agent pays through tab
HTTP/1.1 200 OK
Tab-Receipt: evm:0x...No account. No card details. No shared owner key. No unrestricted wallet.
A mandate is a signed spending authorization from an owner to an agent.
Field | Example |
Agent |
|
Budget |
|
Maximum per call |
|
Allowed sellers |
|
Expires |
|
The owner key never has to be online while the agent is working. Every payment is checked independently by the seller's gateway against the signed mandate, so changing the agent's prompt cannot increase its authority.
tab inside the x402 market that already exists, money saved you can see, more reasons to sell, and every charge publicly checkable.
Upgrade | What it does | From the CLI |
x402 sellers in search | The catalog reads the public x402 discovery list, about 33,000 routes from 3,200 sellers that take USDC on Base, beside tab's own. Agents pay them from their own address within the same mandate. |
|
A cache of paid results | The same GET within ten minutes is answered from the first purchase's proof, for nothing, and still verifies. POST answers only when the seller marks them reusable. |
|
Cost per task | Every paid call is tagged with the task, or the git branch, and summed with what the cache saved. |
|
The cheapest seller that works | Gateways publish each route's 7-day reliability; search ranks working sellers first, and a failed call comes back with alternatives. |
|
Rules in the mandate | Which routes, and which hours, signed into the mandate and enforced by gateways and the client. In tab OS, per agent. |
|
A public receipt log | Every receipt goes into a Merkle tree with a signed head. |
|
For sellers | Free calls per buyer per day, a notice on the first sale and daily earnings, signed earnings stats, routes priced by the kilobyte. |
|
Card top-ups and referrals | Stripe Checkout credits a ledger wallet once its signed webhook arrives; a referrer earns 10% of a referred buyer's card-funded spend. |
|
One command per tool | Cursor, Windsurf, VS Code and Codex, beside Claude Code. |
|
Base | A gateway spec for USDC on Base, and the client's Base signing domain checked against the chain. |
|
SPEC.md draft 0.9 has the wire format: rules in §2.3, free calls and metering in §5.6, the log in §5.9. docs/integrations.md covers every agent tool and framework.
Five upgrades that make tab useful in the first minute, for buyers, sellers and owners.
Upgrade | What it does | From the CLI |
One line to start | The MCP server sets itself up on first launch: keys, a $1.00 a day mandate and $1.00 of starter credits. No |
|
Proof of purchase | Every paid response is kept as a folder: the body, the gateway's signed receipt, the request and the mandate. One command checks the gateway's signature and published key, the body hash, the request, the agent's own signature on the payment, and the owner's signature on the mandate. |
|
Sell without a server | Sign a listing for your API and post it to a hosted gateway. It is served under |
|
Charge for an MCP server | List an MCP server and each tool becomes a paid route; the gateway makes the tool call, and a tool that fails is not charged. Buyers add it to Claude Code as tools of their own. A stdio server goes on HTTP with one command. |
|
Spend alerts | The owner signs a subscription at a gateway: a webhook (an ntfy.sh topic puts it on a phone with no account), budget percentages, and a daily statement. |
|
Hosted listings and alerts are opt-in for an operator (tab serve --listings --alerts), and both only reach public https addresses: no private networks, no redirects, checked again when connecting. SPEC.md sections 5.7 and 5.8 are the wire format.
Five things an owner can do after the mandate is signed, all optional, all backward compatible with 2.x mandates, clients and receipts.
Feature | What it does | From the CLI |
Instant revoke | The owner signs a revocation; gateways refuse the mandate, and every sub-mandate under it, within seconds. Gateways pass revocations to each other. |
|
Sub-mandates | An agent hands a narrower slice of its mandate to another agent key. Every limit stays inside the parent's, spend counts against every level, chains stop at three delegations. |
|
Approval above a threshold |
|
|
Pay on delivery | On routes that offer it, the buyer's payment is held until the seller delivers a result, then released with a receipt that binds the request to the result. Undelivered by the deadline, it comes back. |
|
Payment channels | One deposit, then a signed voucher per call with no transaction per call, settled once at close. Metered routes charge per token, second or unit, a fraction of a cent at a time. |
|
In tab OS each one has a home: a Revoke button on runs and agents, delegated budgets on a manager's card, payment approvals in the Inbox (with a thumb sized Approve on a phone), orders paid on delivery in Receipts, and channels in the Wallet. SPEC.md sections 2.1, 2.2, 5.4, 5.5 and 5.6 are the wire format.
tab uses standard HTTP payment semantics. A priced endpoint answers with 402 Payment Required and a signed challenge describing the purchase. The agent checks the price against its mandate and signs a credential bound to that exact request.
The gateway then runs the full lifecycle:
Step | Action |
1 | Verify the challenge |
2 | Verify the mandate |
3 | Verify the agent |
4 | Verify the exact request |
5 | Reserve the budget |
6 | Call the upstream service |
7 | Settle only after a successful response |
8 | Return a signed receipt |
If the upstream service fails, the payment is voided.
The receipt is signed by a key the gateway publishes, and it binds the whole purchase together: the mandate that allowed it, the exact request the agent signed, a hash of the response body that came back, the seller, and the payment (on Robinhood Chain, the transaction hash). So a receipt proves what was bought, not just that money moved. The client checks it against the bytes it received, and any edit breaks it.
Requires Node.js 22.13 or newer.
Give Claude Code a tab in one line:
claude mcp add --scope user tab -- npx -y https://github.com/paidwithtab/tab/releases/latest/download/paidwithtab.tgz mcpOn its first launch it creates an owner key and an agent key in ~/.tab, signs a mandate ($1.00 per day, $0.05 per call, 90 days), and claims $1.00 of starter credits on the public gateway at pay.paidwithtab.com. Nothing to fund, no chain, no API keys. Then ask Claude for something it needs to pay for, for example "find the weather in Lisbon through tab". From a shell, tab init does the same setup and prints what it made.
Those credits buy real things: 8,638 routes across 484 services, from web search, translation and speech to text to block explorers for 42 chains, market data from 20 exchanges, Wikipedia in 48 languages, SEC filings, US Treasury data, genomes, proteins and chemistry, package registries, RDAP and DNS, weather and space weather, between $0.001 and $0.02 a call. The full list with prices is in the quickstart.
1. Pay for something from the shell.
npm i -g https://github.com/paidwithtab/tab/releases/latest/download/paidwithtab.tgz # once; the command is tab
tab fetch "https://pay.paidwithtab.com/wikipedia/api/rest_v1/page/summary/Lisbon"paid 0.001 (ledger:cpKKYHocOLKlDW8n)
{"type":"standard","title":"Lisbon", ...}2. Prove what it bought.
tab receipts
tab verify ~/.tab/receipts/<folder>Every paid call is kept with its signed receipt. verify checks the gateway's signature against the key it publishes, that the body is the one it signed for, and that the agent itself signed the payment under the owner's mandate. Change one byte and it fails.
3. See a price tag.
curl -i https://pay.paidwithtab.com/fx/latest?base=USDHTTP/1.1 402 Payment Required
WWW-Authenticate: Tab challenge="eyJ2ZXIiOiJ0YWIvMCIs..."The starter credits are sandbox money on that one gateway. For real money, fund an agent with USDG on Robinhood Chain: docs/buyers.md.
Want the whole stack on your machine? git clone https://github.com/paidwithtab/tab && cd tab && npm install && npm run demo starts a paid API, a gateway, a catalog and a local wallet. Full walkthrough
Any HTTP API becomes payable with a small JSON specification. Leave out rail to run on sandbox balances while you develop.
{
"realm": "api.example.com",
"recipient": "<wallet>",
"rail": "evm",
"evm": {
"rpc": "https://rpc.testnet.chain.robinhood.com",
"chain_id": 46630,
"token": "0x5B6C7cAF7F99f99154fD8375ec935Fcf03F326f5",
"decimals": 6, // the token's decimals, 0 to 18; USDG and USDC have 6
"recipient": "<your 0x payout address>"
},
"upstream": "http://127.0.0.1:8080",
"routes": [
{ "method": "GET", "path": "/v1/things/:id", "price": "0.01" },
{ "method": "POST", "path": "/v1/generate", "price": "0.002" }
]
}Start the gateway:
tab serve \
--spec spec.json \
--announce https://paidwithtab.comThe gateway handles payment negotiation, authorization, settlement, receipts, and proxying. Your application keeps serving normal HTTP.
No server to run? List your API on the hosted gateway instead. It is paid to your own wallet, and it shows in the catalog:
tab sell https://api.example.com --price 0.01 --route "GET /forecast" --route "GET /cities/:id"
tab sell https://mcp.example.com/mcp --mcp --price 0.005 # an MCP server: one paid route per tool1. Create an agent key.
tab key new --out agent.json2. Issue it a mandate.
tab mandate issue \
--owner owner.json \
--agent agent.json \
--budget 5.00 \
--window day \
--max-per-call 0.05 \
--allow 'api.example.com' \
--out mandate.json3. Spend within those limits.
import { TabClient, receiptOf } from 'paidwithtab/client';
const client = new TabClient({
agent,
mandate,
maxPerCallUsd: '0.05',
});
const url = 'https://api.example.com/v1/things/42';
const res = await client.fetch(url);
const body = new Uint8Array(await res.arrayBuffer());
console.log(receiptOf(res)?.ref);
console.log(await client.verify(url, res, body)); // { ok: true }Or skip the key handling: tab init does all three steps and claims starter credits on the public gateway.
tab also exposes five MCP tools, so compatible agents can discover and purchase services without ever receiving the owner's private key:
Tool | Purpose |
| Find services in a catalog |
| Inspect a service and its pricing |
| Make a paid request |
| Check remaining budget |
| Read the active mandate constraints |
Hooking tab into a particular agent, with the MCP JSON for Cursor, Codex, Windsurf and Claude Desktop, framework tools, Python by subprocess, and where keys live in production: docs/agents.md
tab 2.2 runs a company of agents on top of the payment layer: tab company and the dashboard at app.paidwithtab.com. A company has a mission, a budget, agents with roles, and tickets. An agent is Claude, running on the Anthropic API key you add to the company with the five tab tools and nothing else, or any HTTP endpoint you point at (a self-hosted server can also run Claude Code). The difference from a plain agent orchestrator is where the money lives:
Every run gets its own mandate, signed by the company's owner key and capped at the smallest of the company's remaining budget, the agent's per-run budget and the ticket's cap. The gateway enforces it; the agent cannot exceed it.
What a run spent is what the gateways booked against that mandate, attributed to the run, the ticket and the company, receipt by receipt. Model cost is booked too. The company warns at 80 percent and pauses at 100.
Nothing closes without evidence: a receipt id, a URL, a file, the literal output. "Done" without it goes to review.
Hire, budget, approve, pause and publish are board actions signed with the owner key and verified on every read. Export the key and sign them offline.
A company can earn: publish the gateway it sells through and its receipts show up as earnings.
The first run takes under a minute and needs no key: sign up and press Start, or run tab company quickstart. A starter agent pays $0.002 for two Wikipedia lookups and hands back the answer with both signed receipts.
tab company serve --host app.example.com # one process, SQLite, no dependencies
tab company signup --email you@example.com --password ...
tab company quickstart # a $1 company; its starter agent pays and answers at once
tab company new --template examples/companies/research.json
tab company model-key --key sk-ant-... # your Anthropic key, sealed at rest; your agents run on it
tab company fund && tab company statusdocs/company.md has the packet an agent receives, the result it must return, the adapters, the board log and the server's trust boundary.
tab settles in USDG on Robinhood Chain mainnet and test USDC on its testnet, or in any ERC-20 a gateway chooses to charge in (its prices, challenges and receipts then name that token in currency), following a delivery first model. The gateway does not settle a payment until the upstream service has responded successfully.
authorize
│
▼
reserve
│
▼
call API
│
├── failure ──► void
│
▼
success
│
▼
settle
│
▼
receipttab speaks x402, the HTTP 402 payment standard that Coinbase started and Cloudflare, Visa and Mastercard build on, in both directions.
x402 buyers can pay a tab gateway. On the evm rail, every 402 carries x402 requirements (a PAYMENT-REQUIRED header) next to tab's own challenge. An x402 client signs an EIP-3009 transfer of exactly the price to the seller, sends it as PAYMENT-SIGNATURE, and gets the response with PAYMENT-RESPONSE and a signed tab receipt. The gateway checks the signature, the amount, the recipient and the time window, dry-runs the transfer, calls the upstream, and only then settles the transfer on chain from a small gas wallet of its own (--x402-settler). If it does not settle, the response is withheld. The public mainnet gateway takes x402 payments in USDG on Robinhood Chain (eip155:4663) today, so all of its routes are open to any x402 agent with no tab software at all.
tab agents can pay x402 sites. When a site answers 402 with only x402 requirements, the tab client pays it within the owner's mandate: realm (the site's hostname), per-call cap, budget and expiry, in a token it knows (USDG on Robinhood Chain, USDC on Base). x402 has the payer sign the transfer itself, so the owner funds the agent's own address with a small amount (tab evm fund --amount 5.00 --token 0x...), and that balance is a hard ceiling on top of the mandate. The client counts what it signs against the mandate in x402-spent.json next to the agent's keys, since an x402 site keeps no tab budget.
A gateway that speaks both is paid the tab way by a tab client, so owners keep custody and the mandate is enforced on both sides.
tab is built around bounded authority.
Property | Guarantee |
Owner keys stay offline | The owner signs the mandate. The agent never receives the owner's private key. |
Agents have explicit limits | Compromising an agent exposes only the authority its mandate granted. |
Requests are cryptographically bound | Credentials commit to the exact request, including query string and body digest. |
Payments cannot be replayed | Challenges are single use, and chain settlement adds a nonce boundary. |
Gateways hold no buyer keys | The gateway verifies and broadcasts what the agent authorized. It cannot create payments on its own. |
Security issues involving payment invariants should be reported privately through SECURITY.md.
tab currently runs 706 automated checks across protocol behavior, the 3.0, 3.1 and 3.2 features, adversarial conditions, EVM settlement and the company orchestrator, plus 40 browser checks of the dashboard and 20 checks of the channel contract on a real EVM.
Suite | Checks | Coverage |
| 90 | Gateway and its home page, catalog, MCP, receipts, payment lifecycle, starter credits, |
| 109 | Revoke and gateways sharing revocations, sub-mandates and their limits, approval above a threshold, pay on delivery, payment channels and metered routes, the 3.0 MCP tools and CLI |
| 68 | Concurrency, replay, mutation, SSRF, persistence, body smuggling, forged and tampered receipts, voucher floods against one deposit, sibling sub-mandates racing one budget, revocation floods, oversized upstream answers, catalog announce floods |
| 69 | The MCP server setting itself up on first launch, proof folders and |
| 127 | Spending rules in mandates on both sides and in sub-mandates, free calls, calls priced by size, route reliability, the receipt log with inclusion and consistency proofs and |
| 99 | Cryptography, EVM transactions, Robinhood Chain, x402 both ways, the testnet faucet, escrow and channels through an escrow address, hosted listings paid on chain to the seller's address, and Base read live: its USDC signing domain matches what tab signs |
| 144 | Accounts and the trust boundary, runs that pay at a real gateway, evidence and verified receipts, budgets, hire requests with model and per call cap, the signed board log, sealed model keys, the claude adapter against a scripted Messages API, claude-code through a fake binary, payment approvals, revoke, delegated budgets, orders and channels, agents' route and hour rules carried into their mandates |
| 40 | tab OS in a real browser (Playwright, |
| 20 |
|
The concurrency suite fires 150 simultaneous $0.01 requests at a $1.00 mandate. Exactly 100 settle.
┌─────────────┐
│ Owner │
└──────┬──────┘
│
signed mandate
│
▼
┌─────────────┐ ┌─────────────┐
│ Catalog │◄──────►│ Agent │
└─────────────┘ └──────┬──────┘
│
HTTP + payment
│
▼
┌─────────────┐
│ tab Gateway │
└──────┬──────┘
│
verify + authorize
│
┌─────────────┴─────────────┐
▼ ▼
┌──────────┐ ┌──────────┐
│ API │ │ USDG │
└──────────┘ └──────────┘src/ protocol, gateway, catalog, client, CLI and MCP
src/tools.ts the tab tools, shared by the MCP server and the company's claude adapter
src/proof.ts proof folders and tab verify
src/listings.ts, src/alerts.ts, src/mcp-bridge.ts hosted listings, spend alerts, MCP connect and MCP over HTTP
src/company/ the company orchestrator: store, engine, adapters, model (the Messages API loop), secrets, packet, board, server
src/evm/ EVM cryptography, transactions and JSON RPC
src/rails/ sandbox and EVM settlement rails
web/ site, catalog and the company dashboard
examples/ demos, example specifications and company templates
test/ protocol, adversarial, EVM and company tests
SPEC.md protocol specification
DEPLOY.md deployment and operationsThe specification lives in SPEC.md.
Current version: Draft 0.8 · Wire protocol: tab/0, and x402 version 2
Areas currently under exploration:
Gateways settling channels through the TabChannel contract
Windowed onchain budgets
Header binding and subscriptions
Fee splits and gas sponsorship
MIT. See LICENSE.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
This server cannot be deployed
Remote MCP utilities for agents: structured data, commerce checks, and x402 paid API discovery.
Agent-native MCP for governed commerce, x402 payments, paid capabilities, and verifiable receipts.
Host any HTTP API as MCP tools with a tamper-evident cross-agent settlement ledger.
Paid MCP tools behind one endpoint. Agents pay per call in USDC on Base via x402.
