Postfjord

Create a signup form (live at once)

postfjord_create_signup_form

Build a public email signup form with double opt-in: share the link, collect contacts, and apply tags automatically when people confirm their subscription.

Instructions

Creates a signup form for the email list, switched on: the answer has its public link, and anyone with the link can sign up. Each person gets an email to confirm first (double opt-in), and the tags go on when they confirm. To plan a whole Flow around a goal (posts, DM, page and emails), use postfjord_plan_goal instead. Confirm the texts with the person first. Needs email switched on (postfjord_mail_overview) and the Publish scope; a workspace has at most 20 forms. 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

Name	Required	Description
`why`	No	One line under the phone and birth date fields on what they are used for, for example "We use your phone number and date of birth to book you in and send a gift on your birthday." Required with askPhone or askBirthday.
`name`	No	An internal name, only the team sees it.
`tags`	No	Tag names to give people who confirm. A new name makes the tag.
`text`	No	A line under the heading: what people get and how often.
`button`	No	The words on the button, for example "Send me the guide".
`reward`	No	What they get for signing up (a code, a guide link), shown once they confirm.
`askName`	No	Also ask for a first name. Default false.
`heading`	No	The heading on the form page.
`success`	No	What people read after they send it.
`askPhone`	No	Also ask for a phone number, required on the form. Default false. Needs why.
`phoneLabel`	No	The label of the phone field, in the page's language.
`askBirthday`	No	Also ask for the date of birth, required on the form, saved as the contact's birthday so a yearly birthday email can use it. People may write 900314, 1990-03-14 or 14 March 1990; of a whole Swedish personal number only the date is kept. Default false. Needs why.
`birthdayLabel`	No	The label of the date of birth field, in the page's language.
`idempotency_key`	No	Your 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.

First observedv0.1.0Oct 26, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses that the form is public and live immediately, that signups trigger a double opt-in confirmation email (an outbound side effect), and that tags are only applied after confirmation. It also carries quota and auth-scope requirements and explains retry semantics, none of which the readOnly/destructive/openWorld hints convey.

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?

Four dense sentences with no filler, and the highest-value facts (what it makes, that it is live, the sibling boundary) are front-loaded. Every sentence carries a distinct operational fact.

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 14-parameter creation tool with no output schema, the description covers the return value ('the answer has its public link'), the side effects, the prerequisites, and the quota. Nothing an agent needs before calling is missing.

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 100%, so all 14 parameters (including why, tags, askBirthday and idempotency_key) are already documented in the schema with examples. The description adds only the retry-situation framing for idempotency_key, which is close to what the schema already says ('send the same one again only when you retry').

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+resource ('Creates a signup form for the email list') and immediately pins down the important scope detail that it goes live at once rather than saving a draft. The sibling redirect to postfjord_plan_goal makes the boundary unmistakable.

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?

Explicitly names the alternative (postfjord_plan_goal) and the situation that selects it, plus concrete preconditions: email must be switched on (postfjord_mail_overview), the Publish scope is required, and a workspace caps at 20 forms. It also adds a workflow instruction ('Confirm the texts with the person first') and retry guidance.

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

Deploy Server

Create a signup form (live at once)

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools