Skip to main content
Glama

Change many posts at once

postfjord_bulk_update_posts
Destructive

Apply one change to up to 200 posts at once: reschedule, draft, cancel, or delete, with a result for each post.

Instructions

Use when the same change applies to many posts (move a week, unschedule, cancel, delete); for one post use postfjord_update_post or postfjord_schedule_post. One action on up to 200 posts, with a result per post. reschedule moves scheduled posts, and drafts that have a date, by shift ({ days, hours, minutes }, negative moves them earlier) or so the earliest starts at startAt and the others keep their spacing; it needs a key that may publish and is refused while the workspace is paused. draft takes scheduled or cancelled posts out of the queue as drafts that keep their date. cancel cancels scheduled posts. delete removes drafts, cancelled, failed and scheduled posts for good (a key with only the Drafts level deletes drafts and cancelled posts), so tell the person how many and get a yes first. Posts being published or already published are never changed: they come back as skipped with a code, like not_found, publishing, published, key_scope, past, month_full, x_addon or changed. 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
shiftNoFor reschedule: how far to move each post. Days keep the time of day in the workspace time zone. At most 366 days.
actionYes
postIdsYesPost ids from postfjord_list_calendar, at most 200.
startAtNoFor reschedule, instead of shift: an ISO 8601 date-time with time zone for the earliest post, e.g. 2026-11-02T09:00:00-05:00.
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.9/5.0
Behavior5/5

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

Goes far beyond the destructiveHint annotation: discloses that reschedule needs a publish-capable key and is refused while the workspace is paused, that delete is permanent and scope-limited by key level, and that publish-in-progress/published posts are never touched and return as skipped with a specific code list. It also prescribes a confirmation step before destructive deletes.

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 selection rule and alternatives before the dense action-by-action detail. It is a long single paragraph, but nearly every clause carries operational information; minor loss for density that could be broken into a short list.

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?

A destructive, multi-action bulk tool with no output schema is fully covered: actions, key requirements, refusal conditions, skip codes, and retry semantics are all present. Nothing an agent needs to call it safely is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

At 80% schema coverage the baseline is 3, but the description adds real meaning: negative shift moves earlier, startAt anchors the earliest post while others keep spacing, and the idempotency_key retry contract (first answer replayed, nothing made twice). These are behavioral semantics the schema alone does not convey.

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 ('one action on up to 200 posts') and explicitly names the scope boundary against siblings postfjord_update_post and postfjord_schedule_post for single-post edits. The scale limit and per-post result shape are stated outright.

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?

Opens with the exact selection condition ('when the same change applies to many posts') and names the alternatives for the single-post case. Each of the four actions is then given its own applicability rules (reschedule for scheduled/drafts-with-date, draft for scheduled/cancelled, delete for which statuses).

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