№ 01For AI agents · Model Context Protocol
Hire the agent.
Keep the receipts.
Zatabox ships a first-party MCP server not a wrapper someone abandoned on GitHub. Every public API operation is a tool; every tool call is scoped, rate-limited, audited and idempotent.
// Claude Desktop · Cursor · any MCP client{ "mcpServers": { "zatabox": { "url": "https://mcp.zatabox.com", "auth": "oauth" // sign in once, scope what it may touch } }}// local stdio bring your own token{ "mcpServers": { "zatabox": { "command": "npx", "args": ["@zatabox/mcp"], "env": { "ZATABOX_API_URL": "https://api.zatabox.com", "ZATABOX_API_KEY": "vt_mcp_…" } } }}# self-host the server next to your stackdocker run -e ZATABOX_API_KEY=vt_mcp_… \ -e MCP_TRANSPORT=http -p 4100:4100 \ ghcr.io/zatabox/mcp-server“Put Friday's show on sale”
event_create → ticket_type_create → event_publish
“How did we do last night?”
checkin_stats → analytics summary in plain English
“Comp the press list”
comp tickets minted + emailed → attendees tagged
“Get me two GA for Friday”
discover_events → order_create → order_pay → order_verify_payment
№ 02Tonight's program
40+ tools. One credential.
The catalog, grouped by what the agent is doing including buying a ticket outright, verification and all. Names are stable; build on them.
Run the box office
Organizer-scoped create, publish, manage.
event_createdraft an event with venue, dates, capacity
event_publishtake a draft live
event_cancelcancel with a reason; triggers refund flow
event_listsearch events with filters
event_getfull detail for one event
ticket_type_createadd GA, VIP, early-bird, comps
ticket_type_listinventory and sale windows
Buy a ticket, end to end
The purchase chain passwordless guest checkout, verified actively.
discover_eventssearch the public catalog
order_createcart ticket types for any on-sale event
order_paycomplete payment crypto (nowpayments) · paystack · flutterwave
order_verify_paymentactively confirm settlement no webhook needed
order_getstatus, items, totals, issued tickets
order_cancelvoid an unpaid order
Grow, attend, audit
Growth, community, analytics and door tools 40+ in all.
my_tickets_listevery ticket across organizers
refund_requestfile a refund with reason
comps · broadcasts · tagsmint guest lists, email attendees, segment them
reviews · waitlistsreply to reviews, work the waitlist
webhooks · analytics · walletmanage endpoints, read sales and balances
checkin_scan · manifest · batchscan at the door offline manifest + sync included
Payout tools ship when payout requests launch the catalog only grows. Transports: stdio, streamable HTTP, or the Dockerfile.
№ 03Trust architecture
Autonomy with an undo button.
“Give an AI write access to money” is a sentence that should come with engineering. Here is ours.
01
Scoped like an API key
MCP tokens are prefixed vt_mcp_ and use the same scope grammar as REST keys. A marketing agent with events:write cannot touch orders or the door the API enforces it underneath, not the prompt.
02
Audited like a payroll system
Every tool call writes an audit row tool name, argument hash, result, token, human principal and fires the agent.action webhook to systems you control.
03
Idempotent by construction
Every write carries an Idempotency-Key with a 24-hour replay window. A retried call returns the original result; the same key with a different body is refused with a 409.
04
Throttled by default
60 tool calls per minute per token, with velocity limits on purchases underneath. An agent in a loop is a nuisance, not a catastrophe.
// fired on every MCP write webhook: agent.action{ "type": "agent.action", "data": { "tool": "order_pay", "args_hash": "sha256:9c1f…", "result_summary": "ord_31xq paid via nowpayments (usdttrc20)", "mcp_token_id": "vt_mcp_71b2…", }}Pipe agent.action into Slack, your SIEM, or a spreadsheet it's just a signed webhook.