Skip to main content
Glama

7IT Solutions

by io.github.XLSV777
OverviewDiscussionsAdmin

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).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tasksYes
hourly_costNoFully loaded cost of an hour of work in USD. Default 47.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
tasksYesPer-task hours and cost
report_urlYes
hourly_costYesHourly cost used, in USD
yearly_costYesYearly cost of the work done by hand, USD
hours_per_monthYes
automatable_yearlyYesYearly cost automation could take over, USD
break_even_budget_6_monthsYes
automatable_hours_per_monthYes
break_even_budget_12_monthsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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"
+}
  2. Changed3 schema fields changed
    • 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
  3. First observed

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 toolsInspect
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