Skip to main content
Glama

create_playbook

Create a reusable content playbook — an ordered template of content-plan items ("save a repeatable content sequence"). Provide a name and, optionally, the ordered items; each item becomes one content plan when the playbook is instantiated.

Visibility: defaults to "team" (visible to all active teammates). Pass visibility "private" to keep it creator-only.

Anchor date: if the user is building this playbook around a specific real date (a launch, an event, a campaign kickoff), offer to set anchor_date — it's the reference point every item's offset_days counts from, and it becomes the default when they instantiate. It's optional; leave it off for an evergreen/undated template.

The response includes link_url — share it so the user can open the playbook you just created.

When to use: when the user wants to author or save a reusable template/playbook of content plans from scratch (e.g. "make me a launch-week playbook", "save this sequence as a template"). To build a playbook from plans the user already ran, use create_playbook_from_plans instead.

**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": {
      "name": "<name>"
    },
    "name": "create_playbook"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesThe playbook's title, shown wherever someone browses or picks a playbook to run. Required and trimmed — a blank or whitespace-only value is rejected. It is also the base of the auto-generated cycle name every time the playbook is run ("<name> — Mon YYYY").
itemsNoThe ordered steps of the playbook — each entry becomes exactly one content plan when the playbook is run. Every entry needs a `name` (`title` is accepted as an alias) and may also carry description, prompt, blueprint_id, category_id, offset_days and sort_order; array order sets the sequence unless sort_order is given. Optional — omit it to save an empty shell you fill in later, but a playbook with no items cannot be run until you add some.
visibilityNoOptional. Defaults to "team". "private" keeps the playbook creator-only.
anchor_dateNoOptional YYYY-MM-DD anchor date this playbook is built around (e.g. a launch date). Each item's offset_days counts from it, and it becomes the default anchor when instantiating. Offer to set this when the user has a specific date in mind; omit or null for an evergreen/undated template.
descriptionNoOptional free-text note saying what this playbook is for and when to run it, for teammates browsing the playbook list. It is stored on the playbook only and is never fed into content generation; omit it and it is saved empty.

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.4/5.0
Behavior4/5

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

Annotations already declare a non-read-only, non-destructive, non-idempotent, closed-world create, so the safety profile is covered. The description adds real behavioral context beyond that: the visibility default of 'team', the fact that an items-less playbook is a shell that cannot be run, and that the response carries a link_url to share. It stops short of permissions/team-scoping or duplicate-name behavior, keeping it from a 5.

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 the core purpose, then visibility, anchor date, response, and when-to-use in a scannable order; no sentence is filler. It runs slightly long, with a trailing link-handling instruction block that is boilerplate relative to the creation task.

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 5-parameter create tool with an output schema, the description covers the optionality of items, the empty-shell caveat, visibility defaults, anchor-date semantics and sibling routing. Nothing an agent needs in order 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents name, items, visibility, anchor_date and description in detail; the baseline of 3 applies. The description reinforces the anchor_date/offset_days relationship and the visibility default, but this largely restates what the schema says rather than adding new semantics.

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+resource ('Create a reusable content playbook') and immediately defines the artifact as an ordered template of content-plan items, including what happens on instantiation. It explicitly distinguishes itself from the closest sibling, create_playbook_from_plans, so an agent can route correctly 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?

There is an explicit 'When to use' section with concrete trigger phrasing ('make me a launch-week playbook', 'save this sequence as a template') and a named negative case: build from existing plans via create_playbook_from_plans instead. It also gives conditional guidance for anchor_date (offer it only when a real date exists, omit for evergreen templates).

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