Skip to main content
Glama

Publish

publish
Idempotent

Put an item live. Confirm with the user before calling this.

By type: • workflow — its draft becomes the live version and its triggers start firing real actions. On a paused workflow this is the editor's "Resume workflow": if has_unpublished_changes is false the live version resumes as it was (resumed: true); otherwise the draft is published as well and the answer says the draft changes went live (published_draft: true), so tell the user which before asking. Runs the pause parked stay parked either way: once the workflow is live again, each is continued with Resume on its run page in Stepper (pressed while the workflow is still paused, the run parks again at once); runs that were sleeping on a delay, approval or retry and wake after the resume carry on by themselves. A live workflow whose draft matches it answers nothing_to_publish without asking. A draft with a step that a later step or rule reads but that has no example output is refused without asking; the refusal names each such step, what reads it, and the call that stores one (load_trigger_samples or test_action with workflow and node). Fetch it first and tell the user what it does. If Stepper refuses (an app refusing a trigger, say), the answer has published: false, live (whether an older version is still running) and a publish_failed diagnostic carrying Stepper's reason. • form — its draft (the edits made with edit_source or in the app) goes live. It never reopens a closed form: write disabled: false in the source, then publish. With no draft, nothing is published and the result says so (published: false).

A published form's result carries live_url: the public address people open to fill it in. Give that link to the user; it is the form's view_url, while edit_url is the editor. live_url is absent when the form has no public address yet.

Example: publish({ id: "12:form:5f3c9a…" }) → { "id": "12:form:5f3c9a…", "type": "form", "live": true, "live_url": "https://…", "record": { … } }

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": {
      "id": "<id>"
    },
    "name": "publish"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe form or workflow id.

Output Schema

NameRequiredDescriptionDefault
idNo
urlNo
recordNo
live_urlNo
publishedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses that publishing starts real trigger actions, explains the paused-workflow resume semantics (resumed vs published_draft), how parked runs behave, and what a Stepper refusal returns (published: false, live, publish_failed). This is exactly the mutation-side-effect context the annotations cannot convey.

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-loads the imperative and the confirmation requirement, then organizes the rest by type with bullets. It is dense and long, but nearly every sentence carries operational detail; a little tightening of the parked-runs passage would help.

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?

Even though an output schema exists, the description still explains the key return fields (live_url vs edit_url, published_draft, published: false) and the failure diagnostics, leaving no ambiguity about what a caller will get back for either item type.

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% and the single id parameter is documented, so the baseline is 3. The description adds real meaning by explaining that the id's type determines entirely different behavior, which the schema's 'form or workflow id' only hints at.

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 and resource ('Put an item live') and immediately disambiguates the two item types it applies to (workflow vs form), which is exactly what an agent needs to distinguish it from siblings like unpublish or update.

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 says to confirm with the user before calling, and enumerates when-not cases: nothing_to_publish, a draft with a step lacking example output (refused without asking), and forms with no draft. It also names the prerequisite alternatives (load_trigger_samples, test_action, edit_source) and the order to use them.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources