Skip to main content
Glama

update_playbook

DestructiveIdempotent

Edit a content playbook. Any playbook is fully editable (no lock-in) — imported or authored alike. Pass only the fields to change: name and/or description patch in place. If items is provided it FULLY REPLACES the playbook's items and their order; omit items to leave them untouched. Changing visibility ("private" | "team") is CREATOR-ONLY — non-creators get InputError.

When to use: when the user wants to rename, re-describe, or restructure a saved playbook — reorder, add, remove, or rewrite its items (e.g. "add a follow-up email to my launch playbook", "reorder these steps").

**Links:** present `link_url` to the user exactly as returned — copy it character for character. Never retype, shorten, or rebuild a link or the IDs inside it.

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": {
      "playbook_id": "<playbook_id>"
    },
    "name": "update_playbook"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoOmit to keep the current name (it cannot be cleared — playbooks always have a name).
itemsNoFull replacement set of ordered items. Omit to keep existing items.
visibilityNoChange the playbook's visibility. Creator-only — non-creators get InputError.
anchor_dateNoOptional YYYY-MM-DD anchor date the playbook is built around. Omit to KEEP the current value; pass null to CLEAR it. Each item's offset_days counts from it, and it's the default anchor when instantiating.
descriptionNoOmit to KEEP the current description; pass null to CLEAR it.
playbook_idYesNumeric id of the playbook to edit — the `id` from list_playbooks or get_playbook, or the trailing number in its link_url, not a UUID. It only selects which playbook to change and is never itself modified. Unknown ids, playbooks in another team, and teammates' private playbooks all return NotFound.

Output Schema

NameRequiredDescriptionDefault
idNo
nameNo
itemsNo
team_idNo
link_urlNoURL to open this playbook in the Marcora web app — share it so the user can view what you created.
created_atNoUnix ms timestamp.
created_byNo
updated_atNoUnix ms timestamp.
visibilityNoprivate = creator-only; team = visible to all active teammates.
anchor_dateNoPersisted YYYY-MM-DD anchor date, or null. Each item's offset_days counts from it; it's the default when instantiating.
descriptionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The description adds substantial behavior beyond the annotations: items are a full-replacement set, omitting fields preserves them, visibility changes are creator-only with InputError for non-creators, and unknown or inaccessible playbooks return NotFound. These details clarify the destructive and idempotent hints rather than contradicting them.

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 core edit semantics, then provides a clearly labeled usage section and a targeted link-handling note. Each sentence contributes operational guidance without excessive repetition.

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?

Given the mutation complexity, nested item replacement, permissions, and error cases, the description covers what an agent needs to call the tool correctly. An output schema exists, so the description does not need to explain return values.

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 parameter descriptions already carry much of the load. The tool description still adds cross-parameter semantics: 'Pass only the fields to change,' the distinction between patching scalar fields and fully replacing items, and the creator-only constraint on visibility.

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 opens with a specific verb and resource: 'Edit a content playbook.' It immediately distinguishes update behavior by explaining partial patching, full item replacement, and visibility changes, so an agent can identify the tool's role 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It includes an explicit 'When to use' section with concrete examples such as renaming, reordering steps, and adding a follow-up email. It does not explicitly name alternatives like create_playbook or instantiate_playbook, so the agent must infer when those are preferable.

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