KoltrixMCP, the email API or Zapier: which one fits which email job?
MCP assistants, an email API and automation tools solve different problems. See which fits triage, product email and routine rules, and how to combine them.
On this page(9 sections)
"Should I use MCP, the API, or an automation tool?" is a fair question, and the honest answer is that they solve three different problems that happen to touch the same inbox.
Choosing wrong is not fatal, but it is annoying. People wire an API integration to do something that needed judgment, or ask a chat assistant to do something that should run every hour without them. This post draws the lines.
Three tools, three jobs
| MCP assistant | Email API / SMTP | Automation platform (Zapier-style) | |
|---|---|---|---|
| Who or what is in charge | You, in a chat | Your code | A fixed workflow you built |
| Runs when | You ask | Your app decides | A trigger fires |
| Handles messy judgment | Yes, that is the point | No, you encode rules | Only simple branching |
| Good at | One-off questions, triage, drafting | Product email at volume | Repeating "when X, do Y" |
| Needs a person present | Yes | No | No |
Everything below elaborates on that table.
MCP: a person with a very fast assistant
MCP, the Model Context Protocol, is an open standard for giving AI assistants tools. When you connect Koltrix, your assistant can search, read, organize and draft in your mailbox because you asked it to, in the middle of a conversation.
What MCP is good at is the work that is hard to specify in advance:
- "What came in overnight that needs a reply from me?"
- "Find the thread where we agreed the renewal date and summarize it."
- "Draft a reply to the newest message from Acme saying we'll ship Friday."
Those requests are vague on purpose. A rule engine would need you to define "needs a reply" in advance. An assistant reads the thread and decides, and you check its work. The cost is that a person has to be there. An MCP connection does nothing on its own at 3 a.m. If the assistant is closed, nothing runs.
Koltrix's MCP server works with your own access. The assistant sees the mailboxes you can open, and by default it reads, organizes and drafts. Sending is off unless an admin turns it on, and then the assistant has to show you the message and get your yes. See what MCP is if you want the underlying idea first.
The API: your software sending email
Koltrix's transactional email API is the other direction entirely. Your product calls POST https://api.koltrix.com/api/v2/emails with an API key to send a password reset, a receipt or an invoice. There is also an SMTP relay for software that already speaks SMTP, plus webhooks that report delivery events.
The API is the right tool when:
- The email is generated by your application, not written by a person.
- It must go out reliably whether or not anyone is awake.
- Volume matters, and each message needs a deterministic result and an audit trail.
No judgment is involved, and that is a feature. A password reset email must be the same every time. You would not want an assistant improvising it.
The two are complementary in a specific way. Replies to your product's email land in your team inbox, threaded under the message that caused them. An assistant connected over MCP can then help you work through those replies. The API sends; MCP helps a human handle what comes back.
Automation platforms: fixed workflows
Tools in the Zapier family sit in between. You define a trigger (a new row, a form submission, a new message) and a chain of actions. They shine at repetitive glue work: copy this field there, post a notification here, create a ticket when a label appears.
At the time of writing, these platforms have added AI steps, but the shape is still a workflow you designed ahead of time that runs when its trigger fires. That makes them predictable and unattended, and it also means they do exactly what you built, including when the situation has changed.
Choose an automation platform when the rule is simple, the trigger is clear, and you want it to run without you.
How to choose, with examples
| Situation | Best fit | Why |
|---|---|---|
| Send a welcome email when someone signs up | API | Your app owns the event, it must be reliable |
| Catch up on the inbox after a trip | MCP | Needs summarizing and judgment, and you are present |
| Post every email labeled "invoice" to a spreadsheet | Automation platform | A clear trigger and a fixed action |
| Draft replies to this week's customer questions | MCP | You want to review wording before it goes out |
| Send a daily usage report to customers | API | Scheduled, templated, no judgment |
| Tag newsletters automatically as they arrive | Rules in Koltrix | Simple, runs by itself, no assistant needed |
That last row is worth noting. Koltrix has auto-label rules, and for mail that arrives and should be tagged the same way every time, a rule beats an assistant. An assistant is better for the one-off sweep: "label everything from our accountant Finance and archive the receipts". See organizing your inbox by chat.
Combining them
The strongest setups use more than one.
Send with the API, handle replies with MCP. Your app sends receipts and password resets through the API. Customers reply, and the replies appear in your team inbox. On Monday, you ask your assistant which of those replies need a human and have it draft answers.
Rules for the routine, MCP for the exceptions. Auto-label rules sort the predictable mail. You use the assistant for the rest: finding things, summarizing long threads, drafting.
Automation for notifications, MCP for decisions. An automation could tell a channel when a new message arrives under a certain label. The decision about what to say back is a drafting job for you and the assistant.
Where people go wrong
- Using MCP for something that must run unattended. If it must happen at a set time with nobody there, it is not an assistant job.
- Using the API for judgment. Do not encode "should we refund this customer" as if-statements when a person should read the thread.
- Letting an assistant send at volume. Koltrix limits assistant sending on purpose: at most 10 recipients per message, 20 sends a day per connection and 50 a day per workspace through assistants, no Bcc and no attachments. Bulk or scheduled sending belongs in the API.
- Over-automating the inbox. The more a workflow acts without a person, the more you need to trust the rule. Start with read-only automation, then add actions.
A note on safety across all three
Anything that reads email is reading text written by strangers, and some of it may be written to manipulate an AI. MCP concentrates this risk because an assistant is reading and acting in the same session. That is why Koltrix keeps the assistant's powers narrow, marks email content in tool results as untrusted, and keeps sending behind an admin switch and your explicit yes. Defending AI assistants against hidden instructions goes deeper.
Key takeaways
- MCP is for tasks where a person is present and the work needs judgment: triage, search, summaries, drafts.
- The API and SMTP relay are for your software sending product email reliably, with no judgment involved.
- Automation platforms are for fixed, unattended "when X, do Y" workflows.
- The best setups combine them: send with the API, sort with rules, and use an assistant over MCP for the work in between.
- Koltrix limits what assistants can do on purpose, so high-volume or scheduled sending belongs in the API.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
