# Mailpark

> One API for every email a software product sends: transactional (password resets, receipts, alerts)
> and marketing (onboarding sequences, product updates). Built on Amazon SES. Made for founders who
> build with AI coding agents. Customers pay only for emails sent.

This file is for AI agents. It covers auth, every endpoint, one complete example per job, the
safety rules, the error format, and how to connect the MCP server.

Local dev: API http://localhost:4000, web app http://localhost:3000, MCP http://localhost:4000/mcp.
Dev test key: sk_test_dev_acme (account "Acme", acc_demo).

---------------------------------------------------------------------------------------------------
## 1. Fastest path ("set up my emails")

1. Connect MCP (section 9) and call `get_started`. It returns the setup checklist and the next step.
2. `add_essential_templates` with the product's name, logo and color (8 ready-made templates).
3. Install the SDK in the app (`npm install mailpark`), set MAILPARK_API_KEY=sk_test_… in .env, and
   wire sends into the app's code (password reset, verify email, receipt, invite …).
4. Test: `send_test_email` / `read_test_inbox` (or `mailpark test password-reset --to me`, `mailpark inbox`).
5. Onboarding: record `signed_up` events from the app, `create_sequence`, `simulate_sequence`,
   `set_sequence_status on`.
6. Domain: `setup_domain`, give the founder the DNS records (or the one-click setup link, when their DNS provider
   supports Domain Connect), `check_domain` until verified.
7. The founder goes live in the web app (humans only). Then swap in the live key.

CLI equivalent: `mailpark login --key sk_test_… --email you@x.com`, `mailpark init`,
`mailpark templates push`, `mailpark test <template> --to me`, `mailpark inbox`, `mailpark logs`,
`mailpark explain <message_id>`, `mailpark sequences simulate <id>`, `mailpark health`.
Every CLI command accepts `--json`.

---------------------------------------------------------------------------------------------------
## 2. Auth, test vs live

- Header: `Authorization: Bearer <api_key>`. JSON in and out, snake_case fields, ISO-8601 UTC times, money in cents.
- `sk_test_…` keys NEVER send real email. Messages are rendered, logged, marked delivered (simulated)
  and captured in the test inbox (GET /v1/test-inbox). Use test keys for all development and agents.
- `sk_live_…` keys send real email, only after a human has "gone live" in the web app (requires a
  verified domain).
- Keys have scopes: emails:send, contacts:write, events:write, templates:write, broadcasts:draft,
  sequences:write, sequences:activate, webhooks:write, logs:read, domains:write.
  Default agent key: everything except sequences:activate on live.
- Every action taken with a key is written to the audit log (GET /v1/activity) with the key's name.

---------------------------------------------------------------------------------------------------
## 3. Conventions

- Writes accept `Idempotency-Key: <string>`. Same key + same body = same response, no duplicate send.
  Always set one when retrying (the SDK sets one automatically; pass your own to make retries safe
  across processes, e.g. `password-reset:<user_id>:<token>`).
- Lists: `{ "data": [...], "next_cursor": string | null }`. Query `?limit=` (default 50), `?cursor=`.
- Success responses may include `next_steps: string[]`. Follow them.
- Rate-limit headers: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset.

Error format (any 4xx/5xx):

  { "error": { "code": "domain_not_verified",
               "message": "What happened, in plain words.",
               "fix": "What to do next.",
               "docs": "https://docs.mailpark.io/errors/domain_not_verified" } }

`validation_failed` (422) adds `error.fields: { "<path>": "<message>" }`.
Codes: unauthorized (401), forbidden / missing_scope / humans_only (403), not_found (404),
validation_failed (422), rate_limited (429), domain_not_verified, suppressed, daily_limit_reached,
spending_cap_reached, account_paused, marketing_paused, test_mode_only.
Always read `fix` and act on it; do not blindly retry 4xx errors.

---------------------------------------------------------------------------------------------------
## 4. Transactional vs marketing

transactional: triggered by one user's action (reset, verify, receipt, alert, invite). Sent from
  mail.<domain>, priority lane, no unsubscribe link, never blocked by marketing limits. One recipient
  per email. Do NOT use it for promotions (misuse is detected and reclassified).
