Used Fork Truck

illustrate_financing

Read-only

Illustrate a monthly note the way the finance page does. Pass price, down, aprPercent, and months. Returns the principal, the formula payment, and the rounded dollars the page shows. Arithmetic only. Not a credit offer, not a rate lock, and not a promise a lender will take the deal. Taxes, freight, a battery, and a doc fee are not included. This desk does not publish a rate. The page allows a price from 5000 to 80000, a down payment from 0 through the price, an APR from 0 to 24, and a term of 24, 36, 48, or 60 months. The page opens on 16500, 2000 down, 11 percent, and 36 months as an illustration, not a quoted rate.

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": {
      "price": "<price>",
      "down": "<down>",
      "aprPercent": "<aprPercent>",
      "months": "<months>"
    },
    "name": "illustrate_financing"
  }
}

Input Schema

Name	Required	Description
`down`	Yes	Down payment in USD. The finance page allows 0 through the truck price. Opening illustration: 2000.
`price`	Yes	Truck price in USD. The finance page runs from 5000 to 80000. Opening illustration: 16500.
`months`	Yes	Term in months. The finance page offers 24, 36, 48, or 60. Opening illustration: 36.
`aprPercent`	Yes	Illustrated APR. The finance page runs from 0 to 24. Not a rate from this desk. Opening illustration: 11.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 15, 2026

TDQS

A4.1/5.0

Behavior5/5

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

With readOnlyHint already covering safety, the description still adds real value: it discloses the return shape (principal, formula payment, rounded dollars), clarifies the arithmetic-only nature, and lists what the illustration omits. The 'desk does not publish a rate' and opening-illustration caveats are exactly the behavioral context an agent cannot get from 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?

Front-loaded with purpose and inputs, then returns, then disclaimers, then bounds and defaults. Every sentence carries content, though the numeric ranges and opening illustration are duplicated between the description and the schema property descriptions, adding some redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates by naming the three returned values, so an agent knows what comes back. Constraints, defaults, and the illustrative (non-quoted) framing are all covered; only edge behavior (e.g. rounding rules, validation errors) is left implicit.

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% and the four parameters already carry ranges, the months enum, and defaults. The description restates the same bounds (5000-80000 price, 0-24 APR, 24/36/48/60 months) without adding syntax or format meaning, so it meets but does not exceed the baseline.

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: 'Illustrate a monthly note the way the finance page does,' and names the four inputs and the returned values. It is clearly a payment-illustration calculator, distinguishable from siblings like desk_terms or screen_truck, though it never explicitly contrasts with them.

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 strong when-not framing ('Not a credit offer, not a rate lock, not a promise a lender will take the deal') and scopes what is excluded (taxes, freight, battery, doc fee). It does not route the agent to a named alternative sibling when a real quote is needed, so it stops short of a 5.

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

All Used Fork Truck 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?