wafle_ads_compare_periods

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

Annotations declare readOnlyHint=true and idempotentHint=true, so the read-only nature is already known. The description adds valuable context: 'Both ranges are evaluated against the wafle CAPI server-side truth' and explains why this ensures honest comparisons. This goes beyond the annotations by clarifying the data source and reliability motivation.

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 sentences, front-loaded with the core purpose and metrics. It efficiently includes examples, data-source rationale, and constraints without redundancy. Every sentence earns its place.

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 tool's purpose, usage scenarios, metrics, data-source semantics, and a key constraint. Since there is no output schema, it reasonably lists the metrics returned (spend, revenue, ROAS, CPA, conversions, profit) but could be slightly more specific about the output structure. Overall, it is sufficiently complete for an agent to select and invoke the tool correctly.

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 only 33% (only slug has a direct top-level description). The tool description compensates by clarifying the relationship between period_a ('newer') and period_b ('baseline'), providing examples of acceptable formats, and adding the crucial non-overlap constraint. It also lists the metrics returned, which helps interpret the periods.

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's function: 'Compare two date ranges ... and return delta % per metric: spend, revenue, ROAS, CPA, conversions, profit.' It is specific about the operation (compare) and the resource (ad periods), and it differentiates itself from sibling tools by focusing on comparison rather than a single-period summary.

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?

Provides explicit use cases: 'Use to answer "how did April do vs March?" or "did the new creative pack improve things in the last 14 days vs the prior 14?"' It also explains why this tool is preferable (CAPI server-side truth vs Meta's pixel drift) and includes a constraint (windows must not overlap). It does not name alternative sibling tools but gives clear contextual guidance.

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