marketing: updates, tips, onboarding, announcements. Sent from updates.<domain>, always has an
  unsubscribe link and List-Unsubscribe header, respects topic unsubscribes, trust-level daily limits
  and the spending cap. Opens/clicks tracked.

Essential templates (all accept brand data, work on mobile and dark mode):
  welcome (marketing), verify-email, password-reset, magic-link, receipt, payment-failed,
  team-invite (transactional), product-update (marketing).

---------------------------------------------------------------------------------------------------
## 5. Endpoints (base http://localhost:4000, all under /v1, API key or session)

Account
  GET    /v1/me                                   -> { api_key, account } for keys
  GET    /v1/health                               -> rates, trust level, next unlock, usage, held items, attention[], next_steps
  GET    /v1/get-started                          -> { account, steps: [{ id, label, done, how }], next_steps }
  GET    /v1/activity?actor_type=&actor_id=       -> audit log
  POST   /v1/account/pause-marketing  { reason? } -> Account (agents may pause; only humans resume)

Emails                                                                         [scope]
  POST   /v1/emails        { to, template? | (subject + html), data?, type?, topic?, from_name? }
                           -> 202 { id, status, environment, next_steps }      [emails:send]
  POST   /v1/emails/batch  { emails: [ ...up to 100 ] } -> { data: [{ id, status }] }  [emails:send]
  GET    /v1/emails?to=&status=&type=&since=&day=YYYY-MM-DD&broadcast_id=  -> Message[] newest first  [logs:read]
  GET    /v1/emails/{id}          -> Message with timeline[] and html          [logs:read]
  GET    /v1/emails/{id}/explain  -> { summary, verdict, steps[], fix, next_steps }  [logs:read]
  Message.status: queued | sent | delivered | bounced | complained | suppressed | failed | held | cancelled

Contacts & events
  GET    /v1/contacts?status=&topic=&list=                                   [logs:read]
  POST   /v1/contacts  { email, external_id?, fields?, topics?, lists? } -> Contact (upsert; lists only adds)  [contacts:write]
  GET    /v1/contacts/{id_or_email}
  PATCH  /v1/contacts/{id_or_email}  { fields?, topics?, external_id?, lists? } (lists replaces)  [contacts:write]
  DELETE /v1/contacts/{id_or_email}  -> { deleted: true, id } (removes personal data everywhere)
  POST   /v1/events  { name, email? | contact_id? | external_id?, data?, occurred_at? }
                     -> { id, contact_id, enrolled_in[], exited_from[], next_steps }  [events:write]
  GET    /v1/events?contact=<id or email>                                     [logs:read]

Contact lists (named groups; membership is NOT consent, broadcasts still skip opt-outs)
  GET    /v1/lists -> ContactList[] { id, name, description, contact_count, active_count }   [logs:read]
  POST   /v1/lists  { name, description? } -> ContactList                     [contacts:write]
  GET|PATCH|DELETE /v1/lists/{id}   (DELETE keeps the contacts; refused while a broadcast targets it)
  GET    /v1/lists/{id}/contacts?status=
  POST   /v1/lists/{id}/contacts         { emails?, contact_ids? }  (unknown emails become contacts)
  POST   /v1/lists/{id}/contacts/remove  { emails?, contact_ids? }
  GET    /v1/event-types   -> { data: EventType[] } most recorded first
  POST   /v1/event-types   { name, description?, properties?: [{ key, type, description? }] } -> EventType + next_steps  [events:write]
  GET    /v1/event-types/{name}
  PATCH  /v1/event-types/{name}  { description?, properties? }  (properties replaces the whole list)  [events:write]
  DELETE /v1/event-types/{name}  -> { deleted: true, name, kept_history }  [events:write]
  EventType: { name, description, properties[], defined, defined_at, first_seen, last_seen, count,
               sequences: [{ id, name, status, role: "trigger"|"exit" }] }
  property.type: string | number | boolean | object | array
  Kinds also appear automatically the first time an event with a new name is recorded (defined: false).
  Properties document the `data` you send; events are not rejected when their data doesn't match.
  Deleting a kind that has recorded events only removes its description and properties.

