EmailFig

Create campaign draft

create_campaign_draft

Saves a new campaign as a draft in EmailFig and returns a link to it. It never sends: a person reviews the draft and sends it from EmailFig. Write the body as blocks, after calling get_email_format, so the person can edit it in EmailFig's drag-and-drop editor.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "subject": "<subject>",
      "audience": "<audience>",
      "body": "<body>"
    },
    "name": "create_campaign_draft"
  }
}

Input Schema

Name	Required	Description
`body`	Yes	Exactly one of: blocks (the editor format from get_email_format), html, or template_id. Use blocks unless the person gave you HTML or chose a template.
`name`	Yes	What the campaign is called in EmailFig.
`subject`	Yes
`audience`	Yes	Who it goes to, one of: { everyone: true }, { list_ids: [...] }, or { tag_ids: [...], segment_ids: [...] }.
`preview_text`	No	The line inboxes show after the subject.
`subscription_list_id`	No	A list list_lists marks as a subscription_list: people can subscribe to it and leave, and anyone who left is skipped. Needed before sending when the account has such lists.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=false and destructiveHint=false, but the description adds material context they do not carry: the draft is never sent, a human reviews and sends it in EmailFig, and the call returns a link. It says nothing about duplicate or repeat-call behavior, which matters for a non-idempotent write.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with zero filler. The key constraints are front-loaded: what it does, that it never sends, and how to build the body.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the essentials for a six-parameter write tool that returns no output schema: the return value (a link), the human-review step, and the prerequisite call. It doesn't explain what happens on duplicate names or how errors surface, which leaves a small gap for a create operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 83%, so the schema already documents body, audience and subscription_list_id in detail. The description reinforces the sequencing (blocks should come from get_email_format so the draft opens in the drag-and-drop editor), which is useful, but it adds little about the parameters themselves beyond what the schema says.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Saves a new campaign as a draft in EmailFig'), the side effect (returns a link), and the boundary ('It never sends'). 'New campaign' implicitly separates it from the sibling update_campaign_draft, so an agent can pick the right one without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete usage condition and prerequisite: write the body as blocks after calling get_email_format, and use blocks unless the person gave HTML or chose a template. It never explicitly contrasts with update_campaign_draft, but the 'new' framing plus the never-sends note provide clear context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All EmailFig tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.