slo_calculate_budget

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, and it falls short. It does not explain whether the tool reads existing SLO configuration, writes files, requires a specific project structure, or what happens when the directory lacks SLO data. The api_key parameter hints at external API access, but the description does not disclose what the key is used for or whether the operation has side effects.

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 short and front-loaded, which is positive, but it is under-specified rather than genuinely concise. Every word is functional, yet the brevity sacrifices critical information that an agent needs to select and invoke the tool correctly.

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 absence of annotations, output schema, and sibling differentiation, the description is incomplete. The tool has two parameters, one undocumented, and no explanation of inputs, outputs, defaults, or error conditions. The agent is left with a tool name and a three-word description, which is inadequate for confident invocation.

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 coverage is only 50%, and the description adds no parameter-level meaning. 'Calculate error budget' does not clarify what 'directory' refers to (project root? SLO config directory?) or why 'api_key' is needed (which service? required for what?). The description must compensate for the undocumented api_key parameter, but it does not, leaving the agent to guess.

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 'Calculate error budget' identifies the action and resource (error budget calculation) but is too terse to establish important details like what inputs it needs (directory, api_key) or how it relates to SLO tooling. It is not a tautology, but it lacks the specificity needed to distinguish it from other SLO-related sibling tools like slo_define_objectives or slo_generate_alerts.

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 guidance about when to use this tool versus alternatives. The sibling list includes slo_define_objectives and slo_generate_alerts, but the description does not mention them or provide any context for choosing this tool. The only contextual clue is that the tool name includes 'budget' and a single required 'directory' parameter, which is insufficient for an agent to decide when to invoke it.

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