Skip to main content
Glama

Draft an email

postfjord_draft_campaign

For one email to the list; a series that starts by itself for each new contact is postfjord_create_email_automation. Creates a new email as a draft, in the workspace's brand colors with its logo on top. Nothing is sent. It can carry who it goes to: tags (contacts with any of these tag names, matched without caring about capitals) or a segment (a saved segment's name or id); without either it goes to everyone who said yes. The answer then says how many confirmed contacts it reaches. Either write it yourself with subject, preheader and blocks (read postfjord_get_brand_profile first and follow its writing rules), or give a brief and Postfjord's own AI drafts it (uses the workspace AI budget). Images are ids from postfjord_list_media. A member opens the draft in the editor from editUrl. To send it, use postfjord_schedule_campaign, which needs the Schedule and publish level. On a retry after a timeout or error, send the same idempotency_key: the first answer comes back and nothing is made or sent twice.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "postfjord_draft_campaign"
  }
}

Input Schema

NameRequiredDescriptionDefault
goalNoWith a brief: what the email should make people do.
logoNoPut the brand logo on top. Default true.
nameNoAn internal name, only the team sees it.
tagsNoSend only to contacts with any of these tags, by tag name (see postfjord_list_tags). Not together with segment.
briefNoInstead of blocks: what the email is about, for Postfjord's AI.
linksNoWith a brief: the only links a button may use.
blocksNoThe email top to bottom. Leave out when you send a brief.
segmentNoSend only to this saved segment, by name or id (see postfjord_mail_overview). Not together with tags.
subjectNoThe subject line. Leave out when you send a brief.
languageNoTwo letter language code of the email, for example en or es. Default: the brand's.
usePostsNoWith a brief: may use recent posts and their photos. Default true.
preheaderNoThe line inboxes show after the subject.
idempotency_keyNoYour own id for this one action, for example post-20261006-launch. Make a new one for each new thing; send the same one again only when you retry. Left out, the exact same call within 10 minutes counts as a retry.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / subject / description
      Added value: +"The subject line. Leave out when you send a brief."
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Adds substantial behavior beyond the annotations: nothing is sent, the AI path consumes the workspace AI budget, the response reports how many confirmed contacts are reached, editUrl opens the editor, and retry semantics via idempotency_key are spelled out. One tension worth noting: idempotentHint=false, while the description describes same-key retries returning the first answer and a 10-minute dedupe window — not a direct contradiction, since idempotency is opt-in via the key, but the two readings sit slightly awkwardly.

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

Conciseness4/5

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

Dense and mostly front-loaded — scope and the sibling exclusion come first, then audience, then authoring path, then next steps. The opening clause ('For one email to the list; a series that...') is slightly contorted, and a few sentences pack two ideas each, but almost every sentence earns its place.

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

Completeness5/5

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

For a 13-parameter creation tool with no output schema and light annotations, the description covers everything an agent needs: what is created, that nothing is sent, how the response is shaped (reach count, editUrl), audience defaults, parameter interdependencies, and the retry contract. No material gap remains.

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

Parameters4/5

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

Schema coverage is 100% and the block schema is extremely detailed, so the description only needs to orient. It still adds real meaning: tags and segment are audience selectors that exclude each other and default to all confirmed contacts without either, brief and blocks are alternatives, and 'read postfjord_get_brand_profile first and follow its writing rules' is operational guidance found nowhere in the schema.

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?

The opening states a specific verb and resource ('Creates a new email as a draft') and immediately scopes it against the closest sibling: 'a series that starts by itself for each new contact is postfjord_create_email_automation.' An agent can pick between drafting a one-off campaign and creating an automation 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 Guidelines5/5

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

Explicit routing is provided at every decision point: use create_email_automation for series, read get_brand_profile first before writing blocks, take image ids from list_media, use schedule_campaign to actually send (and that it needs the Schedule and publish level). It also states the two mutually exclusive authoring paths (own blocks vs brief for AI drafting).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources