Skip to main content
Glama
Rustysama

Postfjord

by Rustysama
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Draft an email

postfjord_draft_campaign

Creates a branded email draft for a tag, segment, or all confirmed contacts, using custom blocks or a brief, and reports reach plus an editor link; nothing is sent.

Instructions

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.

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.
subjectNo
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. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the generic flag set (readOnly=false, destructive=false, idempotent=false); the description goes far beyond by stating 'Nothing is sent', that AI drafting consumes the workspace AI budget, that the response reports the reached confirmed-contact count, and how idempotency_key makes retries safe (first answer returned, nothing duplicated) despite idempotentHint=false. It also discloses the handoff path editUrl for humans.

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 but each sentence carries information (routing, targeting defaults, authoring paths, images, sending handoff, retry semantics). The opening clause about automation series slightly delays the core statement, which is the only structural weakness.

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 mutation with no required fields and no output schema, the description covers what is created, what is targeted by default, both authoring modes, where image ids come from, how the result is returned, and how to send it afterwards. The heavy block schema is self-documented at 92%, so no further param detail is needed.

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 92%, so the baseline is 3. The description still adds meaning the schema does not: tags are matched case-insensitively, and the absence of both tags and segment means everyone who opted in ('everyone who said yes'). It doesn't explain name/language/logo beyond the schema, keeping it short of a 5.

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 concrete verb and resource: 'Creates a new email as a draft' in the workspace's brand styling, and explicitly distinguishes it from postfjord_create_email_automation (self-starting series) and postfjord_schedule_campaign (sending). An agent can route correctly without opening a 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?

Names alternatives and the conditions that pick them: use postfjord_get_brand_profile first for writing rules, postfjord_list_media for image ids, postfjord_schedule_campaign to actually send (with its required level). It also says when to choose the self-written path vs the AI brief path. Nothing left to inference.

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

Deploy Server

Other Tools