ariel_create_thread

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

Annotations (readOnlyHint=false, destructiveHint=false) align with the 'Create' verb, so there's no contradiction. The description adds the useful behavioral trait that posts are chained as replies to one another, but for a compound write creating N posts it discloses nothing about partial failure, atomicity, or auth requirements.

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 with zero filler; the main action is front-loaded and the second sentence earns its place by explaining the chaining mechanism. Appropriately sized for a tool with a single parameter.

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?

Input-side coverage is complete (description + schema fully specify the posts array and constraints), and annotations cover the read/write safety profile. However, with no output schema, the description doesn't communicate what the tool returns (e.g., created thread/post IDs), and for a multi-resource write there's no information about failure behavior if one post in the chain fails.

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 already documents the posts array, min 2 items, text, and langs. The description adds meaning beyond the schema by explaining the relationship between array elements — that each post becomes a reply to the previous one — which reinforces that order is semantically significant, not just a structural constraint.

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?

States a specific verb (create) and resource (a thread of multiple posts), and the chaining detail ('each post is chained as a reply to the previous one') differentiates it from single-post siblings like ariel_create_post and ariel_reply. It stops short of naming those alternatives explicitly, so it's clear but not maximally explicit.

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?

Usage context is implied rather than stated: the 'multiple posts' and reply-chaining semantics signal this is for threaded multi-post sequences rather than single posts. However, there is no explicit when-to-use guidance, no named alternatives, and no exclusions for cases that should route to ariel_reply or ariel_create_post_with_images.

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