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

Goes well beyond the annotations (readOnly/idempotent/closed-world) by disclosing source caps of 5000 first-touch events and 2000 facts with fail-closed behavior, a response limited to the last 100 sessions/requests with truncation flags, required scopes operations:read and accounting:read, and the POST transport. It also flags that capture completeness and test exclusion are not_attested and that zero recorded does not mean zero actual, which is exactly the caveat an agent needs.

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-loaded with the core read statement, then constraints, caveats, permissions and transport in a logical order. It is dense and semicolon-heavy with several clauses packed into single sentences, which costs a little readability, but no clause is filler.

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?

With no output schema, the description still characterizes the return (last 100 sessions/requests plus truncation flags) and adds scope requirements, caps, and explicit non-claims. For a two-parameter read tool with a rich caveat surface, an agent has everything needed to call it and interpret the result 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 0%, so the description must carry the parameter meaning and it does: from/until are optional UTC, half-open, defaulting to 30 days with a 366-day maximum. That supplies interval semantics and default behavior the bare pattern-only schema cannot express.

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: reads tenant-bound first-touch, request, offer, checkout and original primary payment evidence for an attribution audit. The funnel-stage scope makes the resource concrete. It does not explicitly distinguish itself from sibling evidence tools such as get_search_ads_evidence or get_ai_visibility, so it stops short of a 5.

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?

Usage is implied through the audit framing and the explicit scope limits (default 30 days, max 366 days, optional from/until), and the negatives ('no unique-human, conversion, retained revenue or profit claim') hint at what the tool is not for. However, there is no explicit when-to-use statement or named alternative for narrower attribution questions, leaving routing to inference.

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