Templates (HTML with {{variable}} placeholders; versioned)
  GET    /v1/templates
  POST   /v1/templates        { key, type, subject, preview_text?, source, source_kind? "html"|"react", variables? }  [templates:write]
  GET    /v1/templates/{key}?version=   -> Template with versions[]
  PUT    /v1/templates/{key}  { type, subject, preview_text?, source, source_kind?, variables? } -> new version  [templates:write]
  variables: [{ name, default?, description? }]  (both transactional and marketing templates)
    {{name}} in subject, preview text or body. Values come from the send's `data`, then the contact's
    fields ({{first_name}}, {{contact.company}}), then the declared default; {{name|fallback}} sets an inline fallback.
    Omit `variables` on PUT to keep the current list.
  fonts: { heading?, body?, custom?: [{ family, url, fallback? }] } | null   (HTML/Markdown templates; null = theme font)
    heading/body: a Google Fonts family from GET /v1/fonts, or the family of a custom font whose `url` is its https
    stylesheet (Adobe Fonts, Bunny Fonts, self-hosted @font-face CSS). fallback: sans|serif|display|mono|handwriting.
    Blocks templates set style.heading_font / style.body_font (preset, catalog family or custom) and style.custom_fonts.
    Web fonts show in Apple Mail, iOS, Outlook for Mac; Gmail and Outlook for Windows use the fallback.
  GET    /v1/fonts            -> { data: [{ family, category, weights[] }] }
  DELETE /v1/templates/{key}  -> deletes all versions; 409 template_in_use while a sequence or unfinished campaign uses it  [templates:write]
  POST   /v1/templates/{key}/preview  { data? } -> { subject, html, text, image_url }
  POST   /v1/templates/essentials     { brand?: { product_name, logo_url, primary_color, support_email } }
                                      -> { data: Template[] }  [templates:write]

Broadcasts (product updates; a human must approve)
  GET    /v1/broadcasts?status=
  POST   /v1/broadcasts  { name, subject?, template? | html?, data?, topic?, audience_filter?, send_at? }
                         -> Broadcast (status awaiting_approval, approval_url)  [broadcasts:draft]
  GET    /v1/broadcasts/{id}
  PATCH  /v1/broadcasts/{id}   (only while draft / awaiting_approval)
  POST   /v1/broadcasts/{id}/cancel
  POST   /v1/broadcasts/audience-preview  { audience_filter, topic? } -> { count, sample: [{ id, email }] }
  audience_filter: { lists?: [list_id], topic?, fields?: { key: value }, event?: { name, within_days?, did_not? } }
                   lists = contacts on at least one of the lists; all parts are ANDed

Sequences (event trigger -> steps run in order, checks branch into yes / no paths -> exit on event)
  GET    /v1/sequences
  POST   /v1/sequences  { name, trigger_event, steps: [Step], exit_events?, reentry_days?, topic? }
                        -> Sequence (status draft)  [sequences:write]
  GET    /v1/sequences/{id}      PATCH /v1/sequences/{id}
  GET    /v1/sequences/{id}/enrollments   (each has current_step_id, waiting_for)
  DELETE /v1/sequences/{id}/enrollments   (web app only: deletes all enrollments so contacts can re-enter)
  GET    /v1/sequences/{id}/step-counts   -> { data: [{ step_id, active, paused }] }
  POST   /v1/sequences/{id}/on   (session, or key with sequences:activate in test mode)
  POST   /v1/sequences/{id}/off  [sequences:write]
  POST   /v1/sequences/{id}/simulate  { email?, events?: [{ name, after? }], opens?, clicks? }
                        -> { sequence_id, contact_email, timeline[] }   (what-ifs pick the path through waits and checks)
  Step (id optional, max 32 chars [a-zA-Z0-9_-]; default step_<n>, or step_<n>_yes_<m> inside a branch):
    { type: "email", template_key }
    { type: "wait", duration: "P2D" }
    { type: "wait_for_event", event: "project_created", timeout: "P3D", on_timeout: "continue" | "exit" }
        moves on as soon as the contact does the event; only events after reaching the step count
    { type: "check", condition, yes: [Step], no: [Step] }
        runs the matching branch, then carries on with the steps after the check (branches rejoin)
        condition: { kind: "event", event, since: "entered" | "ever" }
                 | { kind: "field", field, op: equals|not_equals|contains|exists|not_exists|gt|lt, value? }
                 | { kind: "email", activity: "opened" | "clicked" }   (the previous email this sequence sent)
        branches hold any steps, including nested checks (at most 5 deep)
    { type: "exit" }   ends the sequence for the contact, e.g. as the last step of a branch
    Legacy { delay, template_key } is still accepted: wait delay, then send.
  Durations are ISO-8601: PT0S, PT1H, P1D, P1W. At least one email step; at most 50 steps in total, counting branches.

