get_run_events

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered. The description adds the 'ordered' qualifier, which is a useful behavioral detail (ordering guarantee) not evident from annotations alone. However, it doesn't disclose return limits, pagination behavior, or whether the event stream is complete vs partial.

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?

A single short sentence with zero wasted words. It's appropriately terse for a simple one-parameter tool. No redundancy or 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?

There is an output schema present, and the tool has only one required parameter with strong read-only annotations. For a simple retrieval tool, the description is roughly adequate. However, the 0% parameter coverage and the lack of differentiation from poll_run_events create a gap in completeness.

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 undocumented run_id parameter. The description names no parameters. The schema shows run_id is a required string, but with 0% coverage, the description should at least mention that run_id identifies the run whose events will be retrieved. Baseline 3 applies when coverage is high; here it's zero, so the description fails to compensate.

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?

Description states 'Return the ordered event stream for a run' - a specific verb (return) and resource (event stream for a run). However, it doesn't distinguish from the sibling tool poll_run_events, which is likely a similar event-retrieval operation. The distinction between a one-shot fetch vs polling is not made clear.

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?

No guidance on when to use this tool vs alternatives like poll_run_events. Given the sibling list contains poll_run_events (likely for continuous/long-polling) and get_run_events (likely one-shot), the description should explain when each is appropriate. There is no when/when-not guidance whatsoever.

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