loop-mcp

business_ratios

Read-only

Compute cash runway in months, cash buffer days, current ratio, quick ratio, debt to equity, DSO, DIO, DPO and cash conversion cycle from any subset of a business's own cash, monthly flow and balance sheet figures. Arithmetic only, no network. Each value carries its formula and the inputs it used; a value that cannot be computed is null with a reason.

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": "business_ratios"
  }
}

Input Schema

Name	Required	Description
`cash`	No	Cash on hand. Every figure uses the same currency unit. May be negative.
`equity`	No	Total equity. May be negative.
`payables`	No	Accounts payable.
`inventory`	No	Inventory at cost.
`l402_proof`	No	L402 payment proof "<macaroon>:<preimage>". Omit on the first call; an unpaid call returns a 0 sat Lightning invoice and the macaroon. Pay the invoice, then repeat the call with this argument set.
`annual_cogs`	No	Cost of goods sold for the last twelve months.
`receivables`	No	Accounts receivable.
`annual_revenue`	No	Revenue for the last twelve months.
`current_assets`	No	Total current assets.
`monthly_inflows`	No	Cash received per month.
`monthly_outflows`	No	Cash paid out per month.
`total_liabilities`	No	Total liabilities.
`current_liabilities`	No	Total current liabilities.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

B3.1/5.0

Behavior1/5

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

The description claims 'Arithmetic only, no network', but the annotations declare openWorldHint=true and the schema contains an l402_proof parameter requiring a Lightning invoice to be paid between two calls. This directly contradicts the annotation and hides a mandatory two-step paid flow from the agent. No credit for the useful null-with-reason note, since it describes output the agent never reaches without solving the undocumented payment step.

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?

Front-loaded with the computed outputs, then the input domain, then return shape; three dense sentences with little waste. The ratio enumeration is long but each term is load-bearing. The one genuinely wasteful sentence is 'Arithmetic only, no network', which is also the misleading one.

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

Completeness2/5

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

For a 13-parameter tool with no output schema, the description does well to explain the return shape (formula plus inputs, null plus reason). But it omits the single most decision-relevant behavior: the first call is unpaid, returns an invoice and macaroon, and must be repeated with l402_proof. An agent cannot call this correctly on the description alone.

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 coverage is 100% and each parameter already documents units, sign and meaning, so the baseline is 3. The description adds only the framing that any subset may be supplied; it adds nothing about l402_proof, which the schema does describe but the description never acknowledges as part of the call flow.

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?

States a specific verb ('Compute') and an explicit, enumerated set of outputs (runway, buffer days, current/quick ratio, D/E, DSO, DIO, DPO, CCC) plus the input domain (cash, monthly flow, balance sheet figures). No sibling overlaps with the utility tools listed, and an agent knows exactly what it will get back.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'From any subset' implies all inputs are optional and that partial data yields partial results, which is useful invocation guidance. However, there is no statement about eligibility, no mention that a first call is unpaid and must be repeated with l402_proof, and no guidance on what minimum input set produces which ratios.

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

All loop-mcp tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?