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

Annotations already declare destructiveHint=true, openWorldHint=true and non-idempotent, so the safety bar is partly covered; the description still adds real value by disclosing that calls run under the team's saved credentials which "never enter the chat". It does not warn that invoking an arbitrary team tool can mutate external state or be non-idempotent, and the timeout sentence introduces "the same ids" even though the schema has no id parameter, which muddies rather than clarifies behavior.

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 definition is front-loaded: resource, then both modes, then the exclusion. Most sentences earn their place, but the final timeout/poll sentence is underspecified and references ids this tool does not accept, consuming space without adding actionable clarity.

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 no output schema, the description usefully characterizes what listing returns ("each one with its tools, their inputs and the exact call"), which is what an agent needs before it can construct a call. Given a two-parameter, open-world dispatch tool with a free-form nested `arguments` object, the main residual gap is that reverse path — how to shape `arguments` for a specific listed tool — plus the ambiguous polling instruction.

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% and the schema descriptions already say `tool` is "<key>/<tool name>" from the list and `arguments` are the tool's arguments. The description restates that same contract rather than extending it — for example it gives no guidance on how `arguments` must be shaped for a nested tool schema. Baseline 3 applies when the schema carries the semantics.

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 opening sentence names the resource precisely ("This team's own tools: the APIs and MCP servers the team added") and the two verbs it supports — list when `tool` is omitted, call when it is supplied. It also names the specific sibling it is not (capability_search), so an agent can route correctly without opening either schema.

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?

Both modes are stated with their triggering condition ("Without tool, lists...", "With tool ... and arguments, calls it"), and an explicit NOT-for exclusion points to capability_search. This is the strongest part of the definition; the only weak spot is the trailing polling advice, which is ambiguous rather than missing.

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