Get Traffic by Channel

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

Annotations declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavior: how channels are classified (from referrer domain and utm_medium/utm_source), default date range (last 30 days), limit default and max (100/1000), pagination via pagination.total, that all filter_* arguments apply, and authentication requirements (websiteId or domain with workspace token). This goes well 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 dense but every sentence serves a purpose: purpose, classification logic, usage guidance, row content, defaults, and auth. It is front-loaded with the core function, then progressively adds necessary context. 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?

For a tool with 27 parameters, 0 required, and an output schema present, the description covers all critical aspects: what is returned (rows with value, visitors, revenue, percentage), pagination details, default limits, filter applicability, and authentication. The output schema handles return structure, so the description is complete for agent decision-making.

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 each parameter is already described in the schema. The description adds context that all filter_* arguments apply and clarifies default date behavior (startAt/endAt default to 30 days). It also explains the websiteId/domain requirement. This adds value beyond the schema, so a 4 is appropriate.

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 groups visitors into GA4-aligned marketing channels, ranked by visitors, for a date range. It names specific channel examples and explicitly differentiates from sibling tools by stating what it is not (get_referrers, get_campaigns) and when to use them instead. The verb 'Get' and resource 'Traffic by Channel' are precise.

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?

Explicit guidance: 'Use this first for the traffic mix, then get_referrers for the domains behind Referral and Organic Social, or get_campaigns for tagged campaigns.' This tells the agent exactly when to use this tool and when to switch to alternatives, with clear routing logic.

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