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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "token": "<token>"
    },
    "name": "publish_board"
  }
}

Input 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.

Changed1 schema field changedNov 3, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```

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.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds substantial behavior beyond them: the internet-wide exposure of the board and its assets, the 409 `page_design_exists` refusal condition, which designs the refusal does and does not protect (page-settings-only designs get replaced), and the `template_applied` response field. Minor gap: it does not say whether republishing is additive or whether unpublishing exists, but coverage is strong for a mutating, publicly-exposing operation.

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 purpose and sibling differentiation, then template semantics, with the exposure warning placed last. The template paragraph is dense and sentence-heavy, but each sentence carries distinct operational information; only the length relative to the point of exposure placement keeps it from a 5.

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 6-parameter mutating tool with an open-world, destructive profile and no output schema, the description supplies what is needed: return value, failure mode and recovery, template resolution rules, and the public exposure consequence. Nothing an agent needs in order to call it correctly appears to be 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 would be 3, but the description goes beyond the schema by explaining the conditional semantics of `template` — that unknown ids are refused with the valid list, that a live page or an existing design never implicitly receives a template, and when `standard` is applied. It also explains the interaction between `template` and stored element edits, which the schema 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?

Opens with a specific verb+resource ("Create or update a board's public page"), states the return value ("Returns the public URL"), and explicitly distinguishes itself from the sibling `share_board` by contrasting a public landing page with an invite-style link. An agent can identify and separate this tool from its neighbors without opening the 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?

Gives explicit when-to-use and when-not guidance: pass `template` for a designed layout, omit it on a non-live board with no design, republish WITHOUT `template` to preserve stored element edits, and use the page element tools to edit instead. It names the alternative tool for the adjacent need and states the exact recovery path after a 409.

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?