Use Mittr from an AI agent (MCP)

Mittr speaks the Model Context Protocol (MCP). Any MCP-compatible agent — Claude, Claude Code, Cursor, OpenAI Agents, Google ADK, LangChain, CrewAI — can call Mittr as a set of tools to dispatch events for reliable delivery and inspect what happened.

The point: agents are good at deciding what to do, but firing an HTTP call and hoping it lands is fragile. When an agent dispatches an event through Mittr, it inherits the whole delivery pipeline — retries with backoff, dead-letter, and a full audit trail — so the action actually lands and you can see every attempt.

Create an API key in the dashboard under API keys. The key’s role gates what the tools can do — see Roles below.

Tools are annotated so MCP hosts can tell reads from writes — the read tools (get, list_*) carry a read-only hint, the writes (send, replay, create_endpoint) are marked additive (never destructive). With these, an agent can discover, send, inspect, replay, and even set up its own endpoint — the full loop without leaving the MCP surface.

Claude Code supports remote HTTP MCP servers directly:

claude mcp add --transport http mittr https://app.mittr.io/mcp \
  --header "Authorization: Bearer mtr_your_key"

Clients configured through a JSON file connect via the mcp-remote bridge:

{
  "mcpServers": {
    "mittr": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://app.mittr.io/mcp",
        "--header",
        "Authorization: Bearer ${MITTR_API_KEY}"
      ],
      "env": { "MITTR_API_KEY": "mtr_your_key" }
    }
  }
}

Newer clients can connect to a remote Streamable-HTTP server directly (URL plus headers) without the bridge — check your client’s MCP docs, and if it supports remote servers, point it at the URL above with the Authorization header.

Building an agent programmatically rather than in an interactive client? Anthropic’s Messages API can connect to Mittr’s MCP server for you — pass the URL and your Mittr key, and Claude discovers and calls the tools itself. No per-tool wiring.

import Anthropic from "@anthropic-ai/sdk";

const claude = new Anthropic(); // reads ANTHROPIC_API_KEY

const message = await claude.beta.messages.create({
  model: "claude-opus-4-8",
  max_tokens: 1024,
  betas: ["mcp-client-2025-11-20"],
  mcp_servers: [{
    type: "url",
    name: "mittr",
    url: "https://app.mittr.io/mcp",
    authorization_token: process.env.MITTR_API_KEY, // mtr_...
  }],
  tools: [{ type: "mcp_toolset", mcp_server_name: "mittr" }],
  messages: [{
    role: "user",
    content: "Send an order.created event through Mittr, " +
             "then tell me if it was queued for delivery.",
  }],
});

The same shape in Python:

from anthropic import Anthropic
import os

claude = Anthropic()  # reads ANTHROPIC_API_KEY

message = claude.beta.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    betas=["mcp-client-2025-11-20"],
    mcp_servers=[{
        "type": "url",
        "name": "mittr",
        "url": "https://app.mittr.io/mcp",
        "authorization_token": os.environ["MITTR_API_KEY"],  # mtr_...
    }],
    tools=[{"type": "mcp_toolset", "mcp_server_name": "mittr"}],
    messages=[{
        "role": "user",
        "content": "Send an order.created event through Mittr, "
                   "then tell me if it was queued for delivery.",
    }],
)

Other frameworks (OpenAI Agents SDK, LangChain, CrewAI) reach the same remote MCP server through their own MCP-client integrations — the URL and Bearer auth above don’t change.

Once connected, the agent calls the tools directly. After taking an action it needs to notify another system about — say, “order 1234 shipped” — it calls mittr_send_event with a destination (or an eventType that fans out to your configured endpoints) and a JSON payload. Mittr queues it, delivers it with retries, and returns the event ID. The agent can then call mittr_get_event or mittr_list_attempts to confirm it landed or see why it didn’t, and mittr_replay_event to retry a failed one.

mittr_send_event accepts two optional fields that tie events back to the run that produced them:

• agentRunId — a correlation key shared by every event from one run.
• agentMetadata — a free-form JSON object (framework, step, tool name, …).

Pass them and every event from a run carries the same handle, so you can trace what an agent dispatched on a given run. Ordinary webhook traffic never sets these.

mittr_send_event accepts an optional idempotencyKey. Pass a stable key — for example, derived from the agent run and step — and repeated calls are deduplicated, which makes the tool safe to retry. Omit it and Mittr generates one per call.

The tools honor the same roles as the rest of Mittr, read from your API key:

• Editor or higher — mittr_send_event, mittr_replay_event, mittr_create_endpoint.
• Viewer or higher — mittr_get_event, mittr_list_events, mittr_list_attempts, mittr_list_endpoints.

A read-only (viewer) key can inspect deliveries but can’t send or replay. Every event an agent dispatches is scoped to your workspace — an agent can never read or touch another tenant’s events.