Why I built MCP Emails
I got bored of writing emails to customers.
Not because I dislike customers. Most of the time, the emails are reasonable: someone needs help getting started, something does not work as expected, a question comes up before they buy, or a customer wants to know whether a feature is planned.
The problem was the shape of the work. An email arrives, I stop what I am doing, open the right product, find the context, write a reply, and then try to remember what I was working on before. Repeat that enough times and email starts taking up more of the day than it deserves.
For a small product, this is easy to accept at first. You are grateful that people are using it. Every email feels important. It probably is important. But being responsive does not mean every reply needs to be written from scratch inside an inbox.
I wanted a way to make customer email a smaller part of my day without making it feel impersonal. That is why I built MCP Emails.
There are plenty of tools for email. There are help desks, shared inboxes, CRMs, AI writing assistants, automations, templates, and rules for almost any workflow. I did not want to set up a new support operation. I wanted less ceremony around a simple task: read an email, understand the context, send a good answer.
The information I needed was usually somewhere else. A customer would ask about a subscription, an account, a feature, or a payment. The answer depended on product data, past conversations, internal notes, or what had changed recently. The inbox was only the start of the job. The actual work was switching between tools.
You can put templates in a help desk. You can ask an AI tool to rewrite a draft. Neither solves the part where you still have to gather the information and decide what is true before you hit send. MCP Emails is built around that gap.
MCP stands for Model Context Protocol. In practical terms, it is a way for an AI assistant to work with tools and data you choose to expose. For email, that matters because a useful answer is rarely just well-written. It has to be correct.
If someone asks whether they can change their plan, the answer should reflect the current product. If they ask about an invoice, it should be based on their actual account. If they report a bug, the reply should include enough detail to move the conversation forward. The goal is not to hand your inbox over to a model and hope for the best. The goal is to make the right context available when you need it.
That might mean finding a previous thread, checking a customer record, looking up an order, or pulling a relevant internal note before drafting a response. I still decide what gets sent. The difference is that getting to a useful draft should take minutes, not a string of tabs and searches.
"AI support" often means a chatbot that tries to stop people from reaching a human. That can be useful in the right place, but it is not what I wanted to build. I wanted a better tool for the person who is already responsible for the reply.
Customer emails are also one of the best sources of product information I have. They tell me where onboarding is unclear. They show me which words people use to describe the product. They expose the assumptions I made while building it. Sometimes a short email points directly at the next feature worth shipping.
I do not want to remove that signal. I want to remove the busywork around it. A good support reply is often short. It might be a direct answer, a link, an apology, or a note that something has been fixed. Writing that answer should not require rebuilding the entire customer story in my head every time.
MCP Emails started from a selfish requirement: I wanted to spend less time in email. If I have a limited number of focused hours in a day, I would rather use them to improve the product, fix an issue properly, or make something easier for every future customer.
The standard is not full automation. The standard is a faster path to a response I would be comfortable sending under my own name. That means keeping the user in control, making sources and context visible, treating a draft as a draft, and being careful about permissions. An email tool only works if you trust it with a sensitive part of your business.
Big companies can afford elaborate systems and dedicated support teams. Most small internet businesses cannot, and often do not need to. A founder might handle sales, support, product, marketing, bookkeeping, and a dozen other things in the same week. The tools should respect that reality.
There is no grand theory behind it. I think email can be less annoying. I think better context makes replies better. And I think founders should be able to stay helpful without turning support into a full-time job.