Webhooks
  GET    /v1/webhooks
  POST   /v1/webhooks  { url, event_kinds: [...] } -> Webhook incl. signing_secret (shown once)  [webhooks:write]
  GET    /v1/webhooks/{id}      DELETE /v1/webhooks/{id}
  POST   /v1/webhooks/{id}/test  { kind? } -> WebhookDelivery
  GET    /v1/webhooks/{id}/deliveries
  POST   /v1/webhooks/{id}/deliveries/{dlv_id}/resend
  event kinds: email.sent, email.delivered, email.bounced, email.complained, email.opened,
  email.clicked, email.unsubscribed, sequence.entered, sequence.exited, broadcast.held, account.paused

Domains (id = root domain, e.g. acme.com)
  GET    /v1/domains
  POST   /v1/domains  { domain } -> Domain with records[] for mail.<domain> and updates.<domain>  [domains:write]
  GET    /v1/domains/{id}  -> Domain, incl. click_tracking { host, status: not_set_up|issuing_certificate|active|standby|failed }
  POST   /v1/domains/{id}/verify  -> re-check DNS now
  GET    /v1/domains/{id}/connect  -> { supported, provider, url, groups, message }: one-click DNS setup (Domain Connect).
         Give `url` to the founder; they sign in at their DNS provider and approve. url is null when unsupported.  [domains:write]
  Optional record: CNAME links.updates.<domain> -> branded click/open tracking over HTTPS (marketing only, one per account).
  DELETE /v1/domains/{id}  -> { deleted, id }; 409 domain_in_use if it's the only verified domain on a live account  [domains:write]

Test mode
  GET    /v1/test-inbox  -> [{ id, message_id, to, subject, type, template, html, created_at }]

Humans only (session in the web app; API keys get 403 humans_only):
  approve / reject / release broadcasts, go live, resume marketing, account settings, API keys,
  team, billing, plan, spending cap, payment method, bulk delete contacts. Admin: trust levels,
  pause/resume accounts, review queue, global suppression.

---------------------------------------------------------------------------------------------------
## 6. Examples, one per job (TypeScript SDK; `npm install mailpark`)

  import { Mailpark, MailparkError, verifyWebhook } from "mailpark";
  const mailpark = new Mailpark(); // MAILPARK_API_KEY, optional MAILPARK_API_URL

### 6.1 Send a transactional email (password reset)

  export async function sendPasswordReset(email: string, resetUrl: string) {
    try {
      const r = await mailpark.emails.send(
        { to: email, template: "password-reset", data: { email, reset_url: resetUrl } },
        { idempotencyKey: `password-reset:${email}:${resetUrl}` },
      );
      return r.id; // msg_…; status "queued" (or "delivered" in test mode)
    } catch (err) {
      if (err instanceof MailparkError) console.error(err.code, err.message, "Fix:", err.fix);
      throw err;
    }
  }

  curl -X POST http://localhost:4000/v1/emails \
    -H "Authorization: Bearer sk_test_dev_acme" -H "Content-Type: application/json" \
    -H "Idempotency-Key: reset-123" \
    -d '{"to":"jane@example.com","template":"password-reset","data":{"reset_url":"https://acme.dev/r/abc"}}'

### 6.2 Add the essential templates (branded)

  const { data } = await mailpark.templates.addEssentials({
    product_name: "Acme", logo_url: "https://acme.dev/logo.png",
    primary_color: "#4f46e5", support_email: "help@acme.dev",
  });
  const p = await mailpark.templates.preview("welcome", { first_name: "Jane" });
  // p.html, p.image_url. Then: mailpark.emails.send({ to, template: "welcome", type: "marketing", data })

Templates in the repo (emails/<key>.html) carry a header comment and are synced with `mailpark templates push`:

  <!--
  key: trial-ending
  type: marketing
  subject: Your {{product_name}} trial ends in 3 days
  -->
  <html>…{{first_name}}…</html>

