finance

Reports: Get debt-paydown analysis

get_debt_paydown

Read-onlyIdempotent

    Get a debt paydown analysis with payoff projections.

    A call with no arguments returns the user's SAVED plan — their chosen
    strategy plus their saved extra monthly payment, the same numbers the
    Debt Paydown page shows them. Answers questions like "when will I be
    debt-free?" / "what's my payoff date?": `debt_free_date` is the
    report's computed payoff date, and `strategy` is the plan's strategy.
    Passing `strategy` / `extra_monthly` produces a what-if projection
    ("what if I paid $200 extra?") rather than the saved plan.

    Args:
        extra_monthly: Extra monthly payment beyond minimums. Omit to use
            the user's saved extra payment (their plan).
        strategy: Payoff strategy - highest_rate, snowball, variable_snowball,
                   minimum_payments, highest_balance, highest_payment,
                   cashflow_index, npv, max_interest_savings. Omit to use
                   the user's saved plan strategy.
        respect_goal_priorities: When True (default), active debt-payoff
            goals override strategy ordering for the primary projection.
            False shows what the chosen strategy does without goal
            interference. The strategies_comparison table shows pure
            strategy ordering regardless of this flag.

    `this_month` answers "what do I pay this month?" / "which debt
    gets my extra?": `this_month.target` is the debt the plan attacks
    first (`target_basis`: extra_this_month, or first_rollover when no
    extra is set and freed-up payments start rolling to it in
    `first_extra_month`). Each row has payment (the amount to send =
    minimum_payment + extra), minimum_payment (the account's stated
    minimum), and plan_minimum_payment / plan_payment (the projection's
    amortized figures, which can differ by a few dollars).

    Returns:
        Debt payoff timeline (incl. debt_free_date, the computed payoff date),
        this_month (per-debt payments + the target debt), interest
        savings, strategy comparison, and is_user_saved_plan (True when
        the projection is the user's own saved plan).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`strategy`	No
`extra_monthly`	No
`respect_goal_priorities`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 22, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, and the description adds substantial context beyond them: the saved-plan-vs-what-if distinction, respect_goal_priorities overriding strategy ordering, why plan_minimum_payment can differ from minimum_payment, and the is_user_saved_plan output flag. This is rich behavioral disclosure for a read-only report.

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?

Well front-loaded with the core saved-plan/what-if distinction, then organized into Args and Returns sections that each earn their place. It is dense and slightly long with a few embedded asides (e.g., the amortized-figure caveat), but there is little outright waste.

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 steps in to name the key return fields (debt_free_date, strategy, this_month.target/target_basis, first_extra_month, is_user_saved_plan) and their meaning. Combined with the parameter and mode coverage, an agent has everything needed to call and interpret this tool correctly.

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

Parameters5/5

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

Schema coverage is 0%, so the description must carry the full load, and it does: extra_monthly is defined as payment beyond minimums with omit-behavior, strategy enumerates nine valid values that are absent from the schema, and respect_goal_priorities explains the True-default semantics and the strategies_comparison exception. Nothing about the parameters is left undocumented.

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

Purpose5/5

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

States a specific verb and resource ('Get a debt paydown analysis with payoff projections') and immediately pins down the two operating modes: no-arg returns the saved plan, while passing strategy/extra_monthly produces a what-if projection. No sibling among the ~130 tools offers debt-payoff projection, so the scope is unambiguous without opening the schema.

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

Usage Guidelines4/5

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

Gives clear context-based guidance: omit arguments for the saved plan, pass strategy/extra_monthly for a what-if, and it ties the call to concrete user questions ('when will I be debt-free?', 'what do I pay this month?'). It never names an alternative tool or an explicit when-not-to-use condition, so it stops short of the top mark.

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

All finance tools Inspect

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

Need Help?