Create thread draft

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

With no annotations provided, the description carries the full burden and does well: it discloses that posts chain as replies (Bluesky reply refs, X in_reply_to), that each post has text and up to 4 images, validation occurs per platform, and nothing publishes until explicit confirmation. It does not mention error scenarios or how drafts are saved, but for a draft-creation tool this is solid transparency.

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: first states the action, second explains thread chaining and per-post content, third clarifies the publish flow. Every sentence earns its place with no filler, and key details are front-loaded.

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 2-parameter tool with no output schema and no annotations, the description provides a solid picture of thread structure, chaining, validation, and the publish gate. It lacks explicit mention of min/max posts (though 'multi-post' implies min 2) and doesn't detail platform-specific rules beyond validation, but overall it is sufficiently complete for typical use.

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%, so the description adds value by explaining that 'posts' items each have text and up to 4 images, which enriches the schema's generic 'media' array. However, the 'platforms' parameter is not explained beyond 'validated per platform,' leaving room for more clarity. Still, it meaningfully compensates for the schema gap.

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 begins with 'Create a multi-post thread draft,' a specific verb+resource statement that clearly distinguishes this tool from sibling create_post_draft. It elaborates on the thread chaining behavior (replies under first post) and mentions per-post text and images, making the purpose unmistakable.

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 implies usage for multi-post threads and emphasizes that nothing is published until publish_post with confirm: true, providing clear context for the drafting vs publishing workflow. However, it does not explicitly name alternatives like create_post_draft for single posts or explicitly state when not to use this tool, leaving a slight gap in explicit exclusion guidance.

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