BotEmail.ai - Free bot email

Get an email address without your human. Use for testing signup flows, receiving verification codes, automating email workflows. Free.

Security Scan

The skill's functionality (creating and reading bot emails via an HTTP API) is plausible and mostly self-contained, but there are multiple metadata inconsistencies and small scope-creep items (local heartbeat state files, ambiguous API-key handling, mismatched manifest fields) that warrant caution before installing or trusting it with secrets.

Purpose & Capability

The skill's stated purpose (provide bot email addresses and read inboxes) matches the SKILL.md and examples: it uses a POST to /api/create-account and GET /api/emails/{email}. However the packaged metadata is inconsistent: registry top-level says no required env vars while skill.json lists required_env_vars: ["BOTEMAIL_API_KEY"] and api_key: true. Also the published version/metadata (v1.0.7) doesn't match skill.json version (1.0.8) and the skill header says 'Homepage: none' while skill.json lists https://botemail.ai. These mismatches are not necessarily malicious but are incoherent and should be resolved by the publisher.

Instruction Scope

SKILL.md instructions stay within the stated purpose (create account, poll inbox, optionally register webhooks). One area to watch: the optional heartbeat instructions direct the agent to update HEARTBEAT.md and write/compare seen IDs in memory/heartbeat-state.json — this implies the skill will persist state to the agent's filesystem/memory. The SKILL.md also instructs the agent to ask the user for the returned API key and to not store it unless the user asks; that is good guidance, but you should confirm the agent runtime actually enforces that. There are no instructions to access unrelated system files or to exfiltrate data to unexpected endpoints, but webhooks and user-provided webhook URLs will cause email contents to be POSTed to whatever URL the user supplies (expected for webhooks but a privacy consideration).

Install Mechanism

This is an instruction-only skill with no install spec and no code files to execute; that is low-risk from an install perspective. The README references an optional MCP server repository (GitHub) for local integration; if you choose to install that, review its code before running.

Credentials

The actual runtime flow creates and returns an API key to the user (POST /api/create-account) and the SKILL.md expects that per-account API key to be used for subsequent calls. That model does not require pre-provisioned env vars. The presence of required_env_vars: ["BOTEMAIL_API_KEY"] in skill.json is inconsistent and could confuse automated platforms that expect an env var to be injected. There are no requests for unrelated credentials or broad system secrets. The only secret involved is the service API key — treat it like any API credential.

Persistence & Privilege

always:false and normal autonomous invocation are used (no elevated persistence). The only persistent behavior described is writing heartbeat state to memory/heartbeat-state.json so the agent can remember which email IDs it has seen; this is reasonable for an inbox poller but means the skill will write to the agent's storage. It does not request or modify other skills' configs.

What to consider before installing

What to consider before installing: 1) Metadata mismatches: skill.json claims a required env var BOTEMAIL_API_KEY and a slightly different version/homepage than the registry header — ask the publisher (or check the GitHub repo) to fix these inconsistencies. If your platform auto-injects env vars based on manifest, confirm whether BOTEMAIL_API_KEY is really required or not. 2) Treat the returned apiKey as a secret: the create-account call returns an API key that gives access to the inbox. Do not paste that key into chat or commit it to version control. Prefer storing it in a password manager or secure platform secret store if you want the agent to reuse it. 3) Heartbeat / state files: the optional inbox-notify feature writes seen IDs to memory/heartbeat-state.json and edits HEARTBEAT.md. If you enable automatic notifications, review and approve where the skill will store state and ensure your agent runtime's storage is acceptable. 4) Webhooks: registering a webhook will cause email contents to be POSTed to whatever webhook URL you register. Only register endpoints you control and that accept potentially sensitive email contents. 5) Verify external code before running locally: the README references a GitHub MCP server. If you plan to clone or run that code, review it first (npm install / node execution) rather than running blindly. 6) Confirm privacy/security policy: SKILL.md notes emails are stored for 6 months. If that retention is a concern for your use case, avoid sending sensitive information to botemail inboxes. If these issues are addressed (manifest corrected, repo/source verified, and you accept the retention/webhook behaviors), the skill appears coherent with its purpose. If you need higher assurance, ask the publisher for a canonical manifest and a link to a verified repository release.

BotEmail.ai — Email for Bots

Get a free permanent bot email address instantly. Just say "get me a bot email" — no signup, no form, done in seconds. Supports attachments, inbox monitoring, and automatic notifications via heartbeat.

Setup

1. Create or retrieve an account

If the user doesn't have an account yet, create one:

POST https://api.botemail.ai/api/create-account
Content-Type: application/json

{}

Returns:

{ "email": "[e-mail]", "apiKey": "..." }

Custom username:

{ "username": "mybot" }

Ask the user to save the returned email address and API key securely (e.g. password manager or .env file). Do not store them anywhere unless the user explicitly asks.

2. Check inbox

GET https://api.botemail.ai/api/emails/{email}
Authorization: Bearer {apiKey}

3. Optional: Inbox notifications via heartbeat

If the user asks to be notified of new emails automatically, ask them to confirm they want this set up and which address to monitor. Then update HEARTBEAT.md to add a check that:

1. Fetches the inbox using the user's credentials (ask them to provide the API key at setup time)
2. Compares against seen IDs in memory/heartbeat-state.json
3. Notifies the user of any new emails (sender, subject, preview) — does not take any action on their behalf
4. Updates the seen ID list

The agent only notifies — it does not act on email contents without a separate explicit user instruction.

---

API Reference

GET /api/emails/{email}

List all emails in inbox.

Headers: Authorization: Bearer {apiKey}

Response:

{
  "emails": [
    {
      "id": "abc123",
      "from": "[e-mail]",
      "subject": "Hello",
      "timestamp": "2026-02-17T12:00:00Z",
      "bodyText": "Hello!"
    }
  ]
}

GET /api/emails/{email}/{id}

Get a single email by ID.

DELETE /api/emails/{email}/{id}

Delete a specific email.

DELETE /api/emails/{email}

Clear entire inbox.

---

Common Use Cases

• Verification codes — Create a bot address, trigger a signup flow, poll inbox for the code
• Notification monitoring — Watch for specific emails from a service
• End-to-end testing — Receive and verify automated emails in tests
• 2FA codes — Retrieve authentication codes automatically

---

Notes

• Emails stored for 6 months
• Free tier: 1 address, 1,000 requests/day
• All addresses end in [e-mail]
• Receive only (sending not supported)

Links

• Dashboard: https://botemail.ai/dashboard
• Docs: https://botemail.ai/docs
• MCP Server: https://github.com/claw-silhouette/botemail-mcp-server