### 6.3 Set up a sending domain

  const d = await mailpark.domains.add("acme.dev");
  for (const r of d.records) console.log(r.type, r.name, r.value, r.priority ?? "");
  // Founder pastes these at their DNS provider (Cloudflare, Route 53, …). Then:
  const checked = await mailpark.domains.verify("acme.dev");
  console.log(checked.status, checked.records.filter(r => r.status !== "verified"));
  // When "verified", the founder clicks "Go live" in the web app (agents cannot).

### 6.4 Record an event + onboarding sequence

  // In the app's signup handler:
  await mailpark.contacts.upsert({ email: user.email, external_id: user.id, fields: { first_name: user.firstName, plan: "trial" } });
  await mailpark.events.record({ name: "signed_up", email: user.email });
  // and on upgrade: await mailpark.events.record({ name: "upgraded", email: user.email });

  // Once, during setup:
  const seq = await mailpark.sequences.create({
    name: "Onboarding",
    trigger_event: "signed_up",
    steps: [
      { type: "email", template_key: "welcome" },
      { type: "wait_for_event", event: "project_created", timeout: "P1D", on_timeout: "continue" },
      { type: "check", condition: { kind: "event", event: "project_created", since: "entered" },
        yes: [{ type: "email", template_key: "onboarding-tip-2" }],
        no:  [{ type: "email", template_key: "onboarding-tip-1" }, { type: "wait", duration: "P2D" },
              { type: "email", template_key: "onboarding-tip-2" }] },
    ],
    exit_events: ["upgraded"],
    reentry_days: 90,
    topic: "onboarding",
  });
  const sim = await mailpark.sequences.simulate(seq.id, { email: "test@example.com" }); // fast-forward, test inbox
  await mailpark.sequences.on(seq.id); // may need the founder (sequences:activate is test-only for keys)

### 6.5 Draft a product update broadcast and get approval

  const b = await mailpark.broadcasts.draft({
    name: "October product update",
    template: "product-update",
    subject: "What's new in Acme: October",
    data: { headline: "Dark mode is here", body_html: "<p>…</p>" },
    topic: "product-updates",
    audience_filter: { event: { name: "signed_up", within_days: 90 } },
  });
  // b.status === "awaiting_approval"; b.audience_count; b.approval_url
  // TELL THE FOUNDER: "Your update to {audience_count} people is ready. Approve it here: {approval_url}"
  // On approval it sends to a 5% sample first (per trust level), waits, checks health, then the rest.
  // Check later: mailpark.broadcasts.get(b.id) -> status sending | held (hold_reason, hold_fix) | sent

  // To a hand-picked group instead: make a list, add people, target it.
  const beta = await mailpark.lists.create({ name: "Beta testers" });
  await mailpark.lists.addContacts(beta.id, { emails: ["jane@example.com", "sam@example.com"] });
  await mailpark.broadcasts.draft({ name: "Beta invite", template: "product-update", audience_filter: { lists: [beta.id] } });

### 6.6 Explain a delivery ("why didn't Jane get their reset email?")

  const { data } = await mailpark.emails.list({ to: "jane@example.com" });
  const msg = data.find(m => m.template === "password-reset");
  if (!msg) console.log("Never sent: the app did not call emails.send for this flow.");
  else {
    const e = await mailpark.emails.explain(msg.id);
    console.log(e.summary, e.verdict, e.fix);  // plain language; steps[] show each stage
  }

  CLI: mailpark logs --to jane@example.com ; mailpark explain msg_…

### 6.7 Webhooks with signature verification

  const wh = await mailpark.webhooks.create({
    url: "https://acme.dev/api/mailpark-webhook",
    event_kinds: ["email.bounced", "email.complained", "email.unsubscribed"],
  });
  // Save wh.signing_secret as MAILPARK_WEBHOOK_SECRET (shown once). Test: mailpark.webhooks.test(wh.id)

  // Next.js route handler (app/api/mailpark-webhook/route.ts):
  export async function POST(req: Request) {
    const raw = await req.text(); // RAW body, not re-serialised JSON
    let event;
    try {
      event = await verifyWebhook(raw, req.headers.get("x-signature"), process.env.MAILPARK_WEBHOOK_SECRET!);
    } catch {
      return new Response("bad signature", { status: 400 });
    }
    // Deduplicate on event.id (retries for up to 24h). Then e.g.:
    if (event.kind === "email.bounced") { /* mark the user's email as invalid */ }
    return new Response("ok");
  }

  Signature scheme: header `X-Signature: t=<unix seconds>,v1=<hex>`, where
  v1 = HMAC-SHA256(secret, `${t}.${rawBody}`). Reject if |now - t| > 300 seconds. Compare in constant time.

  Payload: { "id": "evt_…", "kind": "email.clicked", "created_at": "…",
             "data": { "message_id", "type", "to", "contact_id", "template", "link", "likely_automatic" } }
  likely_automatic: true marks machine opens (Apple Mail Privacy Protection etc.).

