7IT Solutions

Estimate the cost of repetitive work

estimate_automation_roi

Read-onlyIdempotent

Use this when someone wants to know what a repetitive task costs their team, or whether automating it is worth the money. Calculates how many hours a month a team spends on repetitive tasks, what that costs per year, how much of it automation could take over (the share that is copying between systems, not judgment), and the break-even budget for automating it within 12 and 6 months. Uses only the figures provided; the default hourly cost is $47, the US private-industry average employer cost per hour worked in June 2026 (Bureau of Labor Statistics).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tasks": "<tasks>"
    },
    "name": "estimate_automation_roi"
  }
}

Input Schema

Name	Required	Description	Default
`tasks`	Yes
`hourly_cost`	No	Fully loaded cost of an hour of work in USD. Default 47.

Output Schema

Name	Required	Description
`tasks`	Yes	Per-task hours and cost
`report_url`	Yes
`hourly_cost`	Yes	Hourly cost used, in USD
`yearly_cost`	Yes	Yearly cost of the work done by hand, USD
`hours_per_month`	Yes
`automatable_yearly`	Yes	Yearly cost automation could take over, USD
`break_even_budget_6_months`	Yes
`automatable_hours_per_month`	Yes
`break_even_budget_12_months`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 1, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "automatable_hours_per_month": {
+      "type": "number"
+    },
+    "automatable_yearly": {
+      "description": "Yearly cost automation could take over, USD",
+      "type": "number"
+    },
+    "break_even_budget_12_months": {
+      "type": "number"
+    },
+    "break_even_budget_6_months": {
+      "type": "number"
+    },
+    "hourly_cost": {
+      "description": "Hourly cost used, in USD",
+      "type": "number"
+    },
+    "hours_per_month": {
+      "type": "number"
+    },
+    "report_url": {
+      "type": "string"
+    },
+    "tasks": {
+      "description": "Per-task hours and cost",
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "name": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "yearly_cost": {
+      "description": "Yearly cost of the work done by hand, USD",
+      "type": "number"
+    }
+  },
+  "required": [
+    "hourly_cost",
+    "hours_per_month",
+    "yearly_cost",
+    "automatable_hours_per_month",
+    "automatable_yearly",
+    "break_even_budget_12_months",
+    "break_even_budget_6_months",
+    "tasks",
+    "report_url"
+  ],
+  "type": "object"
+}

Changed3 schema fields changedOct 1, 2026
- changedInput schema / $schema
```
Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
```
- removedInput schema / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / tasks / items / additionalProperties
```
Removed value: -false
```
First observedSep 30, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare a safe read-only, idempotent, non-destructive profile, so the safety burden is lifted. The description adds genuine behavioral context beyond that: it defines the automation-eligible share ('copying between systems, not judgment'), pins the break-even horizons (12 and 6 months), and discloses the default $47/hr with its BLS source. It stops short of noting scaling limits or edge-case handling.

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

Conciseness4/5

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

The when-to-use trigger is front-loaded in the first sentence, followed by a compact enumeration of computed outputs. Two parentheticals (the judgment/copying distinction and the BLS citation) are load-bearing rather than filler, though the second sentence runs long.

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

Completeness5/5

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

An output schema exists, so return-format explanation is unnecessary. Purpose, trigger, methodology, defaults, and the definition of the key derived ratio are all present, leaving nothing an agent needs in order to invoke this computation correctly.

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

Parameters4/5

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

With schema coverage at 50%, the description is expected to compensate, and it does on the key points: it justifies the default hourly cost ($47, US private-industry average) and clarifies the semantic distinction that drives copying_share ('copying between systems, not judgment'). It also states that only provided figures are used, which clarifies the derived-output behavior of the tasks array.

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

Purpose5/5

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

The description names a specific verb+resource: calculating what a repetitive task costs a team and whether automation is worth the money. It enumerates the concrete outputs (hours/month, cost/year, automatable share, break-even budget at 12 and 6 months), so an agent knows exactly what this produces without opening the schema.

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 gives an explicit situational trigger: 'Use this when someone wants to know what a repetitive task costs their team, or whether automating it is worth the money.' No alternatives or exclusions are named, but the sibling list contains no comparable ROI/cost tool to route against, so the absence is inconsequential.

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

All 7IT Solutions tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?