Skip to main content
Glama

Senaro Personal Finance

Credit Card Starting Figures

calculate_cc_starting_figures
Read-onlyIdempotent

Calculation, not advice. Verify with a professional before acting. Read a set of credit cards' starting figures without running a payoff simulation: the balances entered by type, the balance-weighted APR at start, and each card's starting minimum payment with their total. Takes the same cards[] and segments[] as calculate_cc_payoff and no other key. Pick this to show those figures while cards are being entered; pick calculate_cc_payoff for a payoff timeline, total interest or a strategy.

Each starting minimum is computed on the balances entered, with one month's interest projected. Per card, the representative formula takes the larger of two amounts on the balance outside installment plans: $25, or that month's interest plus 1% of that balance after the interest. The formula applies only when that balance is above $0. Each plan that still has a balance adds its payment to the card's minimum. The card's minimum is then capped at one total: its balance outside installment plans after that month's interest, plus, for each plan, the smaller of its payment and what it still owes. No annual fee, plan fee, recurring spend or supplied minimum_payment enters it; each such field, when supplied, draws a warning naming its path.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "cards": "<cards>"
    },
    "name": "calculate_cc_starting_figures"
  }
}

Input Schema

NameRequiredDescriptionDefault
cardsYesCredit cards to read starting figures for, 1 to 20. Required: omitting the field answers contract_error MISSING_REQUIRED_FIELD, while an explicit JSON null answers parse_error ("cards is required and must be an array."); the two are not the same rejection. Every card may carry segments[]. 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover read-only, idempotent, non-destructive behavior, but the description adds substantive behavioral detail: it explains exactly which starting figures are returned, how the starting minimum is computed, and which supplied fields do not enter the minimum and instead produce warnings. There is no contradiction with 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.

Conciseness4/5

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

The purpose and sibling routing are front-loaded in the first paragraph, with the minimum-payment formula and exclusions following afterward. The description is long and dense, but most of that detail is justified by the calculation's complexity and the absence of an output schema; it is slightly over-specified for a tool-selection definition.

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?

Given the calculation complexity, rich input schema, and lack of an output schema, the description is complete enough: it says what figures are returned, how the minimum is computed, and what happens to non-entering fields. An agent has the context needed to select and call it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already exhaustively documents the `cards`/`segments` structure and field rules. The description adds only the useful but limited note that it accepts the same `cards[]` and `segments[]` as `calculate_cc_payoff` and no other key, which is modest beyond the schema.

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?

The description states a specific verb and resource: reading credit-card starting figures such as balances by type, balance-weighted APR, and each card's starting minimum payment with total. It also explicitly contrasts itself with `calculate_cc_payoff`, so an agent can distinguish the two tools without opening schemas.

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

Usage Guidelines5/5

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

It gives explicit routing guidance: pick this tool to show starting figures while cards are being entered, and pick `calculate_cc_payoff` for a payoff timeline, total interest, or strategy. It also notes that it takes the same `cards[]` and `segments[]` as `calculate_cc_payoff` and no other key.

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