get_metrics

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It says 'retrieve,' implying a read-only operation, but does not reveal potential side effects of actions like 'aggregate' or 'compare,' possible rate limits, data retention implications, or whether any state is mutated. This is insufficient for a tool with an action parameter that might perform computations.

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 sentence with no filler words, front-loaded with the action verb and resource. It is effective as a concise teaser, even though the brevity sacrifices clarity. It earns a 4 for efficient structure, not for informativeness.

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?

With no output schema, no parameter descriptions, and no annotations, the description is the only documentation source for this complex six-parameter tool. It doesn't explain the action enum values, filtering combination, or return shape. An agent cannot reliably construct a valid invocation from the current definition.

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 meaning of the six parameters. It does not mention limit, action, project, trace_id, execution_id, or behavior_name at all. The only clue is the enum name 'action' in the schema, but the description does not explain what these filters target or how they relate to the four metric categories.

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 a specific verb ('retrieve') and a resource (runtime execution telemetry, tick durations, stuck events, category statistics), so the core purpose is fairly clear. However, it does not differentiate from the sibling 'get_status' tool, which could also surface runtime information. Not enough to drop below a 4, but it leaves ambiguity about which get-style tool to select.

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?

There is no usage guidance at all. The description doesn't say when to use this tool instead of get_status, load_behavior, or replay_recording, and it doesn't explain the action enum or any preconditions. An agent is left to infer the appropriate usage context from the parameter names and siblings.

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