Skip to main content
Glama
Sign In
hybriden

Paperboy CMS

Official
by hybriden
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

publish_content

Make a content item's working draft live in one locale (a LANGUAGE BRANCH: Norwegian text published into 'en' lands on the English site, so a clear mismatch is refused).

Instructions

Make a content item's working draft live in one locale (a LANGUAGE BRANCH: Norwegian text published into 'en' lands on the English site, so a clear mismatch is refused). A future publishAt SCHEDULES it instead: it stays invisible until then; call again with a new publishAt to reschedule, or without one to go live now. expireAt unpublishes it automatically later. Never fake a schedule with a date field — that publishes now. A changed slug or position gets a 301 from the old URL. Fires content.published. Refused when there is nothing new to publish, when required fields are empty (the error names them), or, if the site requires human review of agent drafts, until an editor approves it. Returns the item in the get_content shape with its new status. To take it down use unpublish_content; to drop unpublished edits, discard_draft.

Input Schema

NameRequiredDescriptionDefault
siteNoSite slug or id to act in (multisite). Omit to use this server's default site. Call list_sites to see what exists — an empty tree or search usually means the wrong site, not missing content.
localeNoLocale code. Omit for the document's own locale (its site-default variant, else its only variant).
expireAtNoWhen to unpublish automatically (ISO 8601). Must be after publishAt.
publishAtNoFuture go-live time (ISO 8601, e.g. "2026-09-01T09:00:00Z"). Omit to publish immediately.
documentIdYesThe item's documentId (stable across locales and versions), e.g. from list_tree, list_content or get_content.
allowLanguageMismatchNoSet true ONLY when publishing content whose language deliberately differs from the locale branch

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.7

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the write/non-idempotent/non-destructive profile; the description goes far beyond by disclosing scheduling semantics, automatic unpublication via expireAt, the 301 on slug/position change, the content.published event, language-mismatch refusal, and required-field/review refusals. It also warns against faking a schedule with a date field, which prevents a real misuse.

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?

Dense but front-loaded: the core action and its scheduling semantics come first, with routing and refusal details trailing. Every sentence carries information, though the prose runs long for a single tool and could be tightened slightly.

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?

With no output schema, the description compensates by stating the return shape (the item in get_content shape with its new status) and covering the full behavioral envelope: scheduling, expiry, redirects, events, and refusals. Nothing an agent needs to call 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 coverage is 100%, so the baseline is 3, but the description adds genuine meaning: it explains the locale branch/language-mismatch interaction, that publishAt schedules rather than publishes now, and that rescheduling is done by re-calling with a new publishAt. It does not restate the schema's own wording verbatim.

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?

Names a specific verb (publish/make live) and resource (a content item's working draft), scopes it to one locale, and distinguishes the sibling actions unpublish_content and discard_draft. An agent can tell this apart from update_content or create_content 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?

Explicitly covers when to use it (go live now vs. schedule via publishAt), how to reschedule (call again with a new publishAt), and which sibling to use instead for takedown or discarding edits. Failure/refusal conditions are enumerated, so the agent knows when the call will be rejected.

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