get_report

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds that it returns 'metadata and definition', which gives a bit more insight into the response content, but it does not disclose any additional behaviors such as error handling, permissions, or output details. Since annotations handle safety, the description adds limited but non-trivial context, so a 3 is appropriate.

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 a single, compact sentence that immediately captures the core function. There is zero redundancy, and it is front-loaded with the action verb. Every word contributes meaning, making it an exemplary concise description.

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?

Given the tool's simplicity (one parameter), the presence of an output schema, and the strong annotations, the description is complete enough for an agent to understand what the tool does. It clearly states the purpose and relies on schema/annotations for technical details. It does not discuss edge cases or error behavior, but for a read-only getter with output schema, this is sufficient. A 4 is appropriate.

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?

The schema description covers 100% of the only parameter (report_id) with 'ID of the report.' The tool description does not add any additional semantics for the parameter, relying entirely on the schema. Given the high coverage, a baseline of 3 is warranted, and the description does not go beyond 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 states the verb 'Get' and the resource 'a Visual Analytics report's metadata and definition', which clearly identifies the tool's action and target. While it doesn't explicitly differentiate from siblings like 'get_report_outline' or 'describe_report_objects', the phrase 'metadata and definition' adds specificity that helps distinguish it. It is clear, but not strongly contrastive with alternatives.

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 does not provide any guidance on when to use this tool versus alternatives. It simply states what it does without mentioning conditions, prerequisites, or exclusions. There is no reference to sibling tools or use cases where another tool would be more appropriate, leaving the agent without explicit usage direction.

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