The email API an agent can run on its own
A person signs up and creates a key. After that the agent is on its own: it sends mail, reads the delivery record and checks what is left of the plan, over REST or MCP, with no browser and nobody approving each send.
One key, made once
A key is created by a person, in the dashboard, and it is the only credential the agent ever needs. It is shown once. Everything below is authenticated with Authorization: Bearer <api key> and nothing else — not a url, not a query parameter, not a tool argument.
A browser session cannot stand in for it. Presenting one to MCP answers 403 session_not_allowed, which is a statement that the credential is the wrong kind rather than an invitation to sign in again.
What an agent needs
- An HTTP client. That is the whole SDK requirement — there are no client libraries.
- An API key a person created for it.
- A domain the team has verified, because
frommust be an address at one. That is true on every plan and on the free tier.
How an agent finds any of this
Four surfaces, all readable before anything is called and none of them requiring a key:
GET /plans every plan, with its price, as JSON GET /llms.txt the whole integration, in one file GET /skills/openai.json function definitions for tools[] GET /skills/gemini.json the same surface, as declarations
The catalogue is on api.pony.email; the four files are on this host.
MCP, for a client that speaks it
https://api.pony.email/mcp mounts the API as four tools: send_email, get_email, get_usage and get_plans. Only the last needs no key.
It is the streamable HTTP transport in stateless mode. A client that cannot set an Authorization header is refused on everything but the catalogue, so check that before you connect. The transport rules are in the API documentation.
What the agent runs into
A paid plan is a fixed window of included sends that renews every 30 days on its own subscription cycle; a team with no plan is on the free tier, which resets on the first of the calendar month, UTC. When the volume is spent, the next send answers 402 payment_required and names the billing page in the dashboard. A paid plan opens its next window on renewal; an agent cannot buy or change a plan, so anything sooner is for a person.
An agent that wants warning rather than a refusal should read GET /usage, which reports the sends left and when the window ends.
Sends are idempotent on the Idempotency-Key header. A retry after a timeout returns the original message rather than sending a second copy, which matters more here than usual, because the caller deciding to retry is a program with no way to ask.
The FAQ covers what a plan buys, and the terms govern what the key entitles its holder to.