Skip to main content
Glama

finance

by com.zoninga
OverviewDiscussionsAdmin

Analytics: Get financial ratios

get_financial_ratios
Read-onlyIdempotent
    Get key financial ratios computed from the user's data.

    Returns pre-computed ratios.

    Three different "debt-to-income" flavors are returned and they are
    not interchangeable; each fits a different use case:

    Returns:
        - savings_rate_pct: (income - expenses) / income * 100
        - expense_ratio_pct: expenses / income * 100
        - debt_to_income_ratio: BALANCE-SHEET LEVERAGE RATIO —
            total liabilities / annual income, as a multiple (e.g. 2.36).
            A normal homeowner sits above 1.0 because mortgage balance
            dwarfs annual income; that's expected for this metric and
            NOT a sign of financial trouble. Suited to net-worth analysis.
        - back_end_dti_pct: MORTGAGE-INDUSTRY BACK-END DTI —
            monthly debt service / monthly gross income, as a percent.
            28% / 36% are the GSE qualifying-mortgage thresholds. Same
            calc the health-score DTI component uses. None when no
            debt accounts have ``minimum_payment`` populated.
        - front_end_dti_pct: MORTGAGE-INDUSTRY FRONT-END DTI —
            housing payment (mortgage P&I + escrow tax + escrow
            insurance) / monthly gross income, as a percent. 28% is
            the standard threshold. None when the user has no mortgage
            accounts. Measures housing affordability, as opposed to
            the "all debt" back-end view.
        - monthly_debt_service: dollar sum of minimum payments across
            active debt accounts (numerator of back_end_dti_pct).
        - monthly_housing_payment: dollar sum of mortgage P&I + escrow
            across active mortgage accounts (numerator of front_end_dti_pct).
        - emergency_fund_months: liquid assets / monthly expenses
        - credit_utilization_pct: CC balances / CC limits * 100
        - financial_assets / financial_net_worth: FINANCIAL-ONLY view
            (excludes hard assets like real estate, vehicles, jewelry).
            These differ from the consumer-facing net worth and balance
            sheet figures, which *include* hard assets and match the
            dashboard.
        - Plus: total_liabilities, annual income/expenses

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description nevertheless adds real behavioral context: edge cases where metrics are None (no debt accounts with minimum_payment, no mortgage accounts) and the warning that the balance-sheet DTI legitimately exceeds 1.0. It stops short of describing formatting or aggregation caveats.

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 purpose is front-loaded and the long metric list is well organized with clear labels. It is verbose for a parameterless read tool and 'Returns pre-computed ratios.' slightly restates the opening sentence, but nearly every line carries differentiating information about the metrics.

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?

With no output schema, the description carries the full burden of explaining return values, and it does so exhaustively – naming each metric, its formula, its unit, and its interpretation. For a no-parameter, read-only analytics tool this leaves no significant gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4 per the rubric. There is nothing for the description to compensate for on the input side.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('get key financial ratios computed from the user's data') and clarifies the scope of what is returned. It implicitly distinguishes itself from siblings like get_net_worth and get_balance_sheet by noting the financial-only view excludes hard assets, but it never names an alternative tool outright, so routing still requires inference.

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

Usage Guidelines3/5

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

Usage context is implied through metric descriptions ('suited to net-worth analysis', 'measures housing affordability'), which hint at when each ratio matters. But there is no explicit statement of when to call this tool versus get_net_worth, get_balance_sheet, or get_income_statement, and no exclusions or prerequisites.

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

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources