Skip to main content
Every tool below is exposed by POST /v1/mcp and delegates to the same service as its REST counterpart, so the behaviour, validation, and tenancy rules documented across these pages apply unchanged. The Scope column is the scope your token needs. Without it the tool still appears in tools/list, and the call fails with INSUFFICIENT_SCOPE — see how scopes are enforced. Tools marked 🔴 delete data permanently.

Contacts

Read and write the people on the other side of your channels. See the Contacts endpoints for the full field reference.

CRM

The full pipeline: customers, tickets, tasks, notes. See the CRM overview for how the entities relate.
CRM reads are company-wide. Every *_list and *_get tool returns records from every project in your company, not just the one the token was minted for.

Customers

Tickets

Tasks

Notes

Knowledge

Retrieval and authoring against the tenant knowledge base. See the Knowledge overview.

Messaging

Everything under /v1/messages. Every send tool takes an optional channel (whatsapp, whatsapp_qr, instagram, messenger; defaults to whatsapp) plus channel_id or phone_number_id to pick the concrete channel. Free-form sends only work inside the 24-hour window; outside it, only keebai_send_template gets through.

WhatsApp Flows

In-chat forms. See the Flows guide for the full lifecycle.

Media

Uploading and downloading the binary itself is REST-only — POST /v1/media/upload is multipart and GET /v1/media/{id}/download returns raw bytes, and neither fits a JSON tool call.

Ecommerce

Read-only access to the catalog, carts, and sales. See the ecommerce overview for how the records relate — a cart is not a draft sale.
There are no write tools here. Creating a sale or pushing a product goes through the platform integration, not the API.

Loyalty

Points, stamps, and wallet cards. See the loyalty overview for the data model — in particular that there is no reward entity and that balances are a projection, not a sum of the ledger.
Tools marked ⚠️ have effects outside Keebai. keebai_loyalty_ledger_record moves a balance a customer can spend and is not idempotent — a retried call double-counts. keebai_loyalty_pass_notify sends a push notification to a real phone.Neither is destructive, so neither carries the 🔴 marker, but hand loyalty:write to an agent with the same care you would give messages:send.

Scheduling

Branches, services, professionals, availability, and appointments. See the scheduling overview for the booking model — in particular that an appointment lands in pending, and that reading a slot does not hold it. Arguments keep the REST names: the availability and list tools take serviceId, branchId, and professionalId like the query strings they mirror, while keebai_scheduling_appointment_create takes branch_id, service_id, and start_time like the request body. Dates are YYYY-MM-DD and times HH:mm, both in the branch’s timezone. The appointment id is a UUID, not an ObjectId.
Tools marked ⚠️ reach the customer. Creating, confirming, or cancelling fires the scheduling webhooks, the CRM event on the contact’s timeline, and the reminder and confirmation notifications the account has configured.A slot read from availability is a snapshot, not a hold. When keebai_scheduling_appointment_create fails because the slot was taken, the agent should query availability again and offer the new options rather than retry the same time. An appointment left in pending holds its slot until someone cancels it; nothing expires it.

Agents

Read and write the configuration of the agents themselves: their goal, the sections of their prompt, the funnel, and the webhook tools they can call. Twenty-five tools, all on agents:read or agents:write.
Writing here changes what your bots say to customers. An agent with agents:write can rewrite any prompt section and create webhook tools that make Keebai’s infrastructure call an external host — the URL is validated against loopback, private ranges and internal names, but a public host of the agent’s choosing is allowed. Treat it as a higher-privilege scope than the read side, and read webhook security before handing it out.Tools are company-wide, unlike agents and their sections, which are scoped to the token’s project.keebai_agent_query never touches real data. It runs the turn with the write tools simulated, so an agent can verify its own change without booking anything.

Not exposed as tools

Templates, channels, webhooks, tenants, and setup links have no MCP tools yet. Use the REST API for those. CRM events are not tools either, and that one is on purpose rather than pending. Emitting an event is a system-of-record write from a system that knows something happened — an order closed, a delivery completed. A model deciding to emit one is a model asserting a fact it cannot verify. Call POST /v1/webhook/events from the system that owns the fact.
Keebai’s own agents can emit events, through an internal tool gated by an ai_triggerable flag you set per event type in the portal. That flag defaults to off and does not apply to this MCP server, which is your agent talking to the API, not Keebai’s agent talking to itself.
The binary Apple .pkpass has no tool either, for the same reason as media download: it is a file, not JSON. The Apple link tool covers the same use case.