Replace a pending growth move's marketing draft body before shipping. A draft carrying an unfilled placeholder or a broken link is refused rather than saved. Free; requires the 'act' scope.
| Name | Required | Description | Default |
|---|---|---|---|
| move_id | Yes | Move id (uuid), from list_feed. | |
| draft_content | Yes | The replacement draft body, 1 to 20000 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only and non-destructive, so mutation is implied. The description adds useful behaviors: validation refuses drafts with unfilled placeholders or broken links, cost is free, and requires 'act' scope. This goes beyond what annotations provide.
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?
Two sentences, front-loaded with the main action, no filler. Every word earns its place.
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?
Given the tool's simplicity (2 params, no output schema), the description covers the action, validation behavior, cost, and auth. It doesn't describe the success response, but that's not required. Slightly more could be said about return values, but overall complete.
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 covers both params at 100%, giving a baseline of 3. The description adds context: move_id refers to a pending growth move and draft_content is the marketing draft body. It also clarifies validation criteria, adding meaning beyond the schema.
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?
The description clearly states the action: 'Replace a pending growth move's marketing draft body before shipping.' The verb 'Replace' plus resource 'draft body' and context 'before shipping' distinguish it from siblings like ship_move or redraft_output.
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?
It explains when to use: before shipping a pending move, and what validation will occur (invalid drafts refused). It doesn't explicitly name alternatives, but the 'before shipping' context implies timing relative to ship_move. Lacks explicit exclusions but is sufficient.
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.
Most tools have clearly distinct purposes, and descriptions are thorough. A few pairs (e.g., ship_move vs set_output_status, dismiss_gap vs skip_move) overlap on the dismissal concept but operate on different surfaces, so an agent can usually tell them apart with careful reading.
All tool names follow the same snake_case verb_noun pattern (e.g., get_move, create_checkout, untrack_prompt). Retrieval tools consistently use get_ for single items and list_ for collections, and action verbs are precise, so the naming is fully predictable.
42 tools is heavy by any standard, exceeding the 25+ threshold in the calibration. While each tool may earn its place given the breadth of the domain, the sheer number will overwhelm an agent and complicate tool selection.
The tool set covers the main lifecycles well: moves (list/get/ship/skip/archive/undo/update), outputs (list/get/ship/redraft), connections (list/start/poll/disconnect), prompts (track/untrack/list), and scans (refresh/get/set intensity). Minor gaps exist, such as no direct edit for KB pages, but record_insight partially fills that.