obs_error_rate

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

With no annotations provided, the description carries the full burden of disclosing behavior. It conveys the core computation but does not say what happens when the 5xx metric does not exist, what the response shape is, or whether it filters by a Prometheus label versus a service identifier. This is minimal transparency beyond the tool name.

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 efficient sentence with no filler, and it places the core meaning first. However, it is so terse that it omits behavioral and parameter detail that would justify a longer 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?

For a tool with no annotations into a 2-parameter schema, the description says too little. It does not cover missing-metric behavior, session_name semantics, or when to use this versus obs_query_metrics. The existence of an output schema reduces the need to document return values, but the remaining gaps still leave an agent under-informed.

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 explain parameters. It contributes some meaning by suggesting 'service' is a label or selector for the metric, but 'session_name' is entirely unexplained, and no details are provided about accepted formats, defaults beyond the schema default, or how session_name affects the query.

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 resource ('HTTP 5xx rate') and a precise temporal scope ('over 5 minutes'), and adds a caveat ('if that metric exists'). It is distinguishable from generic siblings like obs_query_metrics, though it lacks an explicit verb such as 'get' or 'retrieve'.

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 is given about when to prefer this tool over obs_query_metrics or how to check whether the metric exists before calling. The conditional phrase implies the metric may be absent, but the resulting behavior is not described, so an agent is left guessing whether to call a sibling or handle an error.

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