[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8,"_9":10},"actionData","errors","root",{"_114":115},"routes/modules.$creator.$moduleId",{"_14":15,"_16":17,"_18":19,"_20":21},"routes/modules.$creator.$moduleId.endpoints",{"_11":12,"_13":-5},"error","Module '@mnexa-ai/e2a' is not configured","tools","module",{"_20":22,"_23":24,"_25":26,"_27":28,"_29":30,"_31":32,"_33":26,"_34":-5,"_35":36,"_37":-5,"_38":-5,"_39":40,"_41":42,"_43":44,"_45":46,"_47":48,"_49":50,"_51":52,"_53":54,"_55":48,"_56":57,"_58":59,"_60":-5,"_61":-5,"_62":-5,"_63":-5,"_64":65,"_66":67,"_68":69,"_70":71,"_72":73,"_74":-5,"_75":-5,"_76":-5,"_77":48,"_78":-5,"_79":80,"_81":82,"_83":84,"_85":86,"_87":88,"_89":90,"_91":92},"apiUrl","https://odel.app/api","creator","mnexa-ai","moduleId","e2a","@mnexa-ai/e2a","displayName","e2a — email for AI agents","tagline","Authenticated email gateway for AI agents — per-agent inboxes, HITL approval, SPF/DKIM verified.","iconKey","https://avatars.githubusercontent.com/u/254367252?v=4","category","communication","status","published","metaDescription","metaKeywords","deploymentType","external","workerName","bindingName","mcpConfig","{\"url\":\"https://mcp.e2a.dev/mcp\",\"transport\":\"streamable-http\",\"authType\":\"bearer\"}","pricingModel","free","creatorUserId","system:external-import","createdAt",1781363360000,"updatedAt",1781499534000,"sourceRegistry","official-mcp-registry","sourceUrl","https://registry.modelcontextprotocol.io/v0/servers?search=io.github.Mnexa-AI%2Fmcp-server","sourceVerified",true,"importedAt","upstreamStars",157,"upstreamUpdatedAt",1781495969000,"detectedTransport","detectedAuthType","probeStatus","lastProbedAt","githubRepoUrl","https://github.com/Mnexa-AI/e2a","githubRepoFullName","Mnexa-AI/e2a","releaseId","ext-mnexa-ai-e2a","version","0.3.2","descriptionMarkdown","# e2a — Email for AI agents\n\n[![Tests](https://github.com/Mnexa-AI/e2a/actions/workflows/test.yml/badge.svg?branch=main)](https://github.com/Mnexa-AI/e2a/actions/workflows/test.yml)\n[![Build image](https://github.com/Mnexa-AI/e2a/actions/workflows/build-image.yml/badge.svg?branch=main)](https://github.com/Mnexa-AI/e2a/actions/workflows/build-image.yml)\n[![License](https://img.shields.io/github/license/Mnexa-AI/e2a)](LICENSE)\n[![npm @e2a/sdk](https://img.shields.io/npm/v/%40e2a%2Fsdk?label=%40e2a%2Fsdk)](https://www.npmjs.com/package/@e2a/sdk)\n[![PyPI e2a](https://img.shields.io/pypi/v/e2a)](https://pypi.org/project/e2a/)\n\n $\"e2a$ \n\nAuthenticated email gateway for AI agents. Receive emails as webhooks or via WebSocket, send emails through an HTTP API, and verify the identity of every sender — humans and other agents alike.\n\n- **Authenticated transport** — SPF/DKIM verified on inbound; HMAC-signed `X-E2A-Auth-*` headers on every delivery\n- **Two delivery modes** — webhook (cloud agents) or WebSocket (local agents, no public URL needed)\n- **Outbound API** — agents send to other agents (SMTP relay) or humans (upstream SMTP, e.g. SES, Resend)\n- **Human in the loop** — opt-in approval gate that holds outbound mail until a reviewer approves via dashboard, magic-link email, or CLI\n- **CLI + SDKs** — TypeScript and Python SDKs, plus a `e2a` CLI for everyday agent ops\n\n

