add_playbook_pagesAdd pages to the Playbook, as the Import's Add pages does: each { title, body, parent, children } — body is plain text of facts; parent, on a top page, is the title of the existing page to place it under (none: the book's root); children nest up to three levels. Pass the pages propose_playbook_pages answered, as kept or changed. Each page is saved under whoever adds it.
| Name | Required | Description | Default |
|---|---|---|---|
| pages | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a non-read-only, non-idempotent write (readOnlyHint=false, idempotentHint=false). The description adds genuinely new behavioral detail beyond the annotations: pages are attributed to "whoever adds it," and nesting is bounded to three levels. It stops short of stating append-vs-replace behavior or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first clause, followed by the object shape and the workflow hook; the whole thing is a tight, information-dense block. The "as the Import's Add pages does" analogy is mildly referential but still earns its place by anchoring the behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation with an opaque schema and no output schema, the description covers the essential object structure and attribution. It omits edge cases an agent might need: whether referenced parents must pre-exist, error/partial-failure behavior on a multi-page batch, and the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single parameter is an untyped array of objects, so the schema gives almost nothing. The description compensates well by spelling out the per-page shape { title, body, parent, children } and the exact meaning of body and parent, which the schema cannot convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Add pages to the Playbook") and ties it to a known flow ("as the Import's Add pages does"), so an agent grasps the operation immediately. It also implicitly distinguishes itself from propose_playbook_pages, though it never explicitly contrasts with the single-page sibling write_a_playbook_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction "Pass the pages propose_playbook_pages answered, as kept or changed" establishes a clear workflow precondition (this tool consumes the proposal output). However, there is no explicit when-not-to-use guidance, and no contrast against write_a_playbook_page, so an agent must infer which page-writing tool to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.