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

Annotations already establish readOnlyHint=true, and the description adds real context beyond that: results are paginated as a window with next_offset, and include_agents produces a larger reply and switches the underlying endpoint. It does not mention ordering guarantees or a total count, but the key behavioral traits are covered.

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?

Three short, front-loaded clauses with no filler: returned fields first, then the include_agents behavior, then pagination and endpoint. Every sentence carries information the agent needs.

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 supplies the shape of the return (field list, pagination window, next_offset). For a simple read-list tool this is nearly complete; only ordering or total-count behavior is left unstated.

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 baseline is 3, but the description goes further by explaining what include_agents does to the response size and endpoint, and by tying offset to the previous call's next_offset. That adds meaning beyond the schema's own per-parameter text.

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 and resource ('List teams') and enumerates the returned fields (team_id, name, address, tags), plus the endpoint variant used. The resource is clearly distinct from siblings like tookan_list_agents, though it doesn't explicitly contrast with them.

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 is implied rather than stated: 'With include_agents, each team also lists its agents' tells the agent how to expand results, and the offset explanation says to reuse next_offset. There is no explicit when-to-use-this-vs-sibling guidance or when-not-to-use conditions.

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