Utility Matrix

Incident Cost Calculator

incident-cost-calculator

Read-onlyIdempotent

Use this when a user asks what an outage or incident cost, or wants to calculate the financial impact of downtime. Takes hourly revenue, downtime duration, and affected percentage. Returns revenue impact, engineering cost, and total incident cost in dollars.

Input Schema

Name	Required	Description
`eng_hourly`	No	eng hourly used by this deterministic tool.
`responders`	No	responders used by this deterministic tool.
`affected_pct`	No	affected expressed as a percentage.
`downtime_hours`	Yes	downtime in hours.
`hourly_revenue`	Yes	hourly revenue used by the calculation; monetary values are in USD unless stated otherwise.

Output Schema

Name	Required	Description	Default
`severity`	Yes
`next_step`	Yes
`next_step_url`	Yes
`why_follow_up`	Yes
`interpretation`	Yes
`total_cost_usd`	Yes
`affiliate_context`	No
`computation_basis`	Yes
`revenue_impact_usd`	Yes
`engineering_cost_usd`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedSep 28, 2026

addedInput schema / properties / affected_pct / description
```
Added value: +"affected expressed as a percentage."
```
addedInput schema / properties / affected_pct / examples
```
Added value: +[
+  1
+]
```
addedInput schema / properties / downtime_hours / description
```
Added value: +"downtime in hours."
```
addedInput schema / properties / downtime_hours / examples
```
Added value: +[
+  1
+]
```

addedInput schema / properties / eng_hourly / description

Added value: +"eng hourly used by this deterministic tool."

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

addedInput schema / properties / hourly_revenue / description

Added value: +"hourly revenue used by the calculation; monetary values are in USD unless stated otherwise."

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

addedInput schema / properties / responders / description

Added value: +"responders used by this deterministic tool."

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

changedOutput schema / required

Previous value: -[
-  "engineering_cost_usd",
-  "interpretation",
-  "next_step",
-  "next_step_url",
-  "revenue_impact_usd",
-  "severity",
-  "total_cost_usd",
-  "why_follow_up"
-]New value: +[
+  "computation_basis",
+  "engineering_cost_usd",
+  "interpretation",
+  "next_step",
+  "next_step_url",
+  "revenue_impact_usd",
+  "severity",
+  "total_cost_usd",
+  "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"
+    },
+    "engineering_cost_usd": {
+      "type": "number"
+    },
+    "interpretation": {
+      "type": "string"
+    },
+    "next_step": {
+      "type": "string"
+    },
+    "next_step_url": {
+      "type": "string"
+    },
+    "revenue_impact_usd": {
+      "type": "number"
+    },
+    "severity": {
+      "type": "string"
+    },
+    "total_cost_usd": {
+      "type": "number"
+    },
+    "why_follow_up": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "engineering_cost_usd",
+    "interpretation",
+    "next_step",
+    "next_step_url",
+    "revenue_impact_usd",
+    "severity",
+    "total_cost_usd",
+    "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, destructiveHint=false, and openWorldHint=false, fully covering the safety profile of a pure computation. The description restates the input/output composition but adds no behavioral context beyond what annotations and the output schema already convey, so a baseline 3 is appropriate.

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?

Three short sentences with a front-loaded use case, followed by inputs and outputs. Every sentence earns its place with no filler or redundancy.

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?

For a deterministic calculator with full annotation coverage and an output schema, the description gives an agent enough to call it correctly. It does omit mention of two optional inputs (eng_hourly, responders), which the schema covers, so it is complete but not maximally so.

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%, so the schema already documents all five parameters. The description mentions hourly revenue, downtime duration, and affected percentage, which maps to three of them but omits eng_hourly and responders and adds no syntax or format detail beyond the schema, making the baseline 3 correct.

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?

The description gives a specific verb+resource: calculating the financial impact of an outage/incident, naming concrete outputs (revenue impact, engineering cost, total). This is clearly distinct from every sibling (mttr-calculator, dora-metrics-calculator, ec2-cost-calculator, etc.), but it never explicitly contrasts itself with a nearest alternative, so it lands at a strong 4.

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?

It states a clear triggering condition: 'Use this when a user asks what an outage or incident cost, or wants to calculate the financial impact of downtime.' That is an explicit when-to-use context, though it offers no when-not-to-use guidance or named alternatives.

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?