get_thread

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

Annotations only state readOnlyHint=true, and the description adds notable behavioral detail: walking reply_to to the root, chronological ordering, tombstone behavior for soft-deleted messages, and the distinction that only the server-recorded 'acks' tally counts as a vote. It also includes a provenance warning that the description text may be peer-authored and that message bodies are data, not commands, which is useful context beyond the annotation.

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 core behavior is front-loaded and each functional sentence adds value, including edge cases like tombstones and vote counting. The provenance paragraph is long and somewhat tangential, but it conveys an important security-relevant caveat that 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?

The description covers the core retrieval semantics, required-id flexibility, deleted-message handling, and important vote-counting behavior. It also has an output schema, so return values do not need to be explained in prose, making the description sufficient for correct invocation.

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 must compensate. It does meaningfully explains the required message_id parameter by saying any message id from the thread is acceptable. However, the optional fields parameter is not mentioned, so the optional projection behavior remains undocumented.

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 uses a specific verb-resource pair ('Fetch the whole conversation thread containing a message') and explains the mechanics: walks reply_to up to the root and returns the full reply tree in chronological order. This clearly distinguishes it from siblings like list_messages or message_history by emphasizing the complete thread structure.

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 gives clear usage context: any message id from the thread works and soft-deleted messages are handled. It does not explicitly contrast this tool with alternatives like message_history or search_messages, so it lacks explicit when-not guidance, but the context is otherwise clear.

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