A laptop showing SendGrid email statistics and a template editor, linked by a connector to a friendly AI assistant

SendGrid MCP: No Official Server, and What to Use Instead

No — SendGrid does not ship an official MCP server. That answer needs a caveat, because two things nearby look like one and neither is. Twilio (which owns SendGrid) does publish an official MCP server at twilio-labs/mcp, but it wraps Twilio’s Public API — messaging, voice, the 1,400+ endpoints behind your Account SID — and it does not cover SendGrid’s v3 email API at all. Separately, Twilio’s developer blog published “Build a SendGrid MCP Server for AI Email Workflows” in December 2025, which reads like a product announcement until you notice it’s a tutorial by an outside contributor showing you how to build one yourself.

So if you want SendGrid over MCP today, you are picking a community server or writing your own. Several good ones exist. Here’s what they do, the SendGrid setup they all require, and the one part of SendGrid that MCP structurally cannot reach.

SendGrid is one of many — the complete list of MCP servers covers every app that ships one, grouped by category.


Official vs. community: the three things people confuse

Search results for “sendgrid mcp” mix these together freely, so it’s worth separating them once:

  • Twilio Alpha MCP (@twilio-alpha/mcp) — genuinely official, genuinely Twilio’s. Alpha, local, single-user, authenticated with an Account SID and API key/secret. It is not a SendGrid server. Twilio has said it plans to add hosted auth and graduate it out of experimental, but that roadmap is about Twilio’s APIs.
  • The Twilio blog tutorial — a contributor post reviewed by a Twilio employee, walking through a five-tool server (send_email, get_template_info, send_template_email, add_contact, get_contact_lists) with the source on GitHub. Useful as a build guide. Not a shipped product, and it doesn’t reference an official SendGrid MCP either.
  • Community servers — the real options. Garoth/sendgrid-mcp (Node/TypeScript) is the most complete, with 14+ tools across contacts, lists, templates, sending, stats, and account info. There’s a Python/Flask one focused on pulling stats and saving templates, a Deno build on JSR, and hosted brokers like Pipedream and Composio that expose SendGrid tools without you running anything.

One caveat worth repeating because Twilio itself makes the point: they advise against running community MCP servers alongside official ones, since a server with credentials in scope is a real injection surface. A SendGrid key with full access can send mail as your domain. Treat it accordingly.

What a SendGrid MCP server can actually do

Across the community implementations, the useful envelope is roughly the same:

  • Send transactional email — one-off sends with HTML or text content, straight from a chat.
  • Send with dynamic templates — pull a template’s details, then send it with personalization data merged in.
  • Manage contacts and lists — add, update, delete contacts; create lists; move people between them.
  • Manage templates — create, list, retrieve, and delete dynamic templates.
  • Read stats — pull open, click, and delivery aggregates and reason about them in plain language.
  • Check account state — list verified senders and suppression groups.

That “send email” capability is more interesting than it sounds, because the mainstream assistant connectors are hedged about it in ways an MCP server is not.

Sending is no longer a clean dividing line. ChatGPT sends from Gmail with a confirmation each time. Claude sends through Microsoft 365 — added in July 2026, off until you enable it — while its Gmail connector remains draft-only. Neither will attach a file.

A SendGrid MCP server sidesteps that entire question. It isn’t sending from your mailbox under a vendor’s safety rules — it’s calling the v3 send endpoint with your API key, which will send whatever it’s told to send. That’s more power and correspondingly more rope.

Setting up the SendGrid side

Every one of these servers needs the same three things from SendGrid, and skipping the second or third is where most people’s first send fails.

1. Create an API key. In SendGrid, go to Settings → API Keys → Create API Key. You get three permission types: Full Access (GET/POST/PUT/PATCH/DELETE across most of the account), Restricted Access (custom — set each scope to No Access, Read Access, or Full Access individually), and Billing Access (billing endpoints only).

Most community servers document “full access” because they touch contacts, templates, stats, and sending. That’s convenience, not necessity. If your use is read-heavy — pulling stats, reviewing templates — build a restricted key with read scopes and nothing else. The key is displayed exactly once and SendGrid cannot retrieve it later, so store it when you create it.

2. Authenticate a sender. SendGrid will not send from an address it doesn’t recognize. Two routes: domain authentication, where you add SPF and DKIM DNS records for your sending domain, or Single Sender verification for one specific address. Single Sender is fine for testing and is required for Marketing Campaigns, but domain authentication is what you want before production — unauthenticated mail gets filtered to spam or blocked outright. Allow up to 48 hours for DNS to verify.

3. Know the sending rules. Garoth’s server documents the ones that bite: v3 APIs only (no legacy templates), you must supply either a suppression_group_id or a custom_unsubscribe_url when sending to a list, and the SendGrid API is eventually consistent — a contact you just added may not appear in the next read immediately. That last one confuses AI agents in particular, which will happily conclude the write failed and try again.

Then point your MCP client at the server. If you’re wiring this into ChatGPT specifically, the ChatGPT MCP servers guide covers the connector setup end to end. For the no-server route, connecting ChatGPT to SendGrid and connecting Claude to SendGrid cover the alternatives.

