read_thread

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

Annotations already provide readOnlyHint=true, covering the safety profile. The description adds that this requires a public channel (behavioral constraint) and returns root+all replies (scope), but doesn't disclose pagination, reply limits, or whether it fetches all reply levels recursively. With annotations covering safety, this is adequate but not rich.

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 tight: one purpose sentence, then a compact Args section leading with the critical public-channel constraint. No wasted words, front-loaded with the core action.

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?

With readOnlyHint annotation and an output schema present, the burden is reduced. The tool is simple (2 params, no nesting). The description covers purpose, param semantics, and the key public-channel constraint. Minor gaps like reply-depth behavior are not documented, but the output schema likely covers the return structure, so this is reasonably complete.

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 add meaning for both params: channel accepts 'id or #name' and must be public, and thread_ts is described as 'the root timestamp (the ts of the first message)'. A 0-coverage schema with this param documentation earns credit, though format details (timestamps in float vs string, etc.) are left 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 clearly states 'Read a full thread (root message + all replies) from a PUBLIC channel' with a specific verb+resource+scope. It distinguishes itself from siblings like read_channel_history (which reads the channel surface) by explicitly scoping to a thread.

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 clarifies this works on PUBLIC channels only, which is important guidance. It doesn't explicitly name alternatives or when-not-to-use, but the public-channel constraint and the nature of the operation give clear context against siblings like search_messages and read_channel_history.

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