get_report

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says the tool returns a report string or an error message, but does not disclose side effects, authorization needs, behavior when both parameters are omitted, or how workspace context affects the lookup. This is minimal transparency for a tool that accesses report data.

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 compact and front-loaded with the core purpose, followed by an Args section and Returns line. The formatting is scannable and the length is appropriate for a simple retrieval tool. Minor redundancy exists because the schema already marks both parameters as optional, but the overall structure is clean.

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 tool with two optional parameters, no required fields, no annotations, and no output schema, the description is incomplete. It does not specify whether report_id is effectively required for a meaningful call, what the returned string contains beyond 'report details', or how errors are surfaced. An agent would need to guess at the correct invocation pattern.

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 0%, so the description must compensate for the bare input schema. It adds useful semantics by stating workspace is a 'Name or ID' and that both parameters are optional, and it mentions a ctx argument, though ctx is not present in the schema. However, it does not explain the relationship between workspace and report_id or what happens if neither is provided, leaving important gaps.

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 a specific action and resource: 'Get a specific report by ID.' It is unambiguous about what the tool does and, by mentioning ID-based retrieval, it is implicitly distinct from list_reports. However, it does not explicitly name sibling tools or contrast them, so it stops short of a perfect score.

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 no guidance on when to use this tool versus alternatives like list_reports or report_export. It does not state prerequisites, whether a report_id is required, or when the workspace parameter should be supplied. This leaves the agent to infer usage from the tool name and one-line summary.

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