My favourite MCPs: Resend

Resend is a great tool with a free tier for automating service emails, so why not hook it into your AI agent?

Not sure what an MCP server is or how it’s used? Check out my explainer here.

Resend is the plumbing that sends email from software — password resets, receipts, invoice reminders, the weekly report your system generates on its own. Not newsletters to a list; the individual messages your tools send without you. Its MCP server puts sending, contacts, domains, webhooks and, crucially, the delivery log where an assistant can reach them.

The reason it made this list is one specific afternoon. A client’s automated weekly report was set to go out at six in the morning, and I needed to know whether it actually had. The automation that triggered it said it had done its part. The invoicing side of things said its bit had run. Neither of them had the faintest idea whether an email reached a human. Resend’s log did: delivered, at the right minute, to the right person, with the right figures in the subject line. A question that had been open for a week closed in about thirty seconds.

That distinction is the whole value. Every component in a chain will happily confirm it did its job. A “sent” flag belongs to the thing that queued the message, and queuing is not delivering. There is exactly one component that knows whether mail arrived, and having its log available in the same conversation where I’m working means I actually check it, rather than assuming.

The failures it catches are the invisible kind. Automated reminders are precisely the thing that quietly stops working, because nobody notices a message that doesn’t arrive. A newsletter going missing generates complaints; a reminder going missing generates silence, then an awkward conversation about an unpaid invoice six weeks later.

Making it repeatable

The one-off ask:

Did this morning’s report send? Check the delivery log and tell me who it reached and at what time.

The standing version lives in a skill — a text file of instructions the assistant reads when the job comes up, written in English rather than code:

For anything email-related:
- "Sent" in the app that queued it is not delivery. Check the
  sending log at the provider.
- Report the timestamp and recipient from the log, never from
  a status flag.
- If a scheduled send has no log entry, treat it as failed and
  tell me straight away.
- Client-facing mail: draft it and stop. I send it.
- Never report a send as confirmed without quoting the log line.

The fourth rule is the one I’d insist on hardest, and it’s the least technical. Having the send available as a tool call makes it easier to skip human review, which is exactly why the rule has to be written down rather than assumed. Anything going to somebody who pays me gets generated automatically and then read by me. No raw machine output leaves the building.

The last rule exists because I’ve watched an assistant tell me an email went out when what it had actually seen was a queue confirmation. Requiring the quoted log line makes that impossible to fudge — either there’s a line to quote or there isn’t.

Domain setup gets easier too, incidentally. The records that decide whether your mail is trusted at all are readable and checkable as tools, rather than a support article you follow once and never verify again.

Resend’s free plan covers 3,000 emails a month, capped at 100 a day on one domain, which is plenty for anything personal, and their MCP server is documented and officially supported.

The report went out at 06:00 UTC, to one recipient, with that week’s figures in the subject line. I know because I read the log line myself, rather than being told it had gone fine.