Cross-network revenue overview

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the agent knows it's a safe, read-only operation. The description adds behavioral details such as default date range, handling of unconfigured networks, and currency conversion behavior, which adds value beyond the annotations.

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 description is two well-structured sentences. The first sentence clearly states the purpose and default behavior, and the second provides a key behavioral detail about unconfigured networks. No wasted words.

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?

The description covers the output concept (totals per network, grand total, daily breakdown) and mentions behavior for unconfigured networks. With 6 optional parameters and no output schema, the description gives enough high-level context for the agent to understand what the tool returns. Minor missing details on output format are acceptable given the read-only nature.

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 100%, so the baseline is 3. The tool description provides additional context on parameter interactions, such as 'days' being ignored when 'start_date' is set, and explains the default behavior for dates and currency. This adds meaning beyond the individual parameter 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?

The description clearly states the tool provides a combined ad revenue overview across Google AdMob and Huawei Petal Ads for a date range, including totals per network, grand total, and daily breakdown. It distinguishes from sibling tools like admob_network_report and petal_revenue_summary by being a cross-network overview.

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 gives useful guidance: it defaults to the last 7 days and notes that networks not configured are still reported without blocking others. While it doesn't explicitly state when not to use this tool, the context is clear enough for an agent to decide.

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