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

No annotations are provided, so the description carries full burden. It discloses the write-tier nature, approval requirements ('first use may require a manager's approval; a from-now-on approval makes future calls seamless, a just-once approval re-asks next time'), and the effect of agreed=false ('clear the seal'). Also notes that Structured Plays refuse Run until this exists. This is rich behavioral context beyond simple mutation.

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?

Front-loads the core purpose, then gives routing and approval context. It's a bit long but each sentence earns its place, covering usage, effect, and approval. The routing line is redundant with the first sentence but adds clarity.

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?

Complete for a mutation tool: it explains the prerequisite (get_playbook), the consequence (run_playbook can dispatch), the effect on other tools (Structured Plays refuse Run), and the approval flow. With no output schema, it doesn't explicitly state the return value, but that's minor. The description covers the needed context well.

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 coverage is 100%, so the schema documents all params. The description adds meaning for 'agreed' ('Default true. Pass false to clear the seal (required after the plan changes)') which supplements the schema. Also clarifies the alternative identification params (tactic_id or tactic_title). While the schema covers these, the description adds practical usage context.

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?

Clear and specific: 'Seal a Playbook plan... so run_playbook can dispatch.' Names the resource (source_details.plan_agreed_at) and the action (seal), and distinguishes from run_playbook and get_playbook. Also mentions it's the same seal Focus writes, adding context.

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?

Explicitly states when to use: 'Use after get_playbook when the steps look right.' Also routes: 'Agree who does what on a Playbook → use this, then run_playbook.' This clear progression guides the agent compared to the numerous siblings.

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