Skip to main content
Glama

liquidity-leverage

calculate_defensive_interval

Read-onlyIdempotent

Calculate the defensive interval ratio: how many days a company can fund its operating expenses from liquid assets alone, without new revenue. Formula: Defensive Interval = (Cash + Marketable Securities + Receivables) / Daily Operating Expenses. WHEN TO USE: Use to gauge cash runway from liquid assets — useful for startups, distressed companies, or businesses with lumpy revenue. WHEN NOT TO USE: Do NOT use for companies with stable, predictable revenue where ongoing collections are dependable. BEHAVIOUR: pure deterministic calculation — no side effects, no network or storage access; idempotent and non-destructive; identical inputs always produce identical outputs. Division by zero or non-finite inputs returns an explicit error instead of a number. RETURNS: JSON object { defensive_interval_days: number (e.g. 45.3 days), inputs }. PARAMETERS: cash_and_equivalents (required): Cash and cash equivalents, e.g. 80000. Must be >= 0. marketable_securities (required): Short-term marketable securities, e.g. 30000. Must be >= 0. receivables (required): Accounts receivable, e.g. 60000. Must be >= 0. daily_operating_expenses (required): Daily operating expenses (annual opex / 365), e.g. 3750. Must be > 0.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
receivablesYesAccounts receivable, e.g. 60000. Must be >= 0.
cash_and_equivalentsYesCash and cash equivalents, e.g. 80000. Must be >= 0.
marketable_securitiesYesShort-term marketable securities, e.g. 30000. Must be >= 0.
daily_operating_expensesYesDaily operating expenses (annual opex / 365), e.g. 3750. Must be > 0.

TDQS

A4.4/5.0
Behavior5/5

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

The description goes well beyond the annotations by disclosing that it is a pure deterministic calculation with no side effects, no network or storage access, and consistent outputs for identical inputs. It also explicitly documents error behavior for division by zero and non-finite inputs, which the annotations alone do not convey.

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 description is well-structured with clear labels, front-loads the definition and formula, and every section adds operational value. It is somewhat long and the PARAMETERS block duplicates the schema descriptions, but the organization keeps it scannable and useful.

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 there is no output schema, the description properly explains the return shape: a JSON object with defensive_interval_days and inputs. It also covers parameter constraints, error behavior, use cases, and side-effect guarantees, making it fully self-sufficient for an agent to invoke correctly.

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 description coverage is 100%, so the schema already documents all four parameters with examples and constraints. The description's PARAMETERS section mostly repeats the schema text, though the formula does clarify the role of each parameter as numerator or denominator. This is a solid baseline but not a major semantic addition beyond the schema.

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 specific verb and resource: 'Calculate the defensive interval ratio' and immediately explains what it measures: how many days a company can fund operating expenses from liquid assets. It also includes the exact formula, which distinguishes it clearly from sibling liquidity ratios such as quick ratio, current ratio, and cash ratio.

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?

The description contains explicit WHEN TO USE and WHEN NOT TO USE sections, giving clear context for startups, distressed companies, and lumpy revenue, while excluding stable/predictable-revenue businesses. It does not name a specific sibling alternative to use instead, but the routing guidance is clear enough for an agent to choose correctly.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool computes a distinct, named financial ratio with a unique formula; even the three liquidity ratios are carefully differentiated by strictness and explicit WHEN TO USE/NOT guidance. There is no practical risk of an agent selecting the wrong tool.

Naming Consistency5/5

All tools follow the identical calculate_<metric> pattern in snake_case, making the naming scheme highly predictable. The only minor variation is calculate_defensive_interval instead of ..._ratio, but it still fits the same verb-prefixed convention.

Tool Count5/5

Eight tools is a well-scoped set for a liquidity and leverage ratio calculator: four liquidity measures and four leverage measures, with no redundant or filler tools. The count is manageable for an agent to choose from without being over-conservative.

Completeness5/5

The tool surface covers the standard liquidity ratios (current, quick, cash, defensive interval) and the core leverage/solvency ratios (debt-to-assets, debt-to-equity, equity multiplier, interest coverage). Since each tool is a pure calculation with no stateful workflow, there are no dead-end operations or lifecycle gaps.

Resources