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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this ('nothing called here changes anything'), which is consistent rather than contradictory. It adds value beyond the annotations by disclosing cost behavior (list_tools/get_tool_schema are free, execute bills the tool) and the 20-account fan-out cap. It does not describe return shape or error behavior, but with no output schema that is a minor gap for a router.

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?

Purpose and the write-sibling boundary are front-loaded, followed by the invocation pattern and a compact category map of routable tool names. The categorized tool list is dense but earns its place by telling the agent what it can reach; a little tightening of the repeated 'free like every read' phrasing would help.

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?

For a dispatcher with a nested arguments object and no output schema, the description supplies everything needed to invoke correctly: the action enum semantics, the accounts behavior/cap, the exactness requirement on tool_name, cost model, and the set of reachable tools plus the one read that lives outside the router.

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 meaningfully enriches the schema: it explains that accounts produces 'one read across up to 20 accounts' that is free, and stresses that tool_name must be exact and never guessed. This adds operational meaning beyond the field descriptions.

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 ('Reads and tool lookup for ChatGPT Ads') and immediately draws the boundary against its write sibling: 'The 13 ChatGPT Ads tools that change something run through chatgpt_ads_write.' An agent can tell this router apart from chatgpt_ads_write and chatgpt_get_performance without opening any 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?

Gives explicit routing rules: use action='list_tools' / 'get_tool_schema' (free) before executing, 'never guess a tool_name', and names the sibling called outside this router (chatgpt_get_performance). The free-vs-billed distinction for reads versus execute is stated outright.

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