Skip to main content
Glama
Rustysama

Postfjord

by Rustysama
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Schedule an email

postfjord_schedule_campaign

Schedules a draft email to send now or at a set time to its stored audience or a chosen segment, optionally running an A/B subject test before delivery to real inboxes.

Instructions

Schedules a draft email at a time or now, to the audience stored on the draft (its tags or segment; everyone who confirmed when it has none), or to one saved segment given here. The email then goes to real inboxes and cannot be taken back once sent. Confirm the email, the audience and the time with the person first. Postfjord runs the same checks as the app: sending must be open for the workspace, the content must pass the checks, and this month must have emails left. A large first email waits for Postfjord to look at it (status review), and a first email goes to a small sample first. With abTest it tests a second subject line: a share of the list gets one of the two, split evenly, and after the wait the rest get the one with more unique clicks (or the one a person picks in the app). Each subject must reach at least 10 people. 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
whenYes"now", or an ISO 8601 date-time with its time zone, e.g. 2026-10-06T09:00:00-05:00.
abTestNoAn A/B test of the subject line. null switches off a test stored on the email; left out keeps it.
segmentIdNoA saved segment id from postfjord_mail_overview. Leave out to use the audience stored on the draft.
campaignIdYes
idempotency_keyNoYour own id for this one action. Send the same one again only when you retry after a timeout. Left out, every call runs, so calling it again after a change publishes or schedules the new version.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Goes well past the annotations: irreversible send, workspace send-gate checks, month quota, 'review' status for a large first send, sample-first delivery, A/B split mechanics and the 10-recipient minimum, required permission level, and idempotency-on-retry behavior. This is exactly the additional context annotations cannot carry.

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?

Front-loaded with the core action and irreversibility, and most sentences carry unique operational facts. It is long, and the A/B-test paragraph largely rehearses defaults already stated in the abTest schema, which is the main trimmable portion.

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?

Given a multi-parameter, high-stakes mutation with no output schema, the description covers preconditions, permissions, irreversibility and retry semantics well. What is missing is what a call returns (scheduled time, campaign id, 'review' status), which the agent needs to confirm success.

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 80%, so most parameters are already documented. The description still adds meaning the schema lacks: the fallback audience rules ('tags or segment; everyone who confirmed when it has none') and the A/B constraint that each subject must reach at least 10 people. campaignId remains unexplained in both places.

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 ('Schedules a draft email') and immediately scopes it: audience comes from the draft, or one saved segment given here. An agent can tell this apart from postfjord_draft_campaign or postfjord_schedule_post 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 Guidelines4/5

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

Gives clear operating context: confirm recipients/audience/time with a human first, that sending must be open, content must pass checks, and quota must remain. However it never names alternatives such as postfjord_cancel_campaign or the drafting step, so exclusion guidance is absent.

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