Playbook

Publish board

publish_board

DestructiveIdempotent

Create or update a board's public page, optionally changing its expiry, download restriction, or password. Returns the public URL. This is different from share_board — a published board is a standalone public landing page, while share_board returns an invite-style shareable link. Pass template to give the page a designed layout: valid ids are the keys of templates in get_page_elements_catalog (an unknown id is refused with the valid list). A template publish creates the page design that get_page_layout and the page element tools read and edit. Omit template on a board that is NOT live and has no page design yet, and it is published with standard so it is editable straight away (a workspace's own version of that template applies if it has one). A live page, or a board that already has a design, is never given a template implicitly. template_applied in the response names the template this call applied, and is absent when the design was left alone. An explicit template is refused with 409 page_design_exists when the page has stored element edits, rather than overwriting them: republish WITHOUT template to keep that design, and edit it with the page element tools. That refusal does NOT cover a design that is only page settings (background colour, typography set with update_page_settings) — a template publish replaces those. A page still following its template (never edited) switches to the new one. Exposure: this makes the board and its assets publicly accessible on the internet to anyone with the URL.

Input Schema

TableJSON Schema

Name	Required	Description
`token`	Yes	Board token, as returned by list_boards, list_board_children or ai_search — the parameter name is `token`, not `board_token` or `collection_token`.
`password`	No	Password-protect the page; empty string clears it
`template`	No	Page-design template id: a key of `templates` in get_page_elements_catalog, such as `brand` — not its `display_name`. Omit to keep an existing design, or to get `standard` on a board that is not live and has none.
`organization`	No	Workspace slug, as returned by list_organizations. Omit it when the account has a single workspace — it is then resolved from your token. Pass it only when the account has several, or when you mean a workspace other than the obvious one.
`expiration_date`	No	ISO 8601 expiry; empty string clears an existing expiry
`disable_downloads`	No	Prevent downloads from the published page

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 5, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

removedInput schema / properties / context

Removed value: -{
-  "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
-  "type": "string"
-}

changedInput schema / required

Previous value: -[
-  "token",
-  "context"
-]New value: +[
+  "token"
+]

First observedOct 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations (destructiveHint, openWorldHint, idempotentHint) only sketch the profile; the description adds the substantive behavior: public internet exposure of the board and its assets, the 409 refusal code and its scope, that a template publish replaces page settings but not stored element edits, and that `template_applied` is absent when the design was untouched. Nothing here contradicts the annotations.

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?

The critical scoping and the sibling differentiation are front-loaded, and the dense template semantics are genuinely load-bearing for correct invocation. It is still a long, paragraph-heavy block with some repetition around template handling that could be tightened, so it falls short of ideal conciseness.

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 high-complexity, destructive, open-world mutation tool with no output schema, the description covers the mutation surface, the return values (public URL, `template_applied`), the failure mode (409) and its remedy, and the exposure consequence. An agent has everything needed to call it correctly.

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 goes further by explaining the conditional meaning of `template` (implicit `standard` on a non-live board, workspace-specific template override, refusal when edits exist) and the resolution rules around `organization`. The remaining parameters are covered adequately by the schema itself.

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 first sentence gives a specific verb+resource (create/update a board's public page) plus the mutation surface (expiry, download restriction, password) and the return value (public URL). It then explicitly contrasts itself with the sibling `share_board`, so an agent can route between them without opening either 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?

It states when to pass `template`, when to omit it, when an implicit `standard` applies, and the recovery path when a 409 `page_design_exists` is returned (republish without `template` and use the page element tools). The share_board vs publish_board distinction and the 'live page or existing design is never given a template implicitly' rule are explicit exclusion criteria.

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

All Playbook 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?