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 emitdCopy Anchor Link

• 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 planCopy Anchor Link

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.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": { "name": "send_email", "arguments": { "to": ["ada@lovelace.io"], "subject": "Hi" } }
}

Connected assistants get six tools:

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 yourselfCopy Anchor Link

Prefer your own tool definitions? Exposing emitd to an agent is just a schema over one fetch — no SDK required:

{
  "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" }
    }
  }
}