List traffic snapshots

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

Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so safety profile is clear. The description adds meaningful context that snapshots come specifically from 'the project's own connected analytics accounts' — establishing a data-provenance boundary that's genuinely useful beyond 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?

Single efficient sentence that conveys source, resource type, and filtering options. Compact and front-loaded, though it could add a bit more practical guidance without bloating.

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?

No output schema and moderate parameter count (6). The description conveys what the tool does and its source scope but doesn't clarify return format, sorting, pagination behavior, or whether date range is inclusive — gaps for an agent deciding how to paginate a potentially large result set.

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 50% (end_date, start_date, project_id are described). The 3 undocumented params (limit, offset, paths) are self-evident pagination and filter controls whose meaning is clear from names and schema constraints. Description adds no param-level detail beyond what the schema provides, so baseline 3 applies.

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?

Specific verb 'list' + resource 'stored page traffic snapshots' + clear scoping ('project's own connected analytics accounts', 'date range', 'optional page paths'). Distinguishes it from sibling tools like list_search_performance_query_stats and sync_project_traffic.

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?

The description states what data it returns (project's own connected analytics accounts) and filtering criteria. It doesn't explicitly contrast with alternative tools like sync_project_traffic or list_search_performance_query_stats, so usage context is implied rather than explicitly compared against siblings.

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