---
name: e2a-setup
description: "Use when a user wants to connect or authorize the e2a MCP server, select or create an agent inbox, verify first-run readiness, or set up a custom email domain. Guides native client OAuth, shared-domain onboarding, and confirmed DNS-provider assistance without changing application code."
---

# Set up e2a

## Boundaries

- This skill starts after the e2a plugin is installed; it cannot bootstrap the plugin that contains it.
- Do not change client configuration, create an inbox, or change DNS without the confirmation stated below. Use OAuth and never ask an interactive user for an API key.
- Do not change application code. Never send a test unless the user selects its recipient.

## MCP bootstrap

1. Inspect the current client's tool registry for e2a tools.
2. If absent, first check whether the plugin is disabled or needs a reload before offering manual registration; do not create a duplicate registration.
3. Only if registration is genuinely absent, explain the native flow from [clients.md](references/clients.md), confirm before a client-config write, then offer to register `https://api.e2a.dev/mcp`.
4. Complete the client's OAuth flow, reload or restart if required, then call the e2a MCP `whoami` tool — never Unix or shell `whoami`. Treat auth failures as reauthorization; preserve configuration for operational failures.

## Select or create the inbox

1. For agent scope, use the `agent_email` from `whoami`.
2. For account scope, call `list_agents`: honor an inbox named by the task, use the sole result, or ask the user to choose among several.
3. If none exists, defer inbox creation until the user chooses a shared or custom domain below.

## Choose shared or custom domain

Ask whether the user wants the recommended shared domain or a custom domain.

- **Shared:** offer an address on `agents.e2a.dev`, confirm the full address,
  then call `create_agent`.
- **Custom:** confirm ownership and branded-address intent, then follow
  [custom-domains.md](references/custom-domains.md). After verification and one
  user-driven post-verification `get_domain` capability read show the inbound
  and outbound state. If ready, ask for and show the complete branded address,
  obtain confirmation, then call `create_agent`. If not ready, report the
  precise resume step; do not poll.

Use a Cloudflare API MCP server when available for Cloudflare-hosted DNS. For GoDaddy, use the authenticated `gddy` path; the official GoDaddy MCP is read-only and cannot modify DNS.

Before any provider-assisted DNS write, show the complete proposed DNS diff and obtain one confirmation for the complete DNS diff.

## Verify readiness

After selecting or creating the inbox, call `list_messages` (pass its email for
account scope). This harmless read must succeed before readiness is claimed.
Offer a send test only after the user selects a recipient; otherwise do not send
one. Once the inbox read succeeds, resume the user's original request.

## Completion report

Report the MCP registration and OAuth state, credential scope, selected inbox, successful inbox read, and domain state. For a custom domain, report inbound verification and outbound branded-sending capability separately, including any pending DNS or propagation action.