Hemrock MCP

Compute unit economics

unit_economics_compute

Read-only

Use when the user asks what a customer is worth or whether acquisition pays back: lifetime value, LTV to CAC, CAC payback, gross margin per customer, for recurring (subscription), one-time and transaction (repeat purchase) revenue in any mix. Takes up to three revenue lines and three cost of sales lines, each typed Recurring, One time or Transaction, with churn, billing and repeat periods, a discount rate, CAC and retention costs. Returns LTV split by revenue type, the ratios, and one customer's monthly revenue, billings, costs and cumulative cash flow (discounted and not) from the month of acquisition (month 0) through month 48, or through the months input (12 to 120). Runs the same math as Hemrock's Unit Economics Tool spreadsheet, checked against the workbook. Send inputs with only what the user gave you; everything else takes the model's defaults, and the result echoes every input used, so tell the user which defaults mattered. Set months (12 to 120, default 48) for the length of the forecast; monthly results are arrays with one value per month, month 1 first, and the totals cover the same months. LTV counts at most ltvMonths months of a customer's life (1 to 120, default 60), whatever the forecast length. The result includes webUrl: give it to the user, because it opens this exact model in Hemrock's web version, where they can change any input and download the live Excel workbook. Free: signed in it uses no calculations; without an account it counts toward a few free runs a day.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "unit_economics_compute"
  }
}

Input Schema

Name	Required	Description	Default
`inputs`	No	The model inputs. Send only what differs from the defaults; anything left out takes its default.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/openWorld annotations, it discloses that the math mirrors a specific spreadsheet checked against the workbook, that inputs are echoed back, that a webUrl should be surfaced to the user, and that free usage is quota-limited for anonymous callers. It also explains output framing (month 0 through month 48 or the months input) — substantial context the annotations do not carry.

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 most decision-relevant material — when to use it and what it returns — is front-loaded, and the later sentences on defaults, month indexing and webUrl all carry weight. It is dense and runs long, with the spreadsheet-parity sentence being the least essential, but there is no filler.

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?

With no output schema, the description carries the full burden of describing returns, and it does: LTV split by revenue type, the ratios, and per-month revenue, billings, costs and cumulative discounted/undiscounted cash flow plus the webUrl. For a nested-input compute tool, an agent has everything needed to call it and report results.

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?

Schema coverage is 100%, so the schema already documents each field. The description still adds cross-parameter meaning: months governs forecast length while ltvMonths independently caps the LTV horizon whatever the forecast length, and monthly arrays are indexed month 1 first with totals spanning the same months. That interplay is not obvious from the schema alone.

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 opens with a concrete use case ('what a customer is worth or whether acquisition pays back') and enumerates the exact metrics produced: lifetime value, LTV to CAC, CAC payback, gross margin per customer. It also scopes the revenue models supported (recurring, one-time, transaction), which makes it unmistakable against siblings like cap_table_compute or fund_economics_compute.

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 trigger condition ('Use when the user asks...') plus practical usage rules: send only the inputs the user gave, everything else takes defaults, and tell the user which defaults mattered. It stops short of naming a sibling alternative or a when-not-to-use case, so it is clear context without full routing guidance.

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

All Hemrock MCP 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?