Email, WhatsApp and Telegram over MCP. Your agent verifies the domain, writes the automation and ships it, inside guardrails that live on the server and not in the prompt.
Remind them an hour after the cart, then stop if they buy.
// the tool the agent calls
create_automation({
name: "Cart · 1h",
entry: "t1", nodes: [ … ]
})
// response
{ id: "aut_9f2", status: "draft", valid: true }Greatmessagingtakesmorethananendpointthatsends.
Itisknowingwhotoreach,onwhichchannel,whentowait,andwhentostop.
Sendingturnsthatjudgmentintoautomationsyouragentwrites,runsandcorrectsacrossemail,WhatsAppandTelegram.
Yousetthelimits.Itdoestherest.
One OAuth connection hands your agent the tools: contacts, templates, campaigns, automations, inboxes. You pick the permissions on the consent screen and change them later from Connections, without reconnecting.
Pick what it can do. Change it later from MCP connections, without reconnecting.
A flow is a graph, so it can be written, read back and corrected. Validation refuses a loop with no exit, a wait set two different ways and a trigger that leads nowhere, before a single message leaves.
{ "type": "wait", "duration": "PT1H" }
{ "type": "branch", "if": "contact.tags contains 'cliente'" }
{ "type": "message", "channel": "email" }Verified domain, suppression list, required idempotency key, plan quota and a per-contact frequency cap. They are enforced server-side, so an agent that convinces itself it has permission still does not send.
Every contact that walks a flow leaves a step with a reason in words: skipped, in suppression, quota reached. That is the answer to why this person never got the email, without opening a container log.
The work an agent cannot do is the work nobody sees: the domain that was never verified, the retry that sent twice, the flow that died quietly.
mail.tobo.solar
Amazon SES · eu-west-1 · your own signature
Mail leaves Amazon SES from your own verified domain with your own DKIM. The reputation you build is not pooled with ours.
Campaign metrics, automation stats and stuck enrollments are API and MCP surfaces, not just a dashboard page. An agent that can send but cannot read the result never learns.
Email, WhatsApp and Telegram behind the same contact model, with consent held per channel, so a flow can fall back instead of stopping.
Contacts and segments, templates, campaigns, flows, deliverability, attribution and the agent inbox. One model underneath, so nothing has to be kept in sync by hand.
Triggers, waits, conditions, splits, tags, sends. Twenty-one node types, each one actually executed by the worker: a node that draws but does nothing is worse than not having it.
Every send is checked against domain, consent, suppression, quota and frequency cap before it is queued, and what the cap held back is shown rather than dropped in silence.
Import contacts, tags, lists, campaigns and automations from ActiveCampaign. Nothing that arrives can send on its own: flows land as drafts.
UTM tagging on the way out, first and last touch on the way back, Stripe and PostHog as conversion sources, and CSV whenever you need it elsewhere.
First touch and last, within 90 days.
A real address on your domain that receives, threads and replies, with signed webhooks when mail lands and allow and block lists you control.
Everything on this page can be verified before you sign up. Where a claim has a page behind it, the card links to it.
Where the data lives
Built for agents“Anagentthatcansendbutcannotreadtheresultisnotautomatinganything.Itisjusttypingfaster.”
Everything worth asking before you connect it. Still missing something? Talk to us.
You may not have to. If all you need is a send endpoint, keep it. Sending is for the point where an agent has to do the rest: build the follow-up, own an inbox, tell you why a message never left.
No. The REST API is the whole surface, with typed TypeScript and Python SDKs generated from an OpenAPI spec. MCP is the same thing, addressed differently.
No. 3,000 messages a month, no card, no expiry date.
Verified domains, the suppression list, a required idempotency key, per-day volume and spend caps, and an audit log. All of it is enforced server-side, so a prompt cannot argue with it.
Email goes out on Amazon SES from your own verified domain, with your own DKIM. The reputation you build is yours, and it is not pooled with ours.
Yes. Every step a contact walks is recorded with a status and a reason in words, readable from the dashboard, the API and MCP.
They are graphs you can read. Fetch them as JSON over the API and take them with you. The import from ActiveCampaign works the same way, in reverse.
Postgres in the European Union, Frankfurt. Email leaves from Amazon SES in eu-west-1, on your own verified domain.
3,000 messages a month, free. No card. The MCP endpoint is on every plan, including this one.