\n\n## Use it\n\nYou can either use the hosted instance or self-host.\n\n- **Hosted** — sign up at [e2a.dev](https://e2a.dev). Includes the shared `agents.e2a.dev` domain for instant slug-based onboarding (no DNS setup), a dashboard, and managed deliverability.\n- **Self-host** — see [Quickstart](#quickstart) and [Deployment](#deployment). Every feature works the same; the shared-domain slug shortcut just needs you to point a mail domain at your relay and set `shared_domain` in `config.yaml`.\n\n## How it works\n\n```\nHuman (Gmail/Outlook)\n │\n ▼ SMTP\n┌──────────────┐\n│ e2a relay │ ← MX record for your agent domain points here\n│ │\n│ 1. Verify │ ← SPF/DKIM check on the inbound message\n│ 2. Sign │ ← HMAC-signed X-E2A-Auth-* headers\n│ 3. Deliver │\n└──────────────┘\n │\n ├──▶ Cloud-mode agent: HTTPS webhook POST\n │\n └──▶ Local-mode agent: store + WebSocket notification\n │\n ▼\n e2a listen (CLI) or client.listen() (SDK)\n```\n\nInbound flow: SMTP → SPF/DKIM check → agent lookup → HMAC-sign auth headers → webhook or WebSocket delivery.\n\nOutbound flow: API call → optional HITL hold → SMTP relay (agent-to-agent) or upstream SMTP (agent-to-human).\n\n## Quickstart\n\nRequires Docker.\n\n```bash\ngit clone https://github.com/Mnexa-AI/e2a.git\ncd e2a\ndocker compose up -d\n```\n\nPostgres comes up first (migrations run automatically), then the API server, then the dashboard. Three host ports:\n\n- `:8080` — HTTP API\n- `:2525` — SMTP relay\n- `:3000` — Dashboard (Caddy + Next.js, proxies `/api/*` to the API server)\n\nHealth check:\n\n```bash\ncurl http://localhost:8080/api/health\n# {\"status\":\"ok\"}\n```\n\nOpen `http://localhost:3000` in a browser to view the dashboard. Sign-in requires Google OAuth credentials configured in `config.yaml`; for an API-only smoke test you can skip the dashboard and use the bootstrap flow below.\n\nCreate your first user and API key (no OAuth required):\n\n```bash\ndocker compose exec e2a e2a -config /etc/e2a/config.yaml -bootstrap-email you@example.com\n# User: you@example.com (id=...)\n# API key: e2a_...\n```\n\nSave the key — it's only shown once. Register an agent and confirm it works:\n\n```bash\nKEY=e2a_...\ncurl -X POST http://localhost:8080/api/v1/agents \\\n -H \"Authorization: Bearer $KEY\" -H \"Content-Type: application/json\" \\\n -d '{\"slug\":\"my-bot\",\"agent_mode\":\"local\"}'\n\ncurl -H \"Authorization: Bearer $KEY\" http://localhost:8080/api/v1/agents\n```\n\nTo receive real inbound mail, point a domain's MX record at your relay host:\n\n- **A**: `your-domain.com` → server IP\n- **MX**: `your-domain.com` → `your-domain.com` (priority 10)\n\nThen register and verify the domain through the API (see [Domains](#domains)). Without DNS, the API still works for testing — but external email won't reach your relay.\n\n> **Upgrades and migrations.** The compose file mounts `migrations/` into Postgres' init directory, which only runs on first start (when the data volume is empty). When you upgrade e2a and pull a new schema migration, you must apply it manually:\n> ```bash\n> docker compose exec postgres sh -c \\\n> 'for f in /docker-entrypoint-initdb.d/*.sql; do psql -U e2a -d e2a -f \"$f\" -v ON_ERROR_STOP=1; done'\n> ```\n> The migration files are idempotent (`CREATE TABLE IF NOT EXISTS`, `ALTER TABLE … ADD COLUMN IF NOT EXISTS`) so re-running them is safe.\n\n## Concepts\n\n### Agent modes\n\nAgents operate in one of two modes, set via `agent_mode` at registration:\n\n| Mode | Delivery | Public URL needed? |\n|------|----------|---------------------|\n| `cloud` (default) | HTTPS webhook POST to `webhook_url` | Yes |\n| `local` | WebSocket notification + REST fetch | No |\n\nLocal-mode agents accumulate \"unread\" messages while disconnected; on reconnect, the server drains them as WebSocket notifications. Both modes can also poll messages via the REST API.\n\n### Auth headers\n\nEvery email delivered through e2a (webhook or WebSocket-fetched) carries signed headers:\n\n| Header | Description |\n|--------|-------------|\n| `X-E2A-Auth-Verified` | `true` if domain-level auth (SPF or DKIM) passed |\n| `X-E2A-Auth-Sender` | Verified sender email or agent domain |\n| `X-E2A-Auth-Entity-Type` | `human` or `agent` |\n| `X-E2A-Auth-Domain-Check` | SPF/DKIM result string (e.g. `spf=pass; dkim=none`) |\n| `X-E2A-Auth-Delegation` | `agent={id};human={id}` if an active delegation binding exists |\n| `X-E2A-Auth-Timestamp` | RFC3339 timestamp |\n| `X-E2A-Auth-Message-Id` | Internal e2a message ID this delivery is for |\n| `X-E2A-Auth-Body-Hash` | Hex SHA-256 of the raw message bytes |\n| `X-E2A-Auth-Signature` | HMAC-SHA256 over a canonical string of the above |\n\nThe signature covers:\n\n```\nverified \\n sender \\n entity_type \\n domain_check \\n delegation \\n timestamp \\n message_id \\n body_hash\n```\n\nThe MAC binds to **both** `message_id` and a SHA-256 of the raw message body. Substituting either invalidates the signature, so an attacker who captures one delivery cannot replay the auth claim on a different message or under a modified body.\n\n#### Verifying the signature\n\nThe `X-E2A-Auth-Verified` field is the *server's claim* — anyone who can reach your webhook URL can set it. To make a security decision, **verify the signature** with one of your account's signing secrets (manage them in the dashboard's **Webhook secrets** page, or via `/api/v1/users/me/signing-secrets`).\n\nThe SDKs gate field access behind verification by default — accessing `email.sender`, `email.subject`, etc. on an unverified webhook payload raises `UnverifiedEmailError`, so you can't accidentally trust attacker-controllable fields. The one-call shortcut:\n\n```python\nfrom e2a.v1 import E2AClient\nclient = E2AClient() # reads E2A_API_KEY\nemail = client.parse_webhook(request_body) # reads E2A_WEBHOOK_SECRET; raises on bad signature\n# safe to use email.sender, email.subject, …\n```\n\n```typescript\nimport { E2AClient } from \"@e2a/sdk\";\nconst email = await client.parseWebhook(req.body); // throws on bad signature\n```\n\nBoth forms read the secret from `E2A_WEBHOOK_SECRET` by default; pass it explicitly as a second argument if you keep it elsewhere. Under the hood the verify step checks, in order: body_hash matches the raw message bytes, HMAC matches the canonical auth string, and timestamp is within a 5-minute replay window.\n\nEmails returned by `client.get_message(...)` are pre-verified — the bearer token already authenticated the channel — so field access works directly without a verify step. (Listing endpoints like `get_messages` / `listMessages` return lightweight summaries, not `InboundEmail`, so the gate doesn't apply.)\n\n### Conversation threading\n\nBoth `send` and `reply` accept an opaque `conversation_id`. e2a propagates it to the recipient on delivery via `payload.conversation_id`, surfaced in this priority order:\n\n1. **`X-E2A-Conversation-Id` header** — authoritative for e2a-to-e2a traffic. Only honored when the SMTP envelope `MAIL FROM` originates from this relay, so external senders cannot forge it.\n2. **`In-Reply-To` / `References` lookup** — standard RFC 5322 threading, scoped to the recipient agent's own messages. Covers humans replying from Gmail/Outlook.\n\nFirst contact from a human arrives with `conversation_id: null` — the agent should assign a new id before replying.\n\n### Human in the loop (HITL)\n\nWhen an agent has HITL enabled, outbound `send` and `reply` calls do **not** dispatch immediately. The message is stored with status `pending_approval` and the API returns HTTP `202 Accepted`. A reviewer must approve it before delivery; otherwise, after a configurable TTL, the message expires into `expired_approved` (auto-sent) or `expired_rejected` (discarded), depending on the agent's `hitl_expiration_action`.\n\nReviewers can approve or reject via:\n\n- **Dashboard / API** — `POST /api/v1/messages/{id}/approve` or `/reject`\n- **Magic-link email** — sent automatically when HITL fires; one-click `GET /api/v1/approve?token=…` and `/reject?token=…` URLs (requires `E2A_PUBLIC_URL` and outbound SMTP configured)\n- **CLI** — `e2a pending` lists held messages\n\nEnable HITL on an agent via `PUT /api/v1/agents/{email}` with `hitl_enabled: true` and an optional `hitl_expiration_action` and TTL.\n\n## API\n\nAll endpoints are under `/api/v1` unless noted. Auth is `Authorization: Bearer ` except for `/api/health`, `/api/v1/info`, `/api/feedback`, and the HITL magic-link routes. Path parameters containing `@` (agent emails) must be URL-encoded.\n\nThe surface covers domain registration + verification, agent CRUD, inbound/outbound messages, HITL approve/reject (API key or signed magic-link token), GDPR-style export and deletion, and a WebSocket channel for local-mode agents.\n\nSee [docs/api.md](https://github.com/Mnexa-AI/e2a/blob/main/docs/api.md) for the full endpoint reference, or [`web/public/openapi.yaml`](https://github.com/Mnexa-AI/e2a/blob/main/web/public/openapi.yaml) for the machine-readable spec.\n\n## CLI\n\n```bash\nnpm install -g @e2a/cli\ne2a login\n```\n\n| Command | Description |\n|---------|-------------|\n| `e2a agents register ` | Register `@`. The deployment's shared domain is auto-discovered after `e2a login` and cached in `~/.e2a/config.json`. |\n| `e2a agents list` | List your agents |\n| `e2a agents update ` | Update an agent (webhook URL, mode, HITL) |\n| `e2a agents delete ` | Delete an agent |\n| `e2a listen` | Listen for emails over WebSocket (real-time) |\n| `e2a listen --json` | Output one full message JSON per line |\n| `e2a listen --forward ` | Forward each message as HTTP POST to a local URL |\n| `e2a inbox` | List recent messages |\n| `e2a read ` | Read a message |\n| `e2a reply --body …` | Reply to a message |\n| `e2a send --to … --subject … --body …` | Send an email |\n| `e2a pending` | List HITL messages awaiting approval |\n| `e2a config` | View or update CLI config |\n\nThe `listen --forward` mode also supports OpenAI Responses API forwarding via `--forward-token`, which formats each inbound email as a Responses payload and auto-replies with the model's output:\n\n```bash\ne2a listen --forward http://localhost:18789/v1/responses --forward-token \n```\n\nSee [cli/README.md](https://github.com/Mnexa-AI/e2a/blob/main/cli/README.md) for full reference.\n\n## SDKs\n\n### Python\n\n```bash\npip install e2a # webhook mode\npip install 'e2a[ws]' # adds WebSocket support\n```\n\n```python\nfrom e2a.v1 import E2AClient\n\nclient = E2AClient() # reads E2A_API_KEY\nemail = client.parse_webhook(request_body) # parse + HMAC-verify (reads E2A_WEBHOOK_SECRET)\nprint(email.sender, email.subject)\nemail.reply(\"Got it!\", conversation_id=\"conv_123\")\n```\n\nWebSocket (local agents):\n\n```python\nfrom e2a.v1 import AsyncE2AClient\n\nasync with AsyncE2AClient(api_key=\"e2a_…\") as client:\n async for notif in client.listen(\"bot@your-domain.com\"):\n # notif is lightweight metadata — fetch the body when you want it\n email = await client.get_message(notif.message_id)\n await email.reply(\"Got it!\")\n```\n\nSee [sdks/python/README.md](https://github.com/Mnexa-AI/e2a/blob/main/sdks/python/README.md).\n\n### TypeScript\n\n```bash\nnpm install @e2a/sdk\n```\n\nSee [sdks/typescript/README.md](https://github.com/Mnexa-AI/e2a/blob/main/sdks/typescript/README.md).\n\n## Deployment\n\nThree audiences each configure a different surface:\n\n| Audience | What they configure | Where |\n|---|---|---|\n| **Server operator** — runs the Go backend | DB, signing key, SMTP, OAuth, optional shared domain | `config.yaml` + `E2A_*` env |\n| **CLI / SDK user** — calls the API from their machine | Just the deployment URL (and login) | `E2A_URL` + `e2a login` |\n| **Web dashboard deployer** — hosts the Next.js dashboard | Public site URL + branding | `NEXT_PUBLIC_*` build-time env |\n\nThe Go binary runs on any container host; storage is plain Postgres 14+; outbound mail goes through standard SMTP. Most workers coordinate via `SELECT … FOR UPDATE SKIP LOCKED`, so multi-replica is safe — the two real horizontal-scaling caveats are in-memory WebSocket fan-out and per-process rate limits.\n\nSee [docs/deployment.md](https://github.com/Mnexa-AI/e2a/blob/main/docs/deployment.md) for the full env-var reference, shared-domain DNS setup, and scaling/limitation notes.\n\n## Security\n\n- **Identity** — agent registration requires DNS TXT verification of domain ownership (custom domains)\n- **Domain auth** — SPF and DKIM checked on every inbound message\n- **Header signatures** — HMAC-SHA256 over canonical auth-header string; reject if timestamp older than 5 minutes\n- **SSRF protection** — webhook URLs must be HTTPS (in production), resolve to public IPs, use domain names (no raw IPs, no private/loopback ranges)\n- **OAuth CSRF** — single-use, time-limited nonce in the `state` parameter\n- **Production mode** (`E2A_ENV=production`) enforces the above where development mode is more permissive\n\nReport security issues privately — see [SECURITY.md](https://github.com/Mnexa-AI/e2a/blob/main/SECURITY.md) for the disclosure process and what's in scope. **Do not file public GitHub issues for vulnerabilities.**\n\n## Data handling\n\nMessage envelopes and inbound bodies live in Postgres for 30 days by default; outbound bodies are scrubbed at terminal HITL transition; API keys are stored as hashes; attachments go in JSONB rows (no S3/GCS). Application logs include sender/recipient addresses (standard MTA practice) but never bodies, attachments, raw keys, or HMAC secrets. Users can self-export (`GET /users/me/export`) and self-delete (`DELETE /users/me`) for GDPR Art. 15 / Art. 17 / CCPA.\n\nSee [docs/data-handling.md](https://github.com/Mnexa-AI/e2a/blob/main/docs/data-handling.md) for the full retention table, log fields, user-rights endpoints, and the operator-side responsibilities (backups, TLS, at-rest encryption, log redaction, compliance).\n\n## FAQ\n\n### Why not just use SendGrid / Resend / Postmark for sending and their inbound parsing for receiving?\n\nFour things that aren't possible to bolt on without significant rework:\n\n1. **Local-mode agents with no public URL.** Agents authenticate with their API key, open a WebSocket to `/api/v1/agents/{email}/ws`, and inbound mail arrives as JSON over that connection — no webhook URL, no ngrok, no port forward. Useful for agents on developer laptops, edge devices, or behind corporate firewalls. SendGrid/Resend are webhook-only by design. A polling REST API is available as fallback.\n\n2. **Conversation threading on every reply.** Whether a human replies from Gmail or another e2a agent replies via the API, the inbound message arrives at the agent with a stable `conversation_id` already mapped to the original thread. For human senders, the relay does standard `In-Reply-To` / `References` lookup scoped to the recipient agent's own messages. For agent-to-agent where both sides are on e2a, it also trusts an `X-E2A-Conversation-Id` header it controls (envelope-from is its own domain), which survives clients that rewrite threading headers. SendGrid/Resend never see inbound mail — they aren't receivers — so neither path is available without you building both yourself.\n\n3. **Slug provisioning on a shared domain.** Operators set `shared_domain: agents.e2a.dev` and users `POST {\"slug\": \"my-agent\"}` to immediately get `my-agent@agents.e2a.dev` with no DNS configuration. Possible because e2a *is* the SMTP relay claiming the domain — Resend / SendGrid are providers, not platforms, and can't multi-tenant a shared address space without you running the relay yourself.\n\n4. **Built-in HITL hold + auto-expiration.** A per-agent `hitl_enabled` flag holds outbound mail in `pending_approval` state. Reviewers approve via dashboard, magic-link email, or CLI; a background worker auto-acts on expired holds based on `hitl_expiration_action` config. Magic-link tokens are HMAC-encoded — stateless, no session backend. With Resend / SendGrid you'd hold the message in your own DB, build the timer, the approval UI, and the stateless review tokens.\n\nYou can absolutely use SES / Resend / SendGrid as e2a's *outbound* SMTP for delivery to humans — that's what `outbound_smtp` in `config.yaml` is for. They complement e2a; they don't replace the inbound receiver, agent abstraction, or any of the layers above transport.\n\n### Why email at all? Why not webhooks, gRPC, or MCP between agents?\n\nEmail is the only protocol where every human already has an address and a working client. Webhooks / gRPC / MCP are great inside systems you control, but they don't reach Gmail or Outlook. If you want an agent that talks to humans (or to *other organizations'* agents) without forcing everyone to install a new client, email is the universal substrate.\n\ne2a doesn't replace webhooks — agents *receive* email via webhooks. It bridges email's universal addressability to the structured-data world the agent code already lives in.\n\n### What stops an attacker from spoofing the `X-E2A-Auth-*` headers?\n\nThe relay strips any incoming `X-E2A-Auth-*` from inbound messages and re-signs with HMAC-SHA256 against `signing.hmac_secret`. The signed canonical binds `Sender + Verified + Body-Hash + Message-Id` together — replay attempts, body swaps, and sender-only forgery all fail validation. Each delivery is bound to *that specific message body*, not just the sender claim, so a captured `(headers, signature)` tuple can't be lifted onto a different message.\n\nReceivers verify with the SDK — `client.parse_webhook(body)` / `client.parseWebhook(body)` does parse + HMAC verify in one call (or `email.verify_signature(secret)` if you parsed first). No API call back to e2a needed. If a signing secret leaks, rotate it via the dashboard and old signatures stop verifying. If it's *stolen from the relay*, the attacker has bigger access than headers anyway.\n\n### Isn't this just SMTP with extra steps?\n\nYes — and the extra steps are the point. Concretely:\n\n- SPF/DKIM verdict normalization so receivers don't reimplement domain auth\n- HMAC-signed delivery contract binding sender, body hash, message ID, and verification status\n- WebSocket transport for agents without public URLs\n- HITL approval flow with auto-expiration and stateless magic-link review\n- Conversation-Id threading that survives the email ↔ structured-data boundary\n- Slug-based agent provisioning on a shared domain\n- Per-agent webhook routing, rate limits, and HITL config\n\nBuilding those on top of bare Postfix is a real project. e2a is that project, open source.\n\n### How does this compare to running Postfix or Postal myself?\n\nIf you want a full MTA, run an MTA — Postfix and Postal are great. e2a isn't trying to replace them at the SMTP transport level (it uses `go-smtp` for receiving and dial-out for sending). The value is the layer above transport: the auth model, agent abstraction, signed delivery contract, retry policy for webhook failures, HITL approval flow, SDKs and CLI. If you're comfortable operating an MTA and only need email plumbing, e2a may be more than you want. If you want the agent abstraction and signed identity layer prebuilt, that's what this is.\n\n### Why open source if there's a hosted version?\n\nTwo reasons:\n\n1. **Auditability.** Identity infrastructure for your agents should be readable code, not a vendor black box. You can verify the cosign signature on `ghcr.io/mnexa-ai/e2a`, reproduce the build, and confirm what's actually running.\n2. **Self-host as a real option.** The hosted instance at e2a.dev runs the same `ghcr.io/mnexa-ai/e2a` image you can pull right now. Convenience features on the hosted side (the shared `agents.e2a.dev` domain, managed deliverability) are config + DNS, not closed-source extras.\n\nPricing for the hosted version isn't enabled yet. When it lands, it'll be opt-in via env var and the OSS code path stays unchanged.\n\n## Development\n\n```bash\nmake build # go build -o bin/e2a ./cmd/e2a\nmake run # build + run (cp config.example.yaml config.yaml first)\nmake test # all Go tests (needs Postgres on :5433)\nmake test-unit # Go unit tests only (no DB)\nmake test-integration # integration tests (needs Postgres)\nmake test-e2e # e2e tests (needs Postgres)\nmake docker-up # start local Postgres via docker compose\nmake migrate # apply SQL migrations to local DB\n```\n\nSee [CLAUDE.md](https://github.com/Mnexa-AI/e2a/blob/main/CLAUDE.md) for the full developer guide (architecture, tests, code generation, conventions).\n\n## Contributing\n\nBy submitting a pull request, you certify the [Developer Certificate of Origin](https://developercertificate.org/) for your contribution. Sign your commits with `git commit -s`.\n\n## License\n\nApache 2.0 — see [LICENSE](https://github.com/Mnexa-AI/e2a/blob/main/LICENSE) and [NOTICE](https://github.com/Mnexa-AI/e2a/blob/main/NOTICE).\n","changelogMarkdown","videoKey","requiredSecretsJson","publishedAt","priceCents","trialDays",0,"categoryDisplayName","Communication","upstream",{"_95":96,"_97":98,"_99":100,"_101":102,"_103":104},"requiredSecrets",[],"tags",[],"assets",[],"stats",{"_93":80,"_94":80},"ratingAvg","reviewCount","topics",[105,106,107,108,109,110,111,112,113],"license","Apache-2.0","language","Go","registryName","io.github.Mnexa-AI/mcp-server","homepage","https://e2a.dev","ai-agents","email","email-api","go","hitl","human-in-the-loop","mail-gateway","smtp","webhook","ENV",{"_116":117,"_118":119,"_120":121},"ENVIRONMENT","production","TURNSTILE_SITE_KEY","0x4AAAAAAB8-rEI2gNDf_QhU","SENTRY_DSN","https://45fd1229f78089d5c3ee78be128030e1@o4510583261757440.ingest.de.sentry.io/4510584253448272"]