Deterministic short-term solvency and capital-structure ratios — current/quick/cash ratio, defensive interval, debt ratios, interest coverage.
Calculate the cash ratio: cash and marketable securities divided by current liabilities — the most conservative liquidity measure. Formula: Cash Ratio = (Cash + Marketable Securities) / Current Liabilities. WHEN TO USE: Use for the strictest view of liquidity, or when a company is in distress and only cash-like assets can be relied on. WHEN NOT TO USE: Do NOT use in isolation for healthy operating businesses — it ignores receivables and inventory that normally convert to cash. 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 { cash_ratio: number (e.g. 0.5 = 0.5x), 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. current_liabilities (required): Total current liabilities, e.g. 220000. Must be > 0.
| Name | Required | Description | Default |
|---|---|---|---|
| current_liabilities | Yes | Total current liabilities, e.g. 220000. Must be > 0. | |
| cash_and_equivalents | Yes | Cash and cash equivalents, e.g. 80000. Must be >= 0. | |
| marketable_securities | Yes | Short-term marketable securities, e.g. 30000. Must be >= 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, and the description reinforces this while adding important specifics: no side effects, no network/storage access, identical inputs produce identical outputs, and division by zero or non-finite inputs returns an explicit error. This goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but well organized with clear labeled sections: formula, WHEN TO USE, WHEN NOT TO USE, BEHAVIOUR, RETURNS, and PARAMETERS. The parameter section largely repeats the schema, but the other sections are information-dense and directly actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deterministic financial calculator with no output schema, the description fully covers what the tool computes, how to call it, what constraints apply, what the return shape is, and how errors behave. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds value by embedding each parameter in the formula and giving concrete examples and validation constraints. It also clarifies the relationship between the three inputs in a way the schema alone does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 cash ratio,' followed by the exact formula. It also positions the tool as the 'most conservative liquidity measure,' which helps distinguish it from sibling liquidity ratios like quick ratio and current ratio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections state that this tool is for the strictest liquidity view or distress situations, and warn against using it in isolation for healthy operating businesses. This gives an agent clear decision criteria versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the current ratio, a liquidity measure of whether a company can cover its short-term obligations (due within a year) with its short-term assets. Formula: Current Ratio = Current Assets / Current Liabilities. WHEN TO USE: Use to assess short-term solvency, compare liquidity across peers of different sizes, or screen for distress risk. WHEN NOT TO USE: Do NOT use as the sole liquidity measure — it ignores asset quality and timing of cash flows (use calculate_quick_ratio or calculate_cash_ratio for stricter views). 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 { current_ratio: number (e.g. 1.8 = 1.8x), inputs }. PARAMETERS: current_assets (required): Total current assets, e.g. 500000. Must be >= 0. current_liabilities (required): Total current liabilities, e.g. 280000. Must be > 0.
| Name | Required | Description | Default |
|---|---|---|---|
| current_assets | Yes | Total current assets, e.g. 500000. Must be >= 0. | |
| current_liabilities | Yes | Total current liabilities, e.g. 280000. Must be > 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, and the description reinforces this with explicit no-side-effects language. It also discloses error handling for division by zero or non-finite inputs, which is valuable behavioral context beyond the annotation fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear labeled sections: definition, formula, when to use, when not to use, behavior, returns, and parameters. It is comprehensive while remaining focused, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deterministic calculation tool, the description covers the purpose, usage boundaries, behavior, error conditions, return format, and parameter constraints. With no output schema, the explicit RETURNS section fully compensates for that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description's PARAMETERS section mostly duplicates the schema, adding no significant semantic value beyond what is already available.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Calculate the current ratio' and defines it as a liquidity measure. It also includes the formula and contrasts with sibling tools like quick ratio and cash ratio, making differentiation clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit WHEN TO USE and WHEN NOT TO USE sections, naming when to prefer calculate_quick_ratio or calculate_cash_ratio. This gives an agent unambiguous selection criteria beyond just the formula.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the debt-to-assets ratio: total debt divided by total assets — the proportion of a company’s assets financed by debt. Formula: Debt-to-Assets = Total Debt / Total Assets. WHEN TO USE: Use to measure overall leverage and asset encumbrance; values above 0.5 indicate debt funds more than half of assets. WHEN NOT TO USE: Do NOT use when you need the debt-to-equity view of capital structure (use calculate_debt_to_equity). 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 { debt_to_assets: decimal (e.g. 0.42 = 42%), debt_to_assets_pct: number (e.g. 42.0), inputs }. PARAMETERS: total_debt (required): Total debt, e.g. 300000. Must be >= 0. total_assets (required): Total assets, e.g. 720000. Must be > 0.
| Name | Required | Description | Default |
|---|---|---|---|
| total_debt | Yes | Total debt, e.g. 300000. Must be >= 0. | |
| total_assets | Yes | Total assets, e.g. 720000. Must be > 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, and non-destructive, and the description adds concrete guarantees: no side effects, no network or storage access, identical inputs produce identical outputs, and division by zero or non-finite inputs returns an explicit error. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized with labeled sections. Every sentence carries information: formula, use case, alternative, behavior, error handling, return shape, and parameter constraints. No filler or redundancy that hurts usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter deterministic calculation with no output schema, this is complete: it gives the formula, return object shape, error behavior, and parameter rules. An agent has everything needed to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 both parameters with constraints, examples, and required status. The description repeats the parameter details with the same examples and constraints, adding no meaning beyond what the schema provides; the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: 'Calculate the debt-to-assets ratio' followed by the exact formula and financial meaning (proportion of assets financed by debt). It also names the sibling tool calculate_debt_to_equity as the alternative, making differentiation explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It has explicit WHEN TO USE and WHEN NOT TO USE sections, including a numeric threshold (above 0.5) and a direct pointer to calculate_debt_to_equity for the debt-to-equity view. An agent can decide correctly without inferring.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the debt-to-equity ratio: total debt divided by shareholders’ equity — how much a company relies on debt versus equity financing. Formula: Debt-to-Equity = Total Debt / Shareholders’ Equity. WHEN TO USE: Use to evaluate capital structure and financial risk, compare leverage across peers, or assess covenant headroom. WHEN NOT TO USE: Do NOT compare D/E across industries without context — capital intensity varies widely; a negative ratio (negative equity) indicates distress, not low leverage. 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 { debt_to_equity: number (e.g. 1.5 = 1.5x), inputs }. PARAMETERS: total_debt (required): Total debt (short-term + long-term interest-bearing), e.g. 300000. Must be >= 0. shareholders_equity (required): Total shareholders’ equity, e.g. 200000. May be negative in distress (result will be negative).
| Name | Required | Description | Default |
|---|---|---|---|
| total_debt | Yes | Total debt (short-term + long-term interest-bearing), e.g. 300000. Must be >= 0. | |
| shareholders_equity | Yes | Total shareholders’ equity, e.g. 200000. May be negative in distress (result will be negative). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing that the calculation is pure, deterministic, side-effect-free, idempotent, and non-destructive, and that invalid inputs (division by zero or non-finite values) return an explicit error. This is useful behavioral context that annotations alone do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear headings and front-loaded purpose, making it easy to scan. However, the PARAMETERS section largely duplicates the input schema, adding some redundancy. Otherwise, every section earns its place and the structure aids agent comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only two parameters and full schema coverage, the description is complete: it states the formula, return shape, error behavior, caveats for negative equity, and when not to use the tool. No critical information is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The PARAMETERS section in the description mostly restates the schema, adding no significant new meaning beyond what is already structured. The negative-equity nuance is present in the schema too, so this stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description names the exact calculation (debt-to-equity = total debt / shareholders' equity) and states the analytical purpose (capital structure, leverage, financial risk). The formula and explicit ratio distinguish it clearly from sibling ratio calculators without relying on the tool name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit WHEN TO USE and WHEN NOT TO USE guidance, including concrete use cases (evaluate capital structure, compare peers, covenant headroom) and a clear exclusion (cross-industry comparison, negative equity misinterpretation). This is strong, actionable context for an agent deciding whether to call this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| receivables | Yes | Accounts receivable, e.g. 60000. Must be >= 0. | |
| cash_and_equivalents | Yes | Cash and cash equivalents, e.g. 80000. Must be >= 0. | |
| marketable_securities | Yes | Short-term marketable securities, e.g. 30000. Must be >= 0. | |
| daily_operating_expenses | Yes | Daily operating expenses (annual opex / 365), e.g. 3750. Must be > 0. |
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.
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.
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.
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.
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.
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.
Calculate the equity multiplier: total assets divided by shareholders’ equity — a leverage measure of how many units of assets each unit of equity supports. Formula: Equity Multiplier = Total Assets / Shareholders’ Equity. WHEN TO USE: Use in DuPont analysis (ROE = Net Margin x Asset Turnover x Equity Multiplier) or to quantify financial leverage. WHEN NOT TO USE: Do NOT use alone — a high multiplier can mean efficient leverage or distress depending on profitability (pair with ROE/ROA). 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 { equity_multiplier: number (e.g. 3.6 = 3.6x), inputs }. PARAMETERS: total_assets (required): Total assets, e.g. 720000. Must be > 0. shareholders_equity (required): Total shareholders’ equity, e.g. 200000. May be negative in distress.
| Name | Required | Description | Default |
|---|---|---|---|
| total_assets | Yes | Total assets, e.g. 720000. Must be > 0. | |
| shareholders_equity | Yes | Total shareholders’ equity, e.g. 200000. May be negative in distress. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description explains it is a 'pure deterministic calculation — no side effects, no network or storage access' and specifies that division by zero or non-finite inputs returns an explicit error. This gives an agent precise expectations beyond the boolean hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized with labeled sections (WHEN TO USE, WHEN NOT TO USE, BEHAVIOUR, RETURNS, PARAMETERS) and front-loads the formula and purpose. Every section contributes new operational information, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deterministic calculator with two parameters and no output schema, the description fully covers usage context, error behavior, return shape, and parameter constraints. An agent has everything needed to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description's PARAMETERS section largely mirrors the schema ('total_assets: Must be > 0', 'shareholders_equity: May be negative in distress'). The formula adds context, but the parameter descriptions themselves add little beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 equity multiplier' plus the exact formula 'total assets divided by shareholders’ equity'. It also distinguishes the tool by naming the metric's role in DuPont analysis, so an agent knows exactly what it computes and how it differs from sibling ratio calculators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit WHEN TO USE and WHEN NOT TO USE sections, including the caution to pair with ROE/ROA and not use the multiplier alone. It stops short of naming alternative sibling tools (e.g., debt-to-equity), so the cross-tool decision is only partially addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the interest coverage ratio: earnings before interest and taxes divided by interest expense — how many times a company can cover its interest obligations from operating earnings. Formula: Interest Coverage = EBIT / Interest Expense. WHEN TO USE: Use to assess credit risk and debt-service capacity; below 1.5 is typically a distress signal, above 3 is comfortable for most industries. WHEN NOT TO USE: Do NOT use for companies with significant non-cash EBIT distortions (large depreciation) — consider EBITDA-based coverage for those. 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 { interest_coverage: number (e.g. 4.2 = 4.2x), inputs }. PARAMETERS: ebit (required): Earnings before interest and taxes (operating income), e.g. 420000. May be negative. interest_expense (required): Annual interest expense, e.g. 100000. Must be > 0.
| Name | Required | Description | Default |
|---|---|---|---|
| ebit | Yes | Earnings before interest and taxes (operating income), e.g. 420000. May be negative. | |
| interest_expense | Yes | Annual interest expense, e.g. 100000. Must be > 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses pure deterministic behavior with no side effects, no network or storage access, idempotence, and identical outputs for identical inputs. It also specifies the division-by-zero and non-finite input error handling, which meaningfully extends the readOnly and idempotent hints already provided by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear labeled sections: purpose, formula, usage guidance, exclusions, behavior, returns, and parameters. Every sentence adds useful information, and the core purpose is front-loaded before the more detailed guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter calculation with no output schema, the description is fully complete: it explains the formula, the domain context, when to use and avoid it, the exact return shape, and edge-case error behavior. An agent has all the information needed to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters already documented in the schema. The description adds value through realistic examples and clarifies the range semantics (e.g., ebit may be negative, interest_expense must be > 0), but these are largely restatements of the schema, so it does not materially go beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: calculates the interest coverage ratio, gives the exact formula (EBIT / Interest Expense), and explains the meaning in plain terms. The threshold context and sibling names for other ratios make it clear this is a distinct financial-ratio calculation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides WHEN TO USE guidance with concrete thresholds (below 1.5 distress, above 3 comfortable) and WHEN NOT TO USE guidance with an alternative (EBITDA-based coverage for non-cash EBIT distortions). This clearly differentiates when to call this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the quick (acid-test) ratio: liquid assets excluding inventory divided by current liabilities — a stricter short-term solvency test than the current ratio. Formula: Quick Ratio = (Current Assets - Inventory) / Current Liabilities. WHEN TO USE: Use when inventory is slow-moving or hard to liquidate and you want a conservative view of short-term payment ability. WHEN NOT TO USE: Do NOT use for businesses where inventory converts to cash quickly (e.g. retailers with fast sell-through) — it understates true liquidity. 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 { quick_ratio: number (e.g. 1.2 = 1.2x), inputs }. PARAMETERS: current_assets (required): Total current assets, e.g. 500000. Must be >= 0. inventory (required): Inventory value to exclude, e.g. 120000. Must be >= 0 and <= current_assets. current_liabilities (required): Total current liabilities, e.g. 280000. Must be > 0.
| Name | Required | Description | Default |
|---|---|---|---|
| inventory | Yes | Inventory value to exclude, e.g. 120000. Must be >= 0 and <= current_assets. | |
| current_assets | Yes | Total current assets, e.g. 500000. Must be >= 0. | |
| current_liabilities | Yes | Total current liabilities, e.g. 280000. Must be > 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behaviors beyond the annotations: pure deterministic calculation, no side effects, no network/storage access, idempotent and non-destructive, with explicit error behavior for division by zero or non-finite inputs. This adds substantial value that annotations alone do not provide, and it is consistent with the readOnlyHint and idempotentHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clearly labeled sections: definition, formula, when to use, when not to use, behavior, returns, and parameters. Every section earns its place and key information is front-loaded; the length is justified by both usage guidance and edge-case behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 explicitly documents the return format as a JSON object with quick_ratio and inputs. It covers edge cases, parameter constraints, formulas, and alternatives, 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds meaning with real-world examples (e.g., 500000, 120000, 280000) and the cross-field constraint that inventory must be <= current_assets, which the schema does not capture. It also clarifies the sign restriction on current_liabilities with 'Must be > 0'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a precise verb and resource: 'Calculate the quick (acid-test) ratio' and gives the formula. It explicitly distinguishes itself from the current ratio, calling itself a 'stricter short-term solvency test,' which helps an agent identify this tool among financial-ratio siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description has dedicated 'WHEN TO USE' and 'WHEN NOT TO USE' sections, providing explicit conditions such as 'use when inventory is slow-moving' and warnings against use for fast sell-through retailers. It clearly routes agents away from this tool in cases where it would understate liquidity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
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.
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.
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.
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.