One command
Get the key in the dashboard (Account → MCP), then the assistant connects with a single command — and talks to the Builder in plain words, just like you do in the dashboard.
Everything the dashboard can do is available from code
The dashboard is a conversation with the Builder. The same Builder answers your app, your AI assistant and your script.
Manage your agents from Claude or ChatGPT
MCP is a way to give your AI assistant access to another product. Our server gives it the same things you see: the agents in your dashboard, what's broken in them, and the conversation with the Builder.
Looks before it changes
The list of agents and what's broken in them — separate from the conversation. The assistant doesn't guess who it's working with and doesn't ask you things the platform already knows.
Changes things in exactly one way
All changes go through the same conversation with the Builder as in the dashboard. There's no second set of rules that will sooner or later drift away from the first.
Your agent as a tool in Claude or Cursor
The same standard, the other way around: instead of a program managing the dashboard, your assistant answers another program. “Ask my support agent” — and Claude asks it itself.
A key for each app
Tell the Builder “make a key for Cursor” — it'll issue a key and a ready-made config. Keys are named: you can see who's calling, and you can revoke one without touching the rest.
Another program — as a visitor
It asks the assistant questions and gives it long tasks with the same rights as a person in the chat window. It won't get access to email, the calendar or “owner-only” actions.
You pay — and you set the limits
Every call spends dashboard credits; the agent's spending cap and rate limit apply here too. When credits run out, the app is told so directly, not “something went wrong”.
How to grant access and what's supported from A2A — in the Guide
A full API, not an “integrations corner”
It's not a separate, cut-down surface: the dashboard uses the same endpoints. Whatever a button can do, a key can do.
A key for one bot
A secret key (sk_) works with one agent: knowledge, conversations, actions. If such a key leaks, it doesn't give anyone control of the dashboard.
Management key
The Builder key (ck_) opens the Builder itself — and MCP. It's used to manage agents; a new key immediately revokes the previous ones.
Universal endpoint
Your app, internal chat or POS sends messages and reads the reply right away — from the same agent that answers on your website.
Events come to you on their own
No polling needed: the platform calls your address itself when the thing you're waiting for happens.
What we send
A visitor asked for a person, left their contact, the agent broke. Every event is signed, so you can verify it really came from us.
Separate keys
Operator handoffs and failures are signed with different keys: access to one system doesn't let anyone forge the other.
Retries
Your service didn't respond — we'll try again. The order and retries are documented, not left to guesswork.
Chat window on your website
One line in the page footer. And if your server confirms who's on the site right now, the agent recognizes a returning customer and remembers them between conversations.
One line of code
Color, greeting and title are changed in the dashboard — no need to paste the code again.
Visitor signing
A name sent by the page proves nothing: anyone can put in someone else's. That's why remembering a person works only where YOUR server has signed their identity.
Page as context
The window can tell the agent what the visitor is looking at right now — along with the product's price, availability and SKU.
Build the agent first — connecting it to code takes a minute
Keys and addresses appear in the dashboard right after you sign up, and none of these features requires a separate plan.
Build an assistant