Skip to main content
Glama
Rustysama

Postfjord

by Rustysama
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Update landing page draft

postfjord_update_page
DestructiveIdempotent

Updates a page draft's title, blocks, description, SEO title, style, search visibility, or live schedule by sending only changed fields, then returns remaining publish checks.

Instructions

Changes a page's draft: title, blocks, description, search title, style, Hide from Google (hideFromSearch), or when a landing page is online (liveFrom, liveUntil). Send only what changes; blocks replaces the whole list, so send every block that stays, with its id from postfjord_get_page. A published page stays live with the version that was published, as in the app, until it is published again with postfjord_publish_page. The answer has the page and the checks that still stop a publish.

Input Schema

NameRequiredDescriptionDefault
styleNoA new style resets the colours to the style's, with the brand kit's on top unless useBrand is false.
titleNo
blocksNoThe blocks from top to bottom. A link in bio page is usually: a hero with layout avatar (the business name, a short line and a photo), a links block with the most important links, and a social block. A landing page for one offer: a hero, a text, a list or faq, a button or a form block. A countdown block (date, time, tz, units, button { label, href }, after, afterText, afterButton) counts down to a date, like a launch or the last day to sign up: use only a real date the person gave, and never move a deadline that has passed to a later one. A location block (name is the business name here; street, city, region, postal, country, phone, tz, week, exceptions) shows the address, opening hours with Open now, a Call button and map links: use only hours and an address the user gave you; never invent them. For a class, call or appointment, use a booking block with the booking link; never invent a link. Write real facts only; do not invent prices, dates or quotes. Text in [brackets] stops a publish; a link written [words](https://address) in a text, the hero line or a faq answer is a link, not brackets, and [words]{#rrggbb} gives those words a color (only when the user asks for one). Any block, and any row of a links block, can show only from one time until another (show).
pageIdYes
liveFromNoLanding pages only: when visitors can see the whole page, as a date and time with an offset or a local time in the workspace time zone (timeZone in postfjord_get_page). Before liveFrom the address says the page does not exist; after liveUntil visitors see that it has ended. null removes it. The link in bio page cannot be scheduled as a whole.
seoTitleNo
useBrandNo
liveUntilNoLanding pages only: when visitors can see the whole page, as a date and time with an offset or a local time in the workspace time zone (timeZone in postfjord_get_page). Before liveFrom the address says the page does not exist; after liveUntil visitors see that it has ended. null removes it. The link in bio page cannot be scheduled as a whole.
descriptionNo
hideFromSearchNoLanding pages only: true keeps the page out of Google and other search engines (a robots noindex tag, and it leaves the sitemap), so only people with the link find it. On a live page the change goes live with the next postfjord_publish_page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the annotations, it discloses that this edits a draft while a published page stays live on its published version until republished, and that blocks replacement requires re-sending every block that stays. It also says the response contains the page and remaining publish-blocking checks, adding useful output and state context.

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?

The description is front-loaded with the editable fields, then moves to the critical blocks-replacement caveat, publish behavior, and response contents. Every sentence carries operational value with no filler.

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?

For a 10-parameter destructive update with no output schema, it covers the essential state behavior, block replacement rule, and response contents. Gaps remain around permissions and a few top-level parameters, but the core guidance needed to call it correctly is present.

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 coverage is 50%, and the description adds real semantics for blocks (full replacement, keep ids) and for liveFrom/liveUntil/hideFromSearch. However, it does not explain top-level parameters such as useBrand, seoTitle, or description, so it only partly compensates for the undocumented half of 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?

The description states a specific verb and resource: it changes a page's draft, and it enumerates the editable fields (title, blocks, description, search title, style, hideFromSearch, liveFrom/liveUntil). This clearly distinguishes it from postfjord_create_page and postfjord_publish_page.

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?

It explicitly says 'Send only what changes' and clarifies that 'blocks replaces the whole list,' which guides correct partial updates. It also references postfjord_get_page for block ids and postfjord_publish_page for making a published page live again, though it does not spell out when to use this versus create_page.

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