How to let an AI agent send email with MCP, without pasting a key

The Model Context Protocol is a specification for handing an assistant a set of tools. An MCP email server is that specification applied to a sending platform: every operation the API offers, described in a way a model can read, so an assistant can add a domain, send a message or look up what happened to one without anybody writing the HTTP call.

The reason to care is narrower than the hype. It is not that a model can now write an email. It is that setting an email account up is a sequence of steps a person does once, badly, from documentation — add a domain, publish four records, wait, create a key, wire a webhook, send a test — and that sequence is exactly the shape a tool-using assistant is good at, provided it cannot do anything irreversible along the way.

Letting an AI agent send email with MCP is a trust decision before it is an integration, so it is worth starting there rather than with the command.

A connected app never gets an API key. It gets an OAuth access token, issued for one team, carrying only the scopes approved on a consent screen you saw, and revocable from Connected apps at any moment. There is no step where a credential is pasted into a desktop application and no way for a prompt to contain one.

Some things have no scope at all, because the tools do not exist: minting or revoking an API key, changing your plan or your team, deleting a domain, a template, a broadcast or an automation, erasing a contact, lifting a suppression, regenerating a signing key. There is no consent screen anywhere that could hand any of it over.

Seventy-four tools, grouped into seven toolsets so a client can load only what it needs.

Narrowing is worth doing. Every registered tool costs context on the model’s side, and an assistant that only ever sends does not need the audience and billing tools in front of it while it works.

claude mcp add --transport http rasket "https://api.rasket.com/mcp?toolset=setup,send"

A tool outside the named toolsets is not registered: it is missing rather than refusing, which is the same principle the scopes follow. An unknown toolset name is an error before any tool runs.

1. Add the server to your client — Run the one-line command your MCP client provides, pointing it at the HTTP endpoint. Clients that take JSON instead accept the same URL as an http server entry.
2. Approve the scopes on the consent screen — A browser window asks which team the assistant is acting for and which scopes it may hold. Approve only the ones the task needs; the scopes decide which tools exist at all.
3. Let it call describe_setup first — That tool needs no scope and is always registered. It returns the setup recipe with each step marked as allowed or blocked, plus the scopes that are missing, so the assistant knows what it can finish.
4. Have it add and verify a domain — The assistant creates the domain and reads back the DNS records to publish. Publishing them is yours to do, at your DNS host; verification then runs on its own until every record resolves.
5. Send the first message — Ask for one message to an address you control, from the verified domain. Have the assistant pass an idempotency key so that a retried tool call cannot become a second email.
6. Wire a webhook and watch the events — Creating a webhook returns its signing secret once. Store it in your own environment, verify every delivery against it, and follow the message from sent to delivered.

claude mcp add --transport http rasket https://api.rasket.com/mcp

Clients that take configuration as JSON accept the same endpoint.

{  "mcpServers": {    "rasket": {      "type": "http",      "url": "https://api.rasket.com/mcp"    }  }}

For an assistant working inside a repository there is a second shape: the setup recipe ships as a skill you copy into the project, and as a rules file for editors that read one. Same twelve steps, no server connection required — useful when the assistant is writing the integration rather than operating the account.

describe_setup needs no scope and is registered whatever the toolset filter says, so it is always available. It returns the setup recipe with each step marked as allowed or blocked for this connection, plus the scopes that are missing.

{  "steps": [    { "id": "add_domain", "tool": "create_domain", "scope": "domains:write", "allowed": true, "reason": null },    { "id": "send_broadcast", "tool": "send_broadcast", "scope": "broadcasts:write", "allowed": false, "reason": "Needs the broadcasts:write scope." }  ],  "missing_scopes": ["broadcasts:write", "automations:write"]}

That shape matters more than it looks. An assistant that starts by asking what it may do can tell you it needs a wider grant before it is halfway through setting your account up, rather than failing on step nine and leaving you to work out which half happened. It is the difference between an agent that stops and asks and one that stops.

Tools are half of it. The other half is that an assistant reasoning about your integration needs the documentation, and HTML full of navigation is a poor way to give it that.

• Add .md to any documentation URL, or ask for the page with an Accept: text/markdown header, and you get the same page as Markdown. Every post on this blog has the same twin.
• /llms.txt is an index of every page written for a model to read, following the llms.txt convention; /llms-full.txt is the same pages concatenated into one file.
• The whole API is served as an OpenAPI document, which is what the SDKs are generated from.

The practical effect is that an assistant asked to add sending to a codebase can read the reference for the endpoint it is about to call, rather than recalling an API shape from training data that may be two versions old.

The platform enforces the boundary. These are the habits worth keeping on your side of it.

• Approve the narrowest grant that finishes the job. You can always reconnect with more. Starting wide because it is convenient is how a scope nobody needed stays live for a year.
• Insist on idempotency keys. A tool call that times out and is retried is exactly the case the key exists for; ask the assistant to derive one from the thing being sent about. The idempotency article covers how to choose them.
• Send to yourself first. The first message an agent sends should go to an address you control, from a domain you just watched it verify.
• Read the audit log. Every tool call is an ordinary API request in your logs, showing the tool and the connected app that ran it, and accepted broadcasts and imports are written to the audit log by name.

The MCP reference lists every tool with its scope, the agents guide has the setup recipe and the skill, and the agents page is the shorter version of all of it. The OAuth documentation covers what a grant actually holds.