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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds real behavioral context the annotations do not: result ordering (newest first), the cursor pagination contract including that next_cursor is null on the last page, and that bot traffic is included by default. It stops short of mentioning page-size limits or rate limits, but with no output schema the pagination disclosure is the most valuable piece.

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?

Roughly two clauses, zero filler, and the most decision-relevant facts (raw rows, newest first, cursor-paginated) are front-loaded. The bot default is appended efficiently, though the single run-on sentence with a colon splice is slightly dense for the amount of contract it conveys.

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 61-parameter read tool with no output schema, the description covers the return-shape essentials: row granularity, ordering, and pagination termination. It omits that all filters are optional and intersect, leaves the 12 sub-slots and tag filters entirely to the schema, and says nothing about result volume or performance characteristics of unfiltered calls.

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 89%, so most of the 61 filter parameters are already documented in the schema itself. The description only reinforces one parameter behavior — bots counted by default unless exclude_bots is set — which the schema also states. It adds no semantics for the 12 sub-slots, tag filters, period/custom date pairing, or how filters combine.

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 resource and shape: "Raw click rows, newest first, cursor-paginated." An agent can tell this returns individual click records rather than aggregates, which implicitly separates it from get_statistics or get_report. It never names the closest sibling, get_click, so the distinction from that single-record tool must be inferred.

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 only implied by the word "raw" — use this when per-click detail is needed rather than aggregated stats. There is no explicit when-to-use or when-not guidance, no mention that get_click is preferable when a click_id is already known, and no note on permission prerequisites beyond what the schema carries for the user parameter.

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