The Event Webhook is the part MCP can’t hear

Here’s the gap that matters most for SendGrid specifically, and it’s sharper here than for most apps.

SendGrid has genuinely excellent event data. The Event Webhook posts every meaningful thing that happens to a message: processed, delivered, deferred, dropped, and bounce on the delivery side; open, click, spamreport, unsubscribe, group_unsubscribe, and group_resubscribe on the engagement side; plus account_status_change. It is real, it is well documented, and it fires in near real time.

MCP cannot listen to any of it.

There is no such thing as an MCP trigger. The protocol's own working group states plainly that clients find out about server-side changes by polling for them, and a real event mechanism remains unshipped.

So the shape of a SendGrid MCP server is: you open a chat, you ask, it acts. A hard bounce on your best customer’s address, a spam report from an enterprise domain, a template quietly dropping deliveries — none of it reaches an AI unless you happen to ask the right question at the right moment. The webhook is broadcasting; MCP is a phone that only makes outgoing calls.

The other structural limits follow the same logic. It’s one app at a time — an MCP server that knows SendGrid doesn’t know your CRM, so “when this bounces, flag the contact and tell the account owner” means separate servers, separate auth, and hoping your client can hold both in one turn. And you own the hosting and the blast radius of that API key.

Wiring SendGrid events to something that reacts

That “react to an event, across apps” job is where Carly fits. Carly connects to SendGrid natively — no server to host, no npm package to keep current — alongside roughly 260 other apps, plus anything with a public API through your own key (paste them into Carly at carlyassistant.com/integrations). The difference from MCP is the one above: Carly’s workflows are triggered and scheduled, so SendGrid events actually go somewhere.

Things MCP can’t do that a Carly workflow can:

  • When an email hard-bounces → mark the contact invalid in your CRM, remove them from the active list, and post to #growth so nobody keeps mailing a dead address.
  • When someone files a spam report → suppress them everywhere, log it, and alert the owner of that campaign before it becomes a deliverability problem.
  • When a high-value recipient clicks a pricing link → notify the account owner in Slack while the interest is still warm.
  • Every Monday → pull last week’s delivery and engagement stats, summarize what moved, and send it to whoever owns the number.

The non-AI steps — the routing, matching, and moving between SendGrid and everything downstream — are free and unlimited, the Zapier-style backbone. The AI steps (drafting, summarizing, deciding) start at $35/month. You describe the outcome in plain language and Carly wires up the SendGrid connection and the apps on either side of it.

If you want to interrogate your SendGrid account from a chat window, a community MCP server does that well and Garoth’s is the one to start with. If you want SendGrid’s event stream to actually cause something to happen, that’s the job the protocol doesn’t have a mechanism for.

FAQ

Does SendGrid have an official MCP server? No. SendGrid does not ship one, and Twilio’s official MCP server (@twilio-alpha/mcp) exposes Twilio’s Public API rather than SendGrid’s v3 email API. Twilio’s developer blog published a guide to building a SendGrid MCP server, but that’s a contributor tutorial, not a released product. The working options are community servers such as Garoth/sendgrid-mcp, or hosted brokers like Pipedream and Composio.

What SendGrid API key permissions does an MCP server need? Most community servers document Full Access because they span contacts, lists, templates, stats, and sending. You can usually get away with a Restricted Access key scoped to only what you need — read-only if you’re just pulling stats. Create it under Settings → API Keys, and copy it immediately, since SendGrid shows it exactly once.

Can a SendGrid MCP server react to bounces or spam reports? No. SendGrid’s Event Webhook publishes delivery and engagement events including bounce, dropped, spamreport, open, and click, but MCP has no trigger or subscription mechanism to receive them — clients discover changes by polling. Reacting to a SendGrid event needs a workflow tool that listens to the webhook, such as Carly.

Why won’t my MCP server send email even though the API key works? Almost always sender authentication. SendGrid refuses to send from an address it hasn’t verified. Either complete domain authentication by adding the SPF and DKIM DNS records for your sending domain, or verify the single address under Sender Authentication. Sends to a list also require a suppression_group_id or a custom_unsubscribe_url.

Ready to automate your busywork?

Carly schedules, researches, and briefs you—so you can focus on what matters.

See what people say

"Before Carly, I relied on a Calendly link, but the whole process felt impersonal and not very professional. Carly changed that by handling all the back-and-forth, so I'm no longer stuck in endless email threads trying to line up schedules.

Now Carly reaches out to candidates, shares my real-time availability, lets them pick a slot, then sends a Zoom link and drops it straight into my calendar. She sends reminders to both of us before each call, which has significantly reduced no-shows and last-minute confusion.

On top of scheduling, Carly acts like a full executive assistant, sending me my schedule the night before so I can prepare for each call. It reminds me of the old x.ai assistant, but Carly is noticeably smarter, faster, and better suited to my healthcare recruitment business."

Gus Ibrahim, Founder & Director, IHR