AI agents & MCP

emitd is built the way agents like to work: a native MCP endpoint, one HTTPS call, a machine-readable spec, and predictable typed errors — no SDK or language runtime required.

Why agents get along with emitd

• One endpoint, one shape. POST /v1/email with a JSON body — trivial to express as a tool definition.
• Machine-readable. The full OpenAPI spec lets an agent (or a codegen step) discover every field and error without scraping HTML, and llms.txt is a compact plain-text reference built for model context windows.
• Deterministic errors. Stable snake_case codes an agent can branch on, instead of prose it has to interpret.

MCP — built in, on every plan

emitd hosts a native Model Context Protocol server at POST /mcp on the API origin. It speaks stateless JSON-RPC 2.0 and authenticates with the same Authorization: Bearer API key as the REST API — no separate server to run, nothing to install.

Connected assistants get six tools:

• send_email — send through the same quota, suppression, and verified-domain pipeline as POST /v1/email
• list_messages / get_message — check whether a send was delivered, opened, or bounced
• list_domains — see which sending domains are verified
• list_templates — discover template aliases to send with
• get_deliverability — bounce and complaint health at a glance

Every tool runs inside your account's guardrails — quotas, rate limits, and per-key permissions apply exactly as they do to the HTTPS API, so an agent can't out-send your plan.

Wrapping the send as a tool yourself

Prefer your own tool definitions? Exposing emitd to an agent is just a schema over one fetch — no SDK required. Here's a send tool an LLM can call directly:

// A minimal "send_email" tool an agent can call — no SDK, just fetch.
{
  "name": "emitd_send_email",
  "description": "Send a transactional email via emitd.",
  "input_schema": {
    "type": "object",
    "required": ["to", "subject"],
    "properties": {
      "to": { "type": "array", "items": { "type": "string" } },
      "subject": { "type": "string" },
      "html_body": { "type": "string" }
    }
  }
}