Postfjord

Create a signup form (live at once)

postfjord_create_signup_form

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. On a Free workspace the form can be built and stays closed until a paid plan: the answer says closedUntilPaid. 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.

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_create_signup_form"
  }
}

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 observedOct 26, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses double opt-in confirmation, that tags are applied only on confirmation, the Free-workspace behaviour where the form stays closed and the response carries closedUntilPaid, and the quota and auth-scope requirements. The retry semantics also resolve the idempotentHint=false annotation by explaining that keyed retries replay the first answer rather than creating a duplicate, which is consistent, not contradictory.

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-loads the core behaviour and the public-link result in the first sentence, then stacks constraints and the alternative tool. It is dense and slightly overloaded with parenthetical tool references, but essentially every clause carries operational information, so little could be cut without loss.

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 mutation with no output schema, the description covers what an agent most needs and cannot get elsewhere: the side effects (email sent, tags applied on confirm), the shape of the answer (public link, closedUntilPaid), prerequisites, quotas, and retry safety. Nothing material to calling it correctly is missing.

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 description coverage is 100%, so the schema carries most parameter meaning and the baseline would be 3. The description still adds real semantics the schema does not: tags are applied at confirmation time rather than at signup, and the response exposes the public link and closedUntilPaid. That is a modest but genuine addition above 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?

States a specific verb and resource ("Creates a signup form for the email list") plus a distinguishing qualifier ("switched on") that separates it from a draft/list tool. It also names the neighbouring tool it is not (postfjord_plan_goal), so 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?

Gives explicit when-to-use and when-not-to-use guidance: use postfjord_plan_goal for planning a whole Flow around a goal, and "Confirm the texts with the person first." It also lists prerequisites (email switched on via postfjord_mail_overview, Publish scope) and a hard limit (at most 20 forms per workspace).

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

All Postfjord 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.

Resources

Need Help?