Skip to main content
Glama

Moltline Business Suite

by com.moltlinestudio

Cash Runway

cash_runway
Read-onlyIdempotent

Compute months of cash runway and the projected out-of-cash date. FREE.

Typical input {"cash_balance": 120000, "monthly_burn": 15000, "monthly_revenue": 5000} returns {"runway_months": 12.0, "net_burn_monthly": 10000, "projected_out_of_cash": "YYYY-MM-DD"}; when revenue covers burn it returns {"runway": "infinite at current numbers (revenue covers burn)", ...}.

Use when a cash balance and a monthly burn are known. Not for per-unit profitability (unit_economics). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "cash_balance must be >= 0"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cash_balanceYesCash on hand today; must be 0 or greater, e.g. 120000.
monthly_burnYesTotal monthly outflow in the same currency as cash_balance, e.g. 15000.
monthly_revenueNoMonthly inflow netted against burn, e.g. 5000. Default 0.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds significant value beyond these: it details the error handling mechanism (never raises protocol error, returns error object with fix instructions), explains the special case when revenue covers burn (returns 'infinite'), and reinforces idempotency with 'after correcting the input it is always safe to retry.' No contradiction with annotations.

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

Conciseness5/5

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

The description is front-loaded with the core purpose, followed by a concise example, usage guidance, and error handling. Every sentence serves a distinct purpose—no redundancy or filler. Despite being a bit long, it is well-structured and efficiently informative.

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?

Given the tool's moderate complexity (3 parameters, 2 required, output schema exists), the description covers all essential aspects: purpose, example, edge case (infinite runway), error handling, and idempotency. The schema already documents parameters and output, so the description complements it fully without gaps.

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% with clear parameter descriptions, so baseline is 3. The description goes further by providing a concrete example input and output (e.g., cash_balance: 120000, monthly_burn: 15000, monthly_revenue: 5000) and explaining the calculation logic (net_burn_monthly). This adds practical context that aids invocation.

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 begins with a clear verb+resource statement: 'Compute months of cash runway and the projected out-of-cash date.' It directly distinguishes from the sibling tool 'unit_economics' by explicitly stating 'Not for per-unit profitability (unit_economics).' This provides strong differentiation.

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

Usage Guidelines5/5

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

The description explicitly states when to use the tool: 'Use when a cash balance and a monthly burn are known.' It also provides an exclusion: 'Not for per-unit profitability (unit_economics).' Additionally, it explains error behavior and retry safety, giving clear guidance on how to handle failures.

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

All Moltline Business Suite toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation3/5

The financial calculation tools (cash_runway, loan_payment, target_price, unit_economics) are clearly distinct in their inputs and outputs. However, within the product listing tools (list_products, get_free_skill, get_full_skill, get_full_product), the differentiation relies heavily on the 'FREE' vs 'PREMIUM' tags and the notion of 'free gateway skill' vs 'paid skills', which creates some ambiguity. An agent could easily pick get_free_skill when it actually needs get_full_skill.

Naming Consistency4/5

The tool set uses a mix of verb_noun (list_products, get_free_skill, get_full_product) and simple noun phrases (cash_runway, loan_payment, target_price, unit_economics). While the 'get_*' prefix creates a consistent pattern for product/skill access, the standalone financial calculation tools break this pattern. Nevertheless, the naming is still clear and predictable within each subgroup.

Tool Count5/5

With 8 tools, the set is well-scoped for a 'business' server that covers two clear domains: financial calculations (4 tools) and product/skill browsing (4 tools). Each tool covers a distinct operation without redundancy, and the count feels appropriate for the stated purpose.

Completeness3/5

The financial calculation tools cover common business math (runway, loan payments, margin/pricing, break-even), but lack coverage for revenue metrics (e.g., ARR, MRR), ROI, or depreciation. The product browsing tools provide a clear CRUD-like flow (list -> get), but there is no way to search or filter products, and the missing 'search_catalog' is referenced as existing on another server. This is a minor gap that may require agents to switch servers.

Resources