Zovo Installment Planner

Generate installment payment plan

generate_installment_plan

Read-onlyIdempotent

Use this when the user wants a payment plan or installment schedule ("split 1200 into 6 monthly payments", "payment plan template", "installment plan for a customer", "pay this off in 4 payments every 2 weeks", "payment schedule with a deposit"). Pass total_amount, installments or installment_amount, frequency and first_due_date; optional deposit (amount or percent), annual_interest_rate (flat simple interest), rounding_rule, round_to, weekend_rule, payer_name, payee_name, plan_title and reference. Returns exact installment amounts that add up to the total, due dates, the remaining balance after each payment, and a printable PDF schedule with signature lines, an Excel file, a CSV and an ICS calendar file with a reminder before each payment. Ask for the first due date if it is unknown. Does not compute amortizing loan payments or APR, does not collect payments, and is not legal or financial advice.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "generate_installment_plan"
  }
}

Input Schema

Name	Required	Description
`deposit`	No	Optional down payment taken off the total first: an amount, e.g. 300, or a percent of the total, e.g. "20%".
`currency`	No	ISO currency code, e.g. USD (default), EUR, GBP, JPY. A symbol in total_amount (€, £, ¥) also sets it.
`round_to`	No	Make installments multiples of this amount, e.g. 0.01 (default, to the cent), 1, 5 or 10.
`frequency`	No	weekly, biweekly (every 2 weeks), semimonthly (twice a month: the 1st and 15th when the first date is the 1st), monthly (default) or quarterly.
`page_size`	No	PDF page size: Letter (default) or A4.
`reference`	No	Optional reference such as an invoice or account label, e.g. "INV-1042". Do not pass bank or card numbers.
`payee_name`	No	Optional name of the person or business being paid, e.g. "Northside Dental".
`payer_name`	No	Optional name of the person or business paying, printed on the schedule, e.g. "Sam Lee".
`plan_title`	No	Optional title, e.g. "Payment plan for invoice 1042". Default "Payment schedule".
`deposit_date`	No	Optional date the deposit is paid, e.g. "2026-11-15". Without it the deposit is shown as paid on signing.
`installments`	No	Number of installments, 1 to 360, e.g. 6. Give this or installment_amount.
`total_amount`	No	The full amount owed before any deposit, e.g. 1200 or "$2,450.00" or "1.250,00 €".
`weekend_rule`	No	none (default), next_business_day (Saturday or Sunday moves to Monday) or previous_business_day (moves to Friday). Holidays are not known.
`reminder_time`	No	Time of the reminder, e.g. "09:00" (default).
`rounding_rule`	No	remainder_last (default: equal installments rounded down, the last one takes the rest), remainder_first (the first takes the rest) or even_up (each rounded up, the last one is smaller).
`first_due_date`	No	Date of the first installment, e.g. "2026-12-01". Required: ask the user if it is not known.
`installment_amount`	No	Fixed amount of each installment instead of a count, e.g. 250; the last one is the smaller rest.
`annual_interest_rate`	No	Optional flat simple interest in percent a year on the amount paid in installments, e.g. 6 or "5.25%". Default 0 (interest-free).
`reminder_days_before`	No	Days before each due date for the calendar reminder, 0 to 30. Default 2.

Output Schema

Name	Required	Description	Default
`notes`	Yes
`title`	Yes
`total`	Yes
`deposit`	Yes
`currency`	Yes
`financed`	Yes
`interest`	Yes
`last_due`	Yes
`schedule`	Yes
`downloads`	Yes
`first_due`	Yes
`frequency`	Yes
`notes_count`	No
`deposit_date`	Yes
`installments`	Yes
`total_to_pay`	Yes
`schedule_count`	No
`regular_installment`	Yes
`links_expire_minutes`	Yes
`different_installment`	Yes
`total_of_installments`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered; the description goes further by naming the generated artifacts (PDF with signature lines, Excel, CSV, ICS with reminders) and the guaranteed invariant that installment amounts add up to the total. It also discloses an interpretive limitation ("flat simple interest") and disclaims advice, which the annotations cannot express.

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 trigger condition and example phrasings are front-loaded, and the negative scope is correctly placed at the end. It is a single dense paragraph with minimal waste, but the long enumeration of optional parameters and output formats makes it heavier than necessary for an agent that will read the schema anyway.

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?

For a 19-parameter generator with an output schema, the description covers the trigger, the required-ish inputs, the output artifacts and the boundaries of the tool's competence, including telling the agent to ask the user when first_due_date is missing. Nothing an agent needs in order to call it correctly or explain its result is absent.

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 every one of the 19 parameters is already documented with examples and defaults in the schema. The description restates the key inputs (total_amount, installments or installment_amount, frequency, first_due_date, deposit as amount or percent, annual_interest_rate as flat simple interest) but adds no syntax or constraint beyond that baseline. It also omits several supported parameters such as currency, page_size, deposit_date and reminder_time, so it does not supersede 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 opens with a concrete verb and resource ("generate a payment plan or installment schedule") and anchors it with realistic user phrasings ("split 1200 into 6 monthly payments", "pay this off in 4 payments every 2 weeks"). An agent can immediately tell this is a schedule-generation tool rather than a loan calculator or payment collector, which the closing sentence reinforces.

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 an explicit trigger condition ("Use this when the user wants a payment plan or installment schedule"), worked examples of that condition, an operational precondition ("Ask for the first due date if it is unknown"), and explicit exclusions ("Does not compute amortizing loan payments or APR, does not collect payments"). Both the when and the when-not are stated, which is rare.

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

All Zovo Installment Planner 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?