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

With no annotations, the description carries full burden and delivers: it enumerates the exact return contents (campaign metadata, Klaviyo attribution claim, Shopify orders/revenue/new-customers, baseline counterfactual, lift, attributionAnalysis), discloses the baseline methodology and its rationale, and explains the disambiguation behavior when campaignName matches multiple records.

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 purpose and methodology, then examples, then the PREFER statement, then parameter guidance — logical ordering. It is dense and long, but most sentences earn their place; the opening rhetorical question is a minor stylistic indulgence.

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 complex no-annotation, no-output-schema synthesis tool, the description covers purpose, methodology, return shape, behavioral edge cases (disambiguation), alternative routing, and parameter tuning — everything an agent needs to call it correctly and interpret the result.

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 already 100%, but the description adds genuine value beyond it: it explains the campaignId vs campaignName trade-off (exact vs fuzzy, returns most recent match plus disambiguation block), and justifies the 7-day default with the contrast against Klaviyo's 5-day attribution window and the high-AOV extension case.

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 ('measures the real impact of a specific Klaviyo campaign') and explicitly names the methodology (day-of-week-aligned baseline, post-send window vs same N days one week earlier). Clearly distinguished from siblings like get_marketing_performance and get_store_summary by its cross-source synthesis framing.

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 concrete example queries ('did the SUMMER20 campaign work?', 'is my abandoned-cart flow driving revenue?') and an explicit PREFER-over instruction naming the alternative workflow (get_connector_data + get_store_summary) and why not to use it. Also gives tuning guidance for windowDays.

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