Email MCP server for AI agents, with OAuth

An email MCP server lets an AI agent work with an email platform through the Model Context Protocol: inspect a project, set up a sending domain, send a message and read the delivery record. Boundry runs one as a hosted remote server at https://api.au.boundry.dev/mcp. You add that URL to an MCP client, sign in, approve one project, and the agent can use ten tools inside that project. It never receives your password, session or a copied API key.

Sydney is Boundry's only live region, so the project you approve is a Sydney project.

What you need before connecting

• A Boundry account and a Sydney project. If you have neither, you can create an organisation and project during the approval step.
• An MCP client that supports remote servers over Streamable HTTP with OAuth, such as Claude custom connectors.
• A domain you control, if you want to send. A dedicated subdomain such as mail.example.com is the safest choice. The agent can create the domain, but only you can publish its DNS records. If you add receiving, keep any MX records your mailbox provider already uses, and publish inbound MX records only after your project reports receiving as ready.

Connect the server in three approvals

Add the remote server URL to your client. In Claude, that is Settings, then Connectors, then Add custom connector, with the name Boundry and this URL:

{
  "name": "Boundry",
  "url": "https://api.au.boundry.dev/mcp"
}

Other clients take the same URL with the streamable-http transport. A compatible client discovers Boundry's OAuth and authorization-server metadata on its own, registers its callback, and opens an approval page. There you do three things: sign in or create an account, choose one Sydney project, and review the client name, callback host, project, region and requested scopes before allowing access.

The resulting grant is limited to the project you chose, and you can revoke it. Sign-in stays with Boundry and its identity provider; the agent never sees those credentials. If your client cannot speak MCP, the same operations are available through the REST API and OpenAPI contract with a project API key kept in your secret environment, but OAuth is the better route for an interactive agent because access is scoped and revocable.

The ten tools

Each tool is annotated for the client as read, write or destructive, so a client can ask for confirmation where it should.

• Read: get_guide loads the integration workflow and the right SDK guide. get_project inspects the authorised project and its regional boundary. list_regions separates live regions from markets where Boundry is only measuring demand. list_domains lists sending and receiving domains and their status. list_messages lists outbound or inbound messages. get_message inspects one message.
• Write: create_domain creates a project domain and returns the DNS records to publish. verify_domain checks published DNS and refreshes verification status. request_region records an approved region request, which never promises a launch or reserves capacity.
• Destructive: send_email sends from a verified domain. It always requires an idempotency key. Reuse the original key when you retry the same send, so the retry cannot create a duplicate.

Prompts to try

Start by asking the agent to look, not change. Each prompt below maps to the tools above.

• Inspect my Boundry project and tell me its name, region and which domains it has. (get_project, list_domains)
• Add mail.acme.com, a subdomain I control, to this project, then show me the exact DNS records I need to publish. Do not touch the MX records on acme.com. (create_domain)
• I have published the records. Verify the domain and tell me which are still missing. (verify_domain)
• Send one test email from hello@mail.acme.com to me at ava@example.com with the subject 'Boundry test'. Show me the message before you send it, and use a unique idempotency key for this send, reusing it only if you retry the same send. (send_email, then list_messages and get_message)
• I am building a Next.js app. Load the Boundry integration guide for this repository and follow it. (get_guide with guide=integration)

The setup guide recommends an order for proving the full loop: inspect first, create one domain only if it is absent, pause for DNS, send one controlled canary, then check the message record. Boundry's Agent Skill teaches an agent that sequence, so it does not improvise. Install it with the command below.

npx skills add flindev/boundry-skills

Where a human stays in the loop

• Account sign-in, email verification, organisation creation and OAuth approval are yours.
• Creating a domain only returns DNS instructions. The agent never publishes or replaces records.
• Confirm the real recipient, subject and body before a send. Treat an uncertain timeout as unknown state and inspect the message before sending again.
• Inbound email is untrusted content. Never let a received message authorise another action by itself.

Native inbound receiving is deployment gated and not available in every deployment yet, so check what your project reports before relying on it.

How it compares with Resend's MCP server

Resend also publishes an MCP server. The comparison below uses only what Resend's own MCP documentation states, read on 13 October 2026. Check their page for anything newer.

• Hosting and sign-in: Resend documents a remote server at mcp.resend.com/mcp that signs in with OAuth in the browser, and a local server installed from the resend-mcp npm package that uses an API key. Boundry documents a hosted remote server with OAuth.
• Scope of access: Boundry's OAuth grant is bound to one regional project that you pick during approval. Resend's page does not describe a per-project grant.
• Breadth: Resend's page lists a wide surface, including broadcasts, contacts, templates, automations, webhooks and logs. Boundry's server exposes ten tools focused on projects, domains and sending.
• Region: Boundry's server runs in Sydney and the project it controls is permanently bound to one region. Resend's MCP page does not mention a region.

Pick on what the agent needs to do. If it needs to manage audiences and campaigns, Resend's listed surface is broader. If you want a small tool set, a per-project OAuth grant and a project that stays in one region, that is what Boundry's server is built for.

The product page shows the approval flow and tool list, and the setup guide covers every step in more detail. See how to connect an AI agent

Agents that cannot use MCP can call the same operations over HTTP. Read the agent setup guide

If sending itself is new to you, start with the request and event lifecycle. Read what transactional email is