Utility Matrix

SLO Error Budget Calculator

error-budget-calculator

Read-onlyIdempotent

Use this when a user asks about their SLO error budget, remaining error budget, or burn rate. Given SLO percentage and window, returns budget minutes remaining, burn rate multiplier, and status (Under budget / Elevated / ALERTING).

Input Schema

Name	Required	Description
`slo_pct`	Yes	Service-level objective target expressed as a percentage.
`window_days`	No	Length of the service-level objective window in days.
`consumed_minutes`	No	consumed in minutes.
`window_elapsed_days`	No	window elapsed days used by this deterministic tool.

Output Schema

Name	Required	Description	Default
`status`	Yes
`burn_rate`	Yes
`next_step`	Yes
`next_step_url`	Yes
`why_follow_up`	Yes
`budget_minutes`	Yes
`interpretation`	Yes
`affiliate_context`	No
`computation_basis`	Yes
`remaining_minutes`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedSep 28, 2026

addedInput schema / properties / consumed_minutes / description
```
Added value: +"consumed in minutes."
```
addedInput schema / properties / consumed_minutes / examples
```
Added value: +[
+  1
+]
```

addedInput schema / properties / slo_pct / description

Added value: +"Service-level objective target expressed as a percentage."

addedInput schema / properties / slo_pct / examples
```
Added value: +[
+  0.001
+]
```

addedInput schema / properties / window_days / description

Added value: +"Length of the service-level objective window in days."

addedInput schema / properties / window_days / examples
```
Added value: +[
+  1
+]
```

addedInput schema / properties / window_elapsed_days / description

Added value: +"window elapsed days used by this deterministic tool."

addedInput schema / properties / window_elapsed_days / examples
```
Added value: +[
+  1
+]
```
addedOutput schema / properties / computation_basis
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / required

Previous value: -[
-  "budget_minutes",
-  "burn_rate",
-  "interpretation",
-  "next_step",
-  "next_step_url",
-  "remaining_minutes",
-  "status",
-  "why_follow_up"
-]New value: +[
+  "budget_minutes",
+  "burn_rate",
+  "computation_basis",
+  "interpretation",
+  "next_step",
+  "next_step_url",
+  "remaining_minutes",
+  "status",
+  "why_follow_up"
+]

Changed1 schema field changedJul 15, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "affiliate_context": {
+      "additionalProperties": false,
+      "properties": {
+        "affiliate": {
+          "type": "string"
+        },
+        "cta_label": {
+          "type": "string"
+        },
+        "disclosure": {
+          "type": "string"
+        },
+        "framing": {
+          "type": "string"
+        },
+        "posture": {
+          "enum": [
+            "secondary"
+          ],
+          "type": "string"
+        },
+        "slot_id": {
+          "type": "string"
+        },
+        "url": {
+          "type": "string"
+        },
+        "variant": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "affiliate",
+        "cta_label",
+        "disclosure",
+        "framing",
+        "posture",
+        "slot_id",
+        "url",
+        "variant"
+      ],
+      "type": "object"
+    },
+    "budget_minutes": {
+      "type": "number"
+    },
+    "burn_rate": {
+      "type": "number"
+    },
+    "interpretation": {
+      "type": "string"
+    },
+    "next_step": {
+      "type": "string"
+    },
+    "next_step_url": {
+      "type": "string"
+    },
+    "remaining_minutes": {
+      "type": "number"
+    },
+    "status": {
+      "type": "string"
+    },
+    "why_follow_up": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "budget_minutes",
+    "burn_rate",
+    "interpretation",
+    "next_step",
+    "next_step_url",
+    "remaining_minutes",
+    "status",
+    "why_follow_up"
+  ],
+  "type": "object"
+}

Changed1 schema field changedJul 13, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
First observedJun 29, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds the output shape and the status classification (Under budget / Elevated / ALERTING), which is useful context, but since an output schema exists this is largely duplicated rather than new behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste: the trigger condition is front-loaded and the return contract follows. Nothing padded or duplicated for its own sake.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a full output schema present, the description need not explain return values, and it covers triggers adequately for a read-only calculator. The one meaningful gap is routing against slo-burn-rate-calculator, whose scope overlaps almost entirely with the 'burn rate' trigger phrase used here.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with each of the four parameters documented in the schema itself, so the baseline is 3. The description mentions only 'SLO percentage and window' and adds no format, unit, or default detail beyond what the schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific computation (error budget from SLO percentage and window) and names the outputs, so the purpose is clear. It does not, however, distinguish itself from the closely named sibling slo-burn-rate-calculator, which the description only incidentally touches by mentioning 'burn rate multiplier' as an output.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The opening sentence gives explicit trigger conditions ('when a user asks about their SLO error budget, remaining error budget, or burn rate'), which is strong context. It stops short of excluding the obvious alternative (slo-burn-rate-calculator), so an agent must still infer which of the two to pick.

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

All Utility Matrix tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?