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

Goes well beyond the annotations: it discloses that calls bill against the user's Google quota, that the account must be connected first, the exact failure modes (invalid key, Google not connected, quota exhausted), and the return shape. It also flags a non-obvious behavior — thinking tokens count against max_tokens, so a low limit truncates output with finish_reason 'length' — which an agent could not infer from the 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?

Front-loads the model identity and the billing/routing distinction before the Args block, so an agent gets the decisive information in the first two lines. It is long, and the Args section partially duplicates schema field names, but with 0% schema coverage that repetition is doing real work rather than padding.

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 7-parameter open-world LLM call with no output schema, the description supplies return structure, error behavior, quota implications, and full parameter semantics — nothing essential for calling it correctly is missing. The only shortfall is the absence of model-selection guidance relative to the flash/sonnet siblings.

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 full burden and it does: every one of the 7 parameters is documented, including the messages role/content shape, the max_tokens range 1..65536, thinking_budget's special values (0 / -1 / N), thinking_level's allowed values and its precedence over thinking_budget, and the error semantics of account_email when the account is absent from the pool.

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+resource — a chat request to Gemini 3 Pro — and immediately qualifies the routing model: it runs through the user's own Google AI Pro subscription and Google account. This lets an agent tell it apart from chat_gemini_flash and chat_claude_sonnet without opening any schema, since the model and billing path are named explicitly.

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 a prerequisite ('подключите на /connect-google') and the cost implication ('Расходует вашу квоту Google, не наши токены'), which implies usage context but never states when to pick this over chat_gemini_flash or chat_claude_sonnet, nor any when-not-to-use condition. Usage is inferable from the model name rather than guided.

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