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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds that the response bundles live state (open approval requests) and a deterministic prompt review, which is useful context, but it discloses no behavior beyond payload contents and that payload is also described by the output schema.

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?

A single dense sentence, front-loaded with the core statement and then the field inventory, with no filler. The field list is long enough to be slightly list-like but each item earns its place by previewing the response.

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 one parameter, a full output schema, and complete annotations, the description covers what an agent needs to call this correctly. Return-value explanation is largely delegated to the output schema as intended, leaving only minor gaps around when the two id forms differ in behavior.

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 carry the parameter, and it does: 'default' selects the organization chatbot while any other value is a rule bot id sourced from list_bots. That is real semantic meaning beyond the bare regex pattern, missing only a note that rule bot ids are numeric.

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?

"One bot in full" plus an enumeration of exactly what is returned (persona, rule and trigger, on/off state, open approval requests, prompt review) makes the retrieval target unambiguous. It also implicitly separates itself from list_bots by referencing it as the id source, though the verb itself is elided rather than stated.

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 tells the agent where to get the id (list_bots) and the special 'default' value, which implies the use case of fetching one bot's details. It never states explicitly when to prefer this over list_bots or list_bot_conversations, so the routing is inferred rather than stated.

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