get_run_metric

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds 'full history' but does not disclose any other behavioral traits (e.g., rate limits, maximum history length, or response format). With annotations handling the main safety aspect, a score of 3 is appropriate—adequate but not enriching beyond annotations.

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 one short sentence, which is concise and front-loaded. However, it lacks any structured detail (e.g., bullet points or examples) that could improve clarity without adding much length. It earns points for brevity but loses slightly for being too minimal to fully support an agent.

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 has 2 parameters, annotations, and an output schema, the description provides the core purpose but does not elaborate on the output structure or any constraints. Since an output schema exists, the return format is covered elsewhere, but the description could still offer examples or edge cases. Score 3 for being minimally complete but not rich.

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 carries full responsibility for explaining parameters. However, the description only says 'Get the full history of a specific metric for a run', which does not add meaning to run_id or metric_name beyond their names. The agent must infer their roles, which is minimal support. Score 2 for insufficient compensation.

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 the tool retrieves 'full history of a specific metric for a run'. The verb 'get' and resource 'full history' are specific, and it differentiates from sibling 'get_run_metrics' which likely returns all metrics. However, 'full history' is somewhat ambiguous (e.g., does it include all steps or all timestamps?). Still, it's clear enough for an agent. Score 4 for good but not perfect clarity.

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 explicit guidance on when to use this tool versus alternatives like get_run_metrics or get_run. The context of sibling tools implies this is for a single metric's history, but the description doesn't state this or mention any exclusions. Usage is only implied, not explicitly guided.

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