Get report

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

With readOnlyHint, idempotentHint and destructiveHint already declared, the description usefully adds behavior annotations do not cover: results are paged, completeness must be checked via the continuation token and scope.has_more, and report names/metadata are untrusted data. The prompt-injection warning is genuinely valuable context for an agent handling returned strings.

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?

Three short sentences, each load-bearing: what it returns, how to paginate correctly, and a safety caveat. The core purpose is front-loaded with zero 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?

No output schema exists, so the description carries the burden of describing the return surface, and it does so partially by naming continuation token and scope.has_more. It doesn't explain the row shape or what the report metadata contains, but for a bounded read tool this is close to sufficient.

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 all four parameters are already documented. The description notes that metric filters limit row data, which is a mild restatement of the metric_ids schema text, and adds nothing about report_id or page_token syntax. Baseline 3 is appropriate when the schema does the heavy lifting.

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 opens with a specific verb and resource ('Retrieve one saved evaluation report') and adds the key scope detail that the result is a bounded page of rows, which separates it from the plural list_reports sibling. It never names the sibling explicitly, so differentiation is inferred rather than stated.

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 gives operational guidance for pagination ('inspect the continuation token and scope.has_more before assuming the report is complete') but says nothing about when to use this tool versus list_reports or get_metric. The when-to-use case is only implied by the singular 'one saved evaluation report'.

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