cancel_scheduled_postCancel one post that is waiting to go out, by id from list_scheduled_posts. Only works while the post is still waiting; the take becomes approvable again. Confirm with the user before calling this — it withdraws something they approved.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The post's id, from list_scheduled_posts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, but the description adds important context: the post withdraws something the user approved, becomes approvable again, and requires user confirmation before calling. This goes beyond the annotation and explains the consequence of the destructive action.
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?
The description is three sentences long, with every sentence adding value: the action, an operational constraint, and a user-consent requirement. There is no redundant wording or filler.
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 tool with a single parameter and no output schema, the description covers all essential operational aspects: when it is valid, the effect on the post, and the required user confirmation. It is complete for its simplicity.
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?
The only parameter 'id' is fully described in the schema with 'The post's id, from list_scheduled_posts.' The description repeats this same source instruction without adding new semantics beyond the schema, so the baseline of 3 for 100% schema coverage is appropriate.
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 states 'Cancel one post that is waiting to go out' with a specific verb and resource. It also names the source of the id, list_scheduled_posts, which distinguishes it from siblings like retry_scheduled_post.
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 description explicitly states a key usage condition: 'Only works while the post is still waiting.' It also implies when to use by saying the take becomes approvable again. It does not explicitly name alternatives, but the constraint is clear.
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.
Each tool targets a distinct resource-action pair: planning (add, edit, archive, list, get, reorder), teleprompter delivery (send), and scheduled posts (list, cancel, retry). Even closely named tools like get_planned_scripts vs list_planned_scripts are clearly separated by metadata vs full-text purpose. No two tools overlap in function.
Names are uniformly snake_case and follow a verb_noun pattern, but there is slight inconsistency: 'add_scripts_to_plan' uses a prepositional phrase while similar operations use past-participle adjectives ('edit_planned_scripts', 'archive_planned_scripts'). Verb choices like list vs get are consistent with their functions. Minor deviations prevent a perfect score but the pattern is highly predictable.
12 tools is well within the ideal 3-15 range for a focused domain. Each tool covers a clear need for content planning and teleprompter delivery without bloat or missing essentials. The count feels appropriately scoped for the server's purpose.
The toolset offers full lifecycle coverage for content plans (create, read, update, delete via archive, reorder) and scheduled posts (list, cancel, retry), with connected account listing for context. The only seemingly absent operation—permanent deletion—is intentionally excluded for safety. Read and write paths are complete, and the design prevents dead ends.