Skip to main content
Glama
Rustysama

Postfjord

by Rustysama
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Stop a Flow

postfjord_cancel_goal
DestructiveIdempotent

Stop or close a Postfjord Flow: cancel unsent posts, switch off DM automation and pause emails; for step-by-step Flows, close signups or turn the Flow off as a draft.

Instructions

This is a Flow in Postfjord (the person may say "start a flow", "a flow" or "my flows"): stops a goal: posts that have not gone out are cancelled, the DM automation is switched off and the emails pause. Contacts, tags, consents and posts already out stay. A Flow Bo planned is stopped for good: its signup form is switched off and its page goes offline. One Bo planned that never went live (proposed or built) is thrown away with its drafts instead, keeping any part the person switched on or scheduled themselves. A Flow the person built step by step (builder true) is turned off instead: it becomes a draft that can be changed and go live again with postfjord_launch_goal, and its page stays online unless takePageDown is true. With mode close, a Flow built step by step closes to new signups instead: nobody new joins (posts not out yet are cancelled, the DM switches off, the signup form closes), while the people already in keep getting every email, birthday emails included; it stays live with closedAt set, and postfjord_launch_goal opens it again. Ask the person which one they want, and confirm first. Needs the Publish scope; works while the workspace is paused.

Input Schema

NameRequiredDescriptionDefault
modeNoOnly for a Flow built step by step: close keeps the emails going to the people already in; stop (the default) pauses them too.
goalIdYesThe goal id from postfjord_plan_goal or postfjord_list_goals.
takePageDownNoOnly for a Flow built step by step: also take its landing page and signup form offline. Links to the page stop working.

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 beyond the destructive/idempotent annotations by spelling out exactly what is destroyed (unsent posts, DM automation, paused emails, signup form, page) versus preserved (contacts, tags, consents, already-sent posts, pages unless takePageDown). Also discloses the Publish scope requirement and that it works while the workspace is paused.

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

Conciseness3/5

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

The purpose is front-loaded, but the body is a dense run-on with repeated framing ('This is a Flow in Postfjord', 'A Flow Bo planned', 'A Flow the person built step by step') and restates schema-documented mode/takePageDown behavior. Acceptable length for a complex destructive tool but poorly structured and partially redundant.

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 destructive, no-output-schema, multi-mode tool, it covers everything an agent needs: branch conditions, side effects, what survives, permission scope, and reopening path. Nothing material 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 coverage is 100%, so the baseline is 3, but the prose adds real meaning: it explains that close keeps existing members receiving every email including birthday emails and leaves closedAt set, and that takePageDown pulls the page offline only for builder Flows. This enriches the terse enum/boolean descriptions rather than merely repeating them.

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 (stops/cancels a goal) and resource (a Flow goal), and explicitly names the counterpart operation postfjord_launch_goal that reopens what this closes. The multi-branch explanation makes the effect unmistakable versus siblings like update_goal.

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 condition-based routing: stop vs close for builder Flows, permanent stop for Bo-planned Flows, draft-revert for step-by-step builds, fairly explicitly telling the agent which variant applies. It also instructs the agent to ask the person and confirm first. Lacks only explicit comparison to non-goal siblings like postfjord_cancel_campaign.

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