Get daily statistics

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds behavioral context by specifying the aggregation granularity (per day) and the metrics (min, max, average, p95), which goes beyond the annotations. It doesn't mention pagination or default date ranges, but the schema covers those. Given the strong annotation coverage, a 4 is appropriate for the added context about the data shape.

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 two sentences, front-loaded with the core purpose, and every sentence earns its place. The first sentence states what it does, the second provides usage guidance and points to the alternative. No fluff, no repetition of schema details. This is a model of conciseness.

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?

The tool has a rich output schema (not shown but indicated), 100% schema coverage, and strong annotations. The description covers the key behavioral aspects: daily aggregation, metrics, and comparison use case. It doesn't explicitly mention pagination or default date ranges, but those are in the schema. For a read-only reporting tool with good structured metadata, the description is complete enough. A 4 is justified because it could mention the output format (e.g., array of daily records) but the output schema likely covers that.

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 100%, so all four parameters (monitorId, dateFrom, dateTo, page) are already documented in the schema with descriptions. The tool description doesn't add parameter-specific semantics beyond what the schema provides, but it does clarify the overall purpose of the date range (daily aggregation) and the monitorId context. Per the rubric, with high schema coverage, baseline is 3, and the description doesn't significantly exceed that.

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's purpose: 'Response time and uptime for one monitor aggregated per day, with min, max, average and p95.' It specifies the resource (one monitor), the aggregation level (per day), and the metrics included. It also distinguishes itself from siblings by noting it's for reports/trends over weeks/months and comparing monitors, while get_stats_hourly is for zooming into a single day.

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 provides explicit usage guidance: 'This is the tool for reports and trends over weeks or months, and for comparing one monitor against another over the same window. When a single day looks wrong, zoom into it with get_stats_hourly.' This clearly states when to use this tool and when to use the alternative (get_stats_hourly), which is exactly what the dimension asks for.

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