A calculator tool should return its assumptions, not just a payback number

Disclosure: Prepared with AI assistance from the current implementation and live checks using fictional inputs.

We exposed Aplos's automation-budget arithmetic as a small MCP tool. The useful design decision was separating cash expenditure from the assigned value of people's time.

Those values can be added in a model, but they should not be presented as the same thing. A workflow might free staff capacity while leaving payroll unchanged.

Make the assumptions explicit

The calculate_automation_budget tool accepts seven numbers:

{
  "setup": 5000,
  "rollout": 10,
  "software": 200,
  "support": 100,
  "review": 5,
  "rate": 40,
  "hours": 40
}

setup is the one-time cash cost. rollout is internal rollout time in hours. software and support are monthly cash costs. review is monthly review and maintenance time. rate assigns a value to an hour, and hours is gross monthly time expected to be freed.

Every input is required. Use zero for an inapplicable cost, and use one currency consistently. The tool validates finite numbers from zero to one million and rejects additional fields. That keeps a caller from silently supplying an unsupported tax rate or another assumption the calculation ignores.

Return the components

For the example above, the calculation is:

Monthly cash cost = 200 + 100 = 300
Monthly economic cost = 300 + (5 × 40) = 500
Upfront economic cost = 5000 + (10 × 40) = 5400
Monthly net capacity value = (40 × 40) - 500 = 1100
Simple economic payback = 5400 / 1100 = 4.91 months
First-year cash outlay = 5000 + (12 × 300) = 8600

The response includes these components and echoes the assumptions in structured content. The caller can show where the headline number came from and which inputs the user should challenge.

Test the uncertain assumption

Holding the costs constant and changing gross time freed from 40 to 15 hours reduces monthly net capacity value to 100. Simple payback becomes 54 months. At 10 hours, modeled monthly net value is negative, so the tool returns null for payback.

That null matters. Returning a negative payback period would make a losing scenario look like a valid schedule. A client should explain that the current assumptions produce no positive monthly net value.

The calculation does not establish that a project will free the forecast hours. That evidence has to come from observing the workflow. It also excludes taxes, financing, discounting and currency conversion.

Keep the tool's claims narrow

The server performs arithmetic. It does not read accounting records, remove expenses, purchase software or promise savings. Its tool annotations describe it as read-only, non-destructive and idempotent, with no open-world actions.

Invalid values produce an explicit tool error. Valid responses include an interpretation explaining that time-valued capacity becomes cash savings only if a real expense is removed. This makes the limitation available to the client alongside the numeric result.

We checked initialization, tool discovery and eight fictional valid/invalid cases against the live endpoint. Those checks verify the examples and input behavior; they are not evidence of economic returns or ChatGPT directory approval.

Try the browser calculator, or see the MCP connection details.