Deterministic operational-efficiency ratios for corporate financial analysis— asset/inventory/receivables/payables turnover, DSO/DIO/DPO, cash conversion cycle.
Calculate asset turnover: net sales divided by average total assets — how efficiently a company generates revenue from its asset base. Formula: Asset Turnover = Net Sales / Average Total Assets. WHEN TO USE: Use to compare revenue productivity across companies or years; a falling ratio suggests assets are not generating sales efficiently. WHEN NOT TO USE: Do NOT compare asset turnover across industries — capital intensity differs fundamentally (software vs manufacturing). 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 { asset_turnover: number (e.g. 0.85 = 0.85x per year), inputs }. PARAMETERS: net_sales (required): Net sales / revenue for the period, e.g. 900000. Must be >= 0. begin_total_assets (required): Total assets at the START of the period, e.g. 1000000. Must be >= 0. end_total_assets (required): Total assets at the END of the period, e.g. 1100000. Must be >= 0.
| Name | Required | Description | Default |
|---|---|---|---|
| net_sales | Yes | Net sales / revenue for the period, e.g. 900000. Must be >= 0. | |
| end_total_assets | Yes | Total assets at the END of the period, e.g. 1100000. Must be >= 0. | |
| begin_total_assets | Yes | Total assets at the START of the period, e.g. 1000000. Must be >= 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, and non-destructive, but the description goes further by stating it is a 'pure deterministic calculation' with no side effects, no network or storage access, and identical outputs for identical inputs. It also discloses error behavior for division by zero and non-finite inputs, which is valuable beyond the 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 labeled sections and front-loads the core formula before usage and behavior details. It is slightly redundant with the schema's per-parameter descriptions, but each section serves a clear purpose and the examples improve 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 simple 3-parameter calculation tool with rich annotations, the description covers everything needed: formula, parameter semantics with examples, return format, invalid-input behavior, and usage guardrails. No critical guidance 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. The description adds value by explicitly linking the parameters through the formula and providing concrete numeric examples for each input, reinforcing constraints like non-negativity. It does not contradict the schema and clarifies how the three inputs combine.
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 asset turnover') and states the exact formula: net sales divided by average total assets. The 'average total assets' phrasing clearly distinguishes this from close siblings like fixed_asset_turnover and inventory_turnover.
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 explicit WHEN TO USE and WHEN NOT TO USE sections, giving concrete use cases and a clear exclusion: do not compare asset turnover across industries due to capital intensity differences. This is exemplary guidance for selecting this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the cash conversion cycle (CCC): DSO + DIO - DPO — the net number of days cash is tied up between paying suppliers and collecting from customers. Formula: CCC = Days Sales Outstanding + Days Inventory Outstanding - Days Payables Outstanding. WHEN TO USE: Use as the definitive working-capital efficiency measure: a shorter (or negative) CCC means less capital trapped in operations. WHEN NOT TO USE: Do NOT use unless all three components are computed on a consistent 365-day basis and comparable periods. 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_conversion_cycle_days: number (e.g. 57.7 days; negative = operating on supplier cash), inputs }. PARAMETERS: dso (required): Days sales outstanding, e.g. 45.6. dio (required): Days inventory outstanding, e.g. 60.8. dpo (required): Days payables outstanding, e.g. 48.7.
| Name | Required | Description | Default |
|---|---|---|---|
| dio | Yes | Days inventory outstanding, e.g. 60.8. | |
| dpo | Yes | Days payables outstanding, e.g. 48.7. | |
| dso | Yes | Days sales outstanding, e.g. 45.6. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits beyond annotations: no side effects, no network/storage access, idempotent, non-destructive, and specific error behavior for division by zero or non-finite inputs. While annotations already signal read-only idempotent non-destructive, the description adds deterministic behavior and explicit error handling, which is genuinely useful.
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 labeled sections (purpose, when to use, behavior, returns, parameters), but the formula is stated twice: once in the opening sentence and once in the explicit Formula section. Minor redundancy aside, the structure is front-loaded and scannable.
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 calculation with three numeric parameters, coverage is comprehensive: annotations handle safety, schema handles parameter definitions, and the description supplies usage conditions, behavioral guarantees, error behavior, return shape, and interpretation of negative results. No output schema exists, but the RETURNS section fully documents the response.
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% with each parameter described and exemplified, so the baseline is 3. The description adds meaning by tying the three parameters to the formula (DSO + DIO - DPO), clarifying they are components that produce days, and noting a negative result means operating on supplier cash. This goes slightly beyond the schema's per-parameter examples.
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 object ('Calculate the cash conversion cycle') and immediately distinguishes it from sibling component tools by presenting the composite formula CCC = DSO + DIO - DPO. It clearly identifies the tool as the aggregate measure, not one of the individual day/ratio tools in the sibling list.
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 give direct guidance: use as the definitive working-capital efficiency measure, but avoid unless all components are on a consistent 365-day basis and comparable periods. This goes beyond generic context and helps an agent decide when to invoke this tool versus component-level tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate days inventory outstanding (DIO): the average number of days a company holds inventory before selling it. Formula: DIO = 365 / Inventory Turnover. WHEN TO USE: Use to assess inventory efficiency and capital tied up in stock; high DIO risks obsolescence and cash drag. WHEN NOT TO USE: Do NOT apply mechanically across industries — optimal DIO differs hugely between fresh grocery and heavy machinery. 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 { days_inventory_outstanding: number of days (e.g. 60.8), inputs }. PARAMETERS: cogs (required): Cost of goods sold for the period, e.g. 600000. Must be > 0. begin_inventory (required): Inventory at period start, e.g. 90000. Must be >= 0. end_inventory (required): Inventory at period end, e.g. 110000. Must be >= 0.
| Name | Required | Description | Default |
|---|---|---|---|
| cogs | Yes | Cost of goods sold for the period, e.g. 600000. Must be > 0. | |
| end_inventory | Yes | Inventory at period end, e.g. 110000. Must be >= 0. | |
| begin_inventory | Yes | Inventory at period start, e.g. 90000. Must be >= 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description states this is a pure deterministic calculation with no side effects, no network or storage access, idempotent and non-destructive behavior, and identical outputs for identical inputs. It also discloses division-by-zero and non-finite input error behavior, adding meaningful operational detail.
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 sections: definition/formula, when to use, when not to use, behavior, returns, and parameters. Every sentence earns its place, and the core purpose is front-loaded in the first sentence.
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?
With no output schema, the description compensates by specifying the exact JSON return shape: { days_inventory_outstanding, inputs }. It also explains error behavior, parameter constraints, and provides a concrete example, making the tool fully callable by an agent.
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 schema already fully documents all three parameters with descriptions, examples, and constraints. The description's PARAMETERS section largely mirrors the schema and adds little new meaning beyond tying the inputs to the DIO formula, so the baseline of 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 days inventory outstanding (DIO)', followed by a definition and the formula DIO = 365 / Inventory Turnover. This clearly differentiates it from sibling tools like DSO, DPO, and inventory turnover by focusing on the inventory holding period.
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, noting that DIO assesses inventory efficiency and capital tied up in stock, and warning against mechanical cross-industry application. It does not name sibling alternatives such as calculate_inventory_turnover or calculate_days_sales_outstanding, which would make the routing fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate days payables outstanding (DPO): the average number of days a company takes to pay its suppliers. Formula: DPO = 365 / Payables Turnover. WHEN TO USE: Use to measure how long a company holds onto cash before paying suppliers — a source of working-capital financing. WHEN NOT TO USE: Do NOT treat very high DPO as always positive — it can indicate cash stress or strained supplier relationships. 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 { days_payables_outstanding: number of days (e.g. 48.7), inputs }. PARAMETERS: cogs_or_purchases (required): Cost of goods sold or purchases for the period, e.g. 600000. Must be > 0. begin_payables (required): Accounts payable at period start, e.g. 70000. Must be >= 0. end_payables (required): Accounts payable at period end, e.g. 90000. Must be >= 0.
| Name | Required | Description | Default |
|---|---|---|---|
| end_payables | Yes | Accounts payable at period end, e.g. 90000. Must be >= 0. | |
| begin_payables | Yes | Accounts payable at period start, e.g. 70000. Must be >= 0. | |
| cogs_or_purchases | Yes | Cost of goods sold or purchases for the period, e.g. 600000. Must be > 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent/destructive annotations by stating the calculation is pure deterministic, has no side effects, no network or storage access, and that identical inputs produce identical outputs. It also discloses the edge-case behavior: division by zero or non-finite inputs return an explicit error.
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?
Well-structured with clear labeled sections (WHEN TO USE, BEHAVIOUR, RETURNS, PARAMETERS) and front-loaded purpose. It is somewhat wordy for a simple three-parameter calculator, but each section contributes distinct information.
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?
Complete for a deterministic financial calculator: the description covers purpose, formula, input constraints, error behavior, and return shape, while the annotations cover the safety profile. There is no output schema, so the explicit RETURNS description is especially valuable.
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?
The schema already has 100% coverage with per-parameter constraints, so the baseline is 3. The description adds meaningful financial context by naming each input's economic role (COGS/purchases, period-start and period-end payables) and reinforcing the >0/>=0 constraints with examples.
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?
States a specific verb ('Calculate') with the resource 'days payables outstanding' and defines it as 'the average number of days a company takes to pay its suppliers.' The formula and DPO definition make it clearly distinguishable from sibling turnover and cycle metrics.
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?
Includes an explicit WHEN TO USE section explaining the cash-management question this metric answers. However, the WHEN NOT TO USE section is an interpretive caveat about interpreting high DPO rather than a routing instruction to an alternative sibling tool, so it stops short of a fully explicit alternatives-based guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate days sales outstanding (DSO): the average number of days it takes a company to collect payment after a sale. Formula: DSO = 365 / Receivables Turnover. WHEN TO USE: Use to measure collection speed and working-capital drag; rising DSO ties up cash and may signal collection problems. WHEN NOT TO USE: Do NOT use when credit sales are unknown (mixed cash/credit revenue distorts the result). 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 { days_sales_outstanding: number of days (e.g. 45.6), inputs }. PARAMETERS: net_credit_sales (required): Net credit sales for the period, e.g. 800000. Must be > 0. begin_receivables (required): Accounts receivable at period start, e.g. 95000. Must be >= 0. end_receivables (required): Accounts receivable at period end, e.g. 105000. Must be >= 0.
| Name | Required | Description | Default |
|---|---|---|---|
| end_receivables | Yes | Accounts receivable at period end, e.g. 105000. Must be >= 0. | |
| net_credit_sales | Yes | Net credit sales for the period, e.g. 800000. Must be > 0. | |
| begin_receivables | Yes | Accounts receivable at period start, e.g. 95000. Must be >= 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The BEHAVIOUR section goes well beyond the annotations by specifying 'pure deterministic calculation — no side effects, no network or storage access', idempotence, and exact error behavior for division by zero or non-finite inputs. This provides valuable safety and execution clarity. The description aligns perfectly with the readOnly, idempotent, and non-destructive 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 well-structured with labeled sections (FORMULA, WHEN TO USE, WHEN NOT TO USE, BEHAVIOUR, RETURNS, PARAMETERS) and front-loads the core meaning. It is longer than strictly necessary and repeats some annotation and schema information, 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?
The description covers purpose, usage context, behavioral guarantees, return shape, and most parameter semantics. It lacks a complete parameter listing in the text, but the rich input schema fills that gap. The output is described adequately even without an output schema.
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 high, the description's PARAMETERS section is misleading: it lists only net_credit_sales and begin_receivables as required and completely omits end_receivables, despite three required parameters. It also gives the formula 'DSO = 365 / Receivables Turnover' without explaining how the inputs translate into receivables turnover. This partial and incomplete parameter explanation can mislead an agent about required inputs.
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 clearly states the tool's function with a specific verb and resource: 'Calculate days sales outstanding (DSO): the average number of days it takes a company to collect payment after a sale.' It is distinct from the sibling turnover calculations because it focuses on collection speed and DSO. However, it does not explicitly name or contrast itself with any sibling tool, so it falls just short of full differentiation.
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 a concrete condition to avoid using the tool (mixed cash/credit revenue). It does not name specific alternatives, but it gives clear context for when this metric is appropriate. This is strong guidance, though not as complete as naming sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate fixed asset turnover: net sales divided by average net fixed assets — how efficiently a company uses its plant, property and equipment to generate sales. Formula: Fixed Asset Turnover = Net Sales / Average Net Fixed Assets. WHEN TO USE: Use for capital-intensive businesses to gauge whether fixed assets are earning their keep (e.g. manufacturing, logistics). WHEN NOT TO USE: Do NOT use for asset-light businesses (software, services) where the ratio is misleadingly high and uninformative. 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 { fixed_asset_turnover: number (e.g. 2.1 = 2.1x per year), inputs }. PARAMETERS: net_sales (required): Net sales / revenue for the period, e.g. 900000. Must be >= 0. begin_net_fixed_assets (required): Net fixed assets (PP&E after depreciation) at period start, e.g. 400000. Must be >= 0. end_net_fixed_assets (required): Net fixed assets at period end, e.g. 450000. Must be >= 0.
| Name | Required | Description | Default |
|---|---|---|---|
| net_sales | Yes | Net sales / revenue for the period, e.g. 900000. Must be >= 0. | |
| end_net_fixed_assets | Yes | Net fixed assets at period end, e.g. 450000. Must be >= 0. | |
| begin_net_fixed_assets | Yes | Net fixed assets (PP&E after depreciation) at period start, e.g. 400000. Must be >= 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description adds concrete behavioral details: pure deterministic calculation, no network/storage access, identical inputs always yield identical outputs, and explicit error behavior on division by zero or non-finite inputs. This fully informs the agent about side effects and edge cases.
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 labeled sections (formula, WHEN TO USE, BEHAVIOUR, RETURNS, PARAMETERS) and front-loads the core definition. It is somewhat verbose and repeats schema parameter descriptions, but each section earns its place for a financial calculation tool with 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?
With no output schema, the description fully explains the return format as a JSON object with fixed_asset_turnover and inputs. It covers edge cases (division by zero), usage guidance, behavior, and parameter constraints. Given the tool's low complexity and rich annotations, 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% with examples, so baseline is 3. The description adds value by explaining that the formula uses the average of begin and end net fixed assets, which is not in the schema, and by providing a concrete numeric example (900000/400000/450000) in context. This goes beyond simple parameter repetition.
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 ('Calculate'), the exact resource ('fixed asset turnover'), and the formula ('Net Sales / Average Net Fixed Assets'). It clarifies that this refers to net fixed assets (PP&E after depreciation), distinguishing it from the sibling calculate_asset_turnover. This makes the tool's purpose unambiguous.
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 give clear context: use for capital-intensive businesses like manufacturing/logistics, avoid for asset-light businesses like software/services. However, it does not name an alternative sibling tool to use instead, so the guidance stops short of a full routing recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate inventory turnover: cost of goods sold divided by average inventory — how many times inventory is sold and replaced in a period. Formula: Inventory Turnover = COGS / Average Inventory. WHEN TO USE: Use to assess inventory management and demand strength; rising turnover usually means better stock discipline or strong demand. WHEN NOT TO USE: Do NOT use COGS-based turnover for service businesses with negligible inventory, and always pair with days inventory outstanding for intuition. 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 { inventory_turnover: number (e.g. 6.0 = 6.0x per year), inputs }. PARAMETERS: cogs (required): Cost of goods sold for the period, e.g. 600000. Must be >= 0. begin_inventory (required): Inventory at period start, e.g. 90000. Must be >= 0. end_inventory (required): Inventory at period end, e.g. 110000. Must be >= 0.
| Name | Required | Description | Default |
|---|---|---|---|
| cogs | Yes | Cost of goods sold for the period, e.g. 600000. Must be >= 0. | |
| end_inventory | Yes | Inventory at period end, e.g. 110000. Must be >= 0. | |
| begin_inventory | Yes | Inventory at period start, e.g. 90000. Must be >= 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description goes well beyond the annotations by stating it is a pure deterministic calculation with no side effects, no network or storage access, idempotence, and identical outputs for identical inputs. It also discloses error behavior for division by zero or non-finite inputs. This fully matches 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 labeled sections (WHEN TO USE, BEHAVIOUR, RETURNS, PARAMETERS) and front-loads the definition and formula. It is slightly repetitive because the PARAMETERS section duplicates the schema descriptions, which are already present and complete, preventing a perfect score.
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?
There is no output schema, so the RETURNS section rightly provides the JSON shape and an example. The description covers the formula, common use, exclusion, error handling, and all parameters. Nothing critical is missing for an agent to invoke this deterministic calculator 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 coverage is 100%, so the baseline is 3. The description adds semantic value by presenting the formula, which clarifies that begin_inventory and end_inventory are combined into an average, and by showing an example output. The parameter list largely repeats the schema, but the formula provides the extra relationship.
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 opens with a specific verb and resource: 'Calculate inventory turnover' plus the formula COGS / Average Inventory and the meaning 'how many times inventory is sold and replaced in a period.' This unambiguously distinguishes it from sibling tools such as calculate_asset_turnover or calculate_days_inventory_outstanding.
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 'WHEN TO USE' section states the intended business assessment, and 'WHEN NOT TO USE' warns against service businesses and instructs pairing with days inventory outstanding. It explicitly names a sibling metric as a complement, giving the agent clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate payables turnover: purchases (or COGS) divided by average accounts payable — how many times a company pays its suppliers in a period. Formula: Payables Turnover = COGS or Purchases / Average Accounts Payable. WHEN TO USE: Use to assess supplier payment speed and working-capital management; lower turnover means the company stretches supplier credit longer. WHEN NOT TO USE: Do NOT interpret low payables turnover as inefficiency without context — it can be a deliberate financing strategy. 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 { payables_turnover: number (e.g. 7.5 = 7.5x per year), inputs }. PARAMETERS: cogs_or_purchases (required): Cost of goods sold or total purchases for the period, e.g. 600000. Must be >= 0. begin_payables (required): Accounts payable at period start, e.g. 70000. Must be >= 0. end_payables (required): Accounts payable at period end, e.g. 90000. Must be >= 0.
| Name | Required | Description | Default |
|---|---|---|---|
| end_payables | Yes | Accounts payable at period end, e.g. 90000. Must be >= 0. | |
| begin_payables | Yes | Accounts payable at period start, e.g. 70000. Must be >= 0. | |
| cogs_or_purchases | Yes | Cost of goods sold or total purchases for the period, e.g. 600000. Must be >= 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly discloses that the calculation is pure, deterministic, idempotent, non-destructive, and has no side effects or network/storage access—which complements the annotations (which already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false). It also adds edge-case behavior (division by zero returns an explicit error), which is useful beyond the 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 sections (formula, when to use, when not to use, behavior, returns, parameters), front-loading the key information. Every sentence serves a purpose and there is no redundancy.
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?
The description covers the formula, usage guidance, behavioral traits, edge cases, return format, and parameter details—comprehensive for a pure calculation tool. There is no output schema, but the description spells out the return shape, so an agent has enough to invoke it correctly. Minor gap: it doesn't specify precision/rounding for the output, but the example suffices.
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?
The schema has 100% description coverage for all three parameters, so the baseline is 3. The description adds value by explaining the role of cogs_or_purchases and begin/end payables in the formula and providing realistic examples, which helps an agent understand what values to supply.
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 clearly states the formula and purpose—measuring how many times a company pays its suppliers in a period. This distinguishes it from sibling tools like calculate_inventory_turnover and calculate_days_payables_outstanding, which are named as separate metrics.
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, explaining when to apply the metric and warning against misinterpreting low turnover as inefficiency without context. This provides clear guidance for an agent deciding whether to invoke 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 receivables turnover: net credit sales divided by average accounts receivable — how efficiently a company collects money owed by customers. Formula: Receivables Turnover = Net Credit Sales / Average Accounts Receivable. WHEN TO USE: Use to assess collection efficiency and customer credit quality; a falling ratio signals slower collections or looser credit terms. WHEN NOT TO USE: Do NOT use total revenue if a large share of sales is cash (use credit sales only), and pair with days sales outstanding for intuition. 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 { receivables_turnover: number (e.g. 8.0 = 8.0x per year), inputs }. PARAMETERS: net_credit_sales (required): Net credit sales for the period, e.g. 800000. Must be >= 0. begin_receivables (required): Accounts receivable at period start, e.g. 95000. Must be >= 0. end_receivables (required): Accounts receivable at period end, e.g. 105000. Must be >= 0.
| Name | Required | Description | Default |
|---|---|---|---|
| end_receivables | Yes | Accounts receivable at period end, e.g. 105000. Must be >= 0. | |
| net_credit_sales | Yes | Net credit sales for the period, e.g. 800000. Must be >= 0. | |
| begin_receivables | Yes | Accounts receivable at period start, e.g. 95000. Must be >= 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=true, idempotentHint=true, destructiveHint=false; the description adds genuinely new behavioral context beyond them: no side effects/network/storage access and, importantly, that division by zero or non-finite inputs returns an explicit error rather than a number. Some content restates annotations (idempotent, non-destructive), but the error-behavior disclosure is valuable for correct invocation. No contradiction.
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?
Well-structured with labeled sections (WHEN TO USE, WHEN NOT TO USE, BEHAVIOUR, RETURNS, PARAMETERS) and front-loaded purpose sentence. However, the PARAMETERS section duplicates schema descriptions and the BEHAVIOUR section repeats annotation hints, adding mild redundancy to an otherwise efficient layout.
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?
Despite no output schema, the description explicitly documents the return shape ({ receivables_turnover: number, inputs }), provides the formula, usage boundaries, edge-case behavior, and complete parameter semantics. For a 3-parameter deterministic calculation tool, 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 description coverage is 100%, so the schema fully documents all three parameters; the PARAMETERS section largely mirrors the schema (same examples, same constraints). The formula body adds relational meaning (numerator vs. denominator, average = begin/end), but the per-parameter text adds no value beyond the schema, so baseline 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?
States a specific verb and resource ('Calculate receivables turnover'), gives the operational definition (net credit sales divided by average accounts receivable), and provides the explicit formula. This clearly differentiates it from siblings like days_sales_outstanding (which it names as the paired metric) and inventory/payables/asset turnover variants.
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?
Has explicit WHEN TO USE ('assess collection efficiency and customer credit quality') and WHEN NOT TO USE ('Do NOT use total revenue if a large share of sales is cash') sections. It also names the alternative sibling, days sales outstanding, telling the agent to pair with it for intuition — clear routing context with exclusions.
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 calculates a distinct financial efficiency ratio, but some boundaries are close: the turnover/day pairs (e.g., inventory_turnover vs. days_inventory_outstanding) cover conceptually related metrics, and asset_turnover vs. fixed_asset_turnover could initially be confused. The detailed WHEN TO USE guidance does help disambiguate, so misselection risk is low but not zero.
All tool names follow the exact same calculate_<metric> pattern, making the set highly predictable and easy to scan. There are no mixed conventions, position variations, or inconsistent verb forms.
Nine tools is a well-scoped size for a financial efficiency calculation server. Each tool corresponds to a standard, distinct efficiency ratio, and none feel redundant or unnecessary.
The set covers the core efficiency ratio family comprehensively: asset, fixed asset, inventory, receivable, and payable turnover, plus their days-based counterparts and the cash conversion cycle. Minor gaps remain, such as no direct working-capital-turnover or operating-cycle calculator, but agents can assemble those from the existing outputs.