---------------------------------------------------------------------------------------------------
## 7. Safety rules for agents

- Use test keys (sk_test_…). Going live is a one-time human action in the web app.
- You CAN: draft anything, create/update templates, contacts, events, sequences, webhooks, domains,
  send single emails (one recipient each), simulate, read logs/health/activity, pause marketing.
- You CANNOT (no API or tool exists for keys): approve, reject or release broadcasts; go live;
  change plan, billing, payment method or spending cap; bulk-delete contacts; change trust levels;
  resume marketing; manage API keys or the team.
- Never loop single sends to email many people. Use a broadcast; the founder approves it at approval_url.
- Every broadcast you draft waits in awaiting_approval. Always give the founder the approval_url.
- Do not retry `suppressed` addresses: they bounced or complained before.
- Do not mark promotional content as transactional.
- Never put API keys or webhook secrets in source code. Use env vars.
- Limits grow with good behaviour (trust levels 0-5). Check GET /v1/health for today's marketing
  limit and what unlocks next. Transactional email is never blocked by marketing limits.
- In an emergency (wrong content, complaints spiking), call pause_marketing / POST /v1/account/pause-marketing.
  Transactional continues. Only the founder can resume.

---------------------------------------------------------------------------------------------------
## 8. MCP tools (http://localhost:4000/mcp)

get_started, setup_domain, check_domain, remove_domain, list_templates, get_template, create_template, update_template,
edit_template_blocks, restore_template_version, delete_template,
add_essential_templates, preview_template, send_test_email, read_test_inbox, send_email,
list_contacts, upsert_contact, delete_contact, list_contact_lists, create_contact_list, update_list_members, record_event, draft_broadcast, create_sequence, simulate_sequence,
set_sequence_status, explain_delivery, search_logs, get_health, add_webhook, test_webhook,
webhook_deliveries, pause_marketing, get_activity.
Each result is a short summary + JSON + "Next steps". Errors include "Fix".

Changing templates from an agent:
  get_template { key, version? }            read it first: subject, variables, fonts, body; visual templates list their sections with ids
  update_template { key, …changes }         subject, preview text, type, theme, fonts, variables, or the whole body
  edit_template_blocks { key, ops[], subject?, preview_text? }   visual (blocks) templates, incl. every ready-made one:
    { op: "update", block_id, set: { text: "…", "items.0.title": "…" } }   null removes a field
    { op: "insert", after: block_id | null, block: { type: "markdown", text: "…" } }
    { op: "remove", block_id }  { op: "move", block_id, after: block_id | null }
    { op: "style", set: { accent_color: "#4f46e5", heading_font: "Playfair Display" } }
  restore_template_version { key, version } undo: republishes an earlier version as a new one

---------------------------------------------------------------------------------------------------
## 9. Connect the MCP server

Claude Code (HTTP, recommended):

  claude mcp add --transport http mailpark http://localhost:4000/mcp --header "Authorization: Bearer sk_test_…"

Claude Code (stdio, from a checkout of the backend):

  claude mcp add mailpark --env MAILPARK_API_KEY=sk_test_… -- npx tsx backend/functions/mcp/stdio.ts

Other clients (Cursor, Codex, …): add a "streamable HTTP" MCP server with URL
http://localhost:4000/mcp and header `Authorization: Bearer sk_test_…`. The server is stateless;
send JSON-RPC with POST and `Accept: application/json, text/event-stream`.
Production will use OAuth sign-in instead of a pasted key.

Quick check with curl:

  curl -s http://localhost:4000/mcp -H "Authorization: Bearer sk_test_dev_acme" \
    -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" \
    -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'