№ 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 · Claude Code · ChatGPT no key needed// The client registers itself, then sends you to the Zatabox// organizer portal to approve the scopes it asked for.{ "mcpServers": { "zatabox": { "url": "https://api.zatabox.com/mcp" } }}// any MCP client, using an organizer API key{ "mcpServers": { "zatabox": { "url": "https://api.zatabox.com/mcp", "headers": { "Authorization": "Bearer vt_live_…" } } }}// local stdio bring your own API key{ "mcpServers": { "zatabox": { "command": "node", "args": ["/path/to/zatabox/server/_core/scripts/mcp-stdio.js"], "env": { "ZATABOX_API_URL": "https://api.zatabox.com", "ZATABOX_API_KEY": "vt_live_…" } } }}# MCP ships inside the core API, so self-hosting the# agent surface is just running the API: one process# serves REST (/api/v1) and MCP (/mcp) together.cd server/_core && npm installexport PUBLIC_API_ORIGIN=https://api.yourdomain.comexport PUBLIC_PORTAL_ORIGIN=https://organizer.yourdomain.comnode server.js curl https://api.yourdomain.com/mcp/health“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
102 tools. One credential.
The catalog, grouped by what the agent is doing including buying a ticket outright, verification and all. 48 are read-only and 22 are flagged destructive, so a client can tell a read from an irreversible write before it calls. 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, courses and door tools.
my_tickets_listevery ticket across organizers
ticket_downloadauthorize one download of a digital purchase
refund_requestfile a refund with reason
comps · broadcasts · tagsmint guest lists, email attendees, segment them
customers CRMbuyers, notes, tags, one-off white-label email
course_* (learner)study, sit the exam, collect the certificate
reviews · waitlistsreply to reviews, work the waitlist
checkin_scan · manifest · batchscan at the door offline manifest + sync included
Run the business
Organization admin, money and integration health the 12 tools OAuth unlocked.
organizer_mewho am I, and which org may I touch call it first
org_overviewthe dashboard in one call: revenue, sales-by-day, upcoming
organization_updatepublic profile, brand colours, header nav
org_members_listwho has access, and at what role
wallet_transactionsthe ledger behind the balance
payout_list · payout_requestwhere the money is and moving it, with a human's yes
refund_list · message_listwhat buyers are asking for, fenced as untrusted
notification_list · referral_getwhat you missed; your referral link and earnings
integration_metricsvolume, errors, p95 and per-key activity
The catalog only grows 102 tools across 14 modules today. Endpoint: https://api.zatabox.com/mcp over streamable HTTP, or stdio for local development.
№ 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
Approved by a human, in your portal
OAuth-capable clients get no key at all. They register themselves, then send you to the consent page in the Zatabox organizer portal, where you see the client, the exact scopes and an org picker before you approve or deny. PKCE is mandatory, redirect URIs are exact-match, codes are single-use and refresh tokens rotate and the token you grant is short-lived, revocable, pinned to one organization and attributable to you.
02
Scoped like an API key
Every credential carries the same scope grammar as REST organization:read, events:write, wallet:read and the rest. A marketing agent with events:write cannot touch orders or the door, and the credential is pinned to its organization the API enforces it underneath, not the prompt. Long-lived vt_live_ / vt_test_ keys still work, but a bare key has no human behind it, so the money tools (payouts) and organizer_me refuse one outright.
03
Audited like a payroll system
The server tags every call with an X-MCP-Client header, so a successful API-key write fires an agent.action webhook tool, method, path, status to systems you control, and lands in the key's API usage log.
04
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.
05
Throttled underneath
The REST API enforces per-endpoint rate limits and velocity limits on purchases beneath every tool. An agent in a loop is a nuisance, not a catastrophe.
// fired on a successful API-key write webhook: agent.action{ "type": "agent.action", "data": { "tool": "order_pay", "method": "POST", "path": "/api/v1/orders/ord_31xq/pay", "statusCode": 201, "at": "2026-06-10T15:21:47Z" }}Pipe agent.action into Slack, your SIEM, or a spreadsheet it's just a signed webhook.