retry_scheduled_postPut one failed post back in the queue, due now — by id from list_scheduled_posts. Use it after the cause in the failure sentence is fixed (say, a reconnected account). The post goes out within about five minutes.
| 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 indicate idempotentHint=true, and the description adds that the post goes out within about five minutes. It also mentions it's a single post (one failed post), complementing the annotations. No contradiction; the description adds temporal behavior beyond annotations.
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, all with purpose: states the action, specifies the condition, and notes the timing. No filler, front-loaded with the verb and object.
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 a single parameter, high schema coverage, idempotent annotation, and no output schema, the description is sufficient. It covers the trigger condition and expected behavior, though it doesn't detail what happens on failure or idempotency implications, but that's not required given context.
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 100% of the parameter with a detailed description ('The post's id, from list_scheduled_posts.') and maxLength. The tool description repeats the source ('by id from list_scheduled_posts') but doesn't add new semantics beyond the schema, so baseline 3 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 clearly states the tool's purpose: to put a failed post back in the queue, with the specific condition of being due now and referenced by id. It distinguishes itself from siblings by specifying it operates on a failed post from list_scheduled_posts.
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 explicitly states when to use it: after the cause in the failure sentence is fixed (e.g., reconnected account). It also implies not to use it before fixing the cause, and provides context on the timing (about five minutes). This gives clear usage guidance.
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.