Skip to main content
Glama

Senaro Personal Finance

Payoff Strategy Comparison

compare_strategies
Read-onlyIdempotent

Calculation, not advice. Verify with a professional before acting. Compare avalanche and snowball payoff strategies side-by-side. Returns months, total interest, payoff order, savings, total_balance, weighted_average_apr_pct, monthly_interest_now, and cost_breakdown array. When an arm is not projected to reach a zero balance, the savings.* fields for that arm carry status: "none" with value: null and an explanation, not a number. savings.strategies_convergence separately discloses the avalanche/snowball arms' own convergence: "both_converge" (ordinary case), "worst_never_amortizes" (the losing strategy arm does not reach a zero balance in this projection but the winning arm does, so savings.best_vs_worst_months/interest carry status: "none"), or "neither_converges" (the WINNING strategy arm does not reach a zero balance either, so no dollar or month figure derived from either strategy arm is reportable). lower_total_interest_strategy names whichever of avalanche or snowball has the lower total interest, or "tie" when the two arms' total interest and months are exactly equal. A "tie" can co-occur with savings.strategies_convergence="neither_converges". It reports only that comparison, never that either arm pays off. chart_hints.title and chart_hints.annotations[0].label report a dollar figure only when the comparison they describe is Defined, and otherwise state plainly that no figure is reportable, matching the "none" status on the corresponding savings.* field. Unlike chart_hints, summary and savings.savings_summary hedge rather than decline a figure, and the two always carry the same sentence as each other: when the compared arm does not converge (savings.baseline_never_amortizes=true, or savings.strategies_convergence=worst_never_amortizes) but the winning side still does, both report a figure hedged as a floor, "saves at least $X and N months ..., so the true saving could be higher than reported". Only when strategies_convergence=neither_converges do summary and savings.savings_summary also state that no figure is reportable. No savings.* sentinel object carries a hedged floor in its value key; the only place a floor ever appears is the savings.savings_summary sentence. This tool carries no domain-shaped warnings[].type entries (unlike calculate_cc_payoff); warnings[] here is exclusively validation disclosures emitted as warnings[].code, e.g. MINIMUM_PAYMENT_NOT_BINDING_IN_BASELINE plus the general portfolio findings (MANY_CARDS, HIGH_CARD_BALANCE, etc.) shared with every card-based tool. The response includes chart_hints with rendering directives any client can use. The senaro-charts MCP server renders them locally over stdio only. Use output: 'summary' (default) for a compact response or 'inline' for the full payload. output: 'capture' writes the full payload to a file on this server's local disk and returns a capture_ref URI for chart rendering; available on the local stdio transport only, and rejected with a structured error on the hosted HTTP transport, where a capture_ref would be a dead link for a remote caller.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toolArgumentsYesJSON object with these parameters: cards (REQUIRED array, max 20): same format as calculate_cc_payoff - name, purchase_balance, purchase_apr_pct (REQUIRED) - cash_advance_balance, cash_advance_apr_pct (optional) - minimum_payment (OPTIONAL, omit or 0 to auto-calculate) - annual_fee: decimal >= 0 (optional, default 0). Charged at month 1 and every 12th month thereafter. - plan_fees_monthly: decimal >= 0 (optional, default 0). Charged every month while the card has a balance. - segments: array (OPTIONAL; when present, supersedes purchase_balance / cash_advance_balance). Max 100 segments total across all cards in the request. Per-card, per-type caps: 1 purchase, 1 cash_advance, 5 balance_transfer, 1 promotional, 10 installment_plan. Same per-segment shape as calculate_cc_payoff; see that tool's segments[] documentation for the full field list. extra_monthly_payment: decimal >= 0 (optional, default 0) (Note: fixed_payments is NOT a parameter of this tool, unlike calculate_cc_payoff. Avalanche and snowball are always compared under the canonical constant rolled-forward payment, see comparison_basis in the response. Passing fixed_payments returns an unknown_parameter error.) apply_rate_cap: bool (optional, default false) chart_title: string (optional) override for the chart title. Must not contain em-dashes or en-dashes. Max 120 characters. output: 'summary' | 'inline' | 'capture' (optional, default 'summary') 'capture' is available on the local stdio transport only; the hosted HTTP transport rejects it with a structured error naming 'summary' and 'inline' as the valid alternatives.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Goes far beyond the readOnly/idempotent annotations: it discloses the 'none' sentinel semantics for non-converging arms, the strategies_convergence states (both_converge / worst_never_amortizes / neither_converges), how summary/savings_summary hedge as floors while chart_hints decline figures, that warnings[] carries only validation codes, and the capture transport restriction. This is exactly the kind of mutation/edge-case context annotations cannot supply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded well with 'Calculation, not advice' followed by the purpose, but the remainder is a dense wall of sentinel-status prose for a single-parameter tool. Most sentences carry technical weight, yet the reconstruction of return-field behavior is verbose enough to impede scanning.

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 fully carries the return-value burden: it enumerates returned fields and exhaustively documents the sentinel, convergence, hedging, and chart_hints semantics. An agent has everything needed to interpret responses correctly.

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?

Schema description coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains that fixed_payments is intentionally absent (returns unknown_parameter), the semantics of each output mode, and the chart_title dash/length constraint. The 'capture on stdio only' detail materially clarifies the output parameter.

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: 'Compare avalanche and snowball payoff strategies side-by-side.' It also names the concrete sibling it is not (calculate_cc_payoff), noting fixed_payments is not a parameter here, so an agent can distinguish it from the single-strategy payoff tools.

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 for the output modes ('summary' for compact, 'inline' for full, 'capture' for file rendering) and states the transport constraint on 'capture' (stdio only, rejected on HTTP). It also distinguishes itself from calculate_cc_payoff via the fixed_payments exclusion. It stops short of an explicit 'use this instead of X when Y' routing statement against the broader sibling set.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources