Moonshot Lab (demo)

compare_payment_scenarios

Use this to compare several financing what-ifs for ONE listing side by side in one call (for example cash down, term, credit tier or APR, trade-in, incentives). Each scenario reruns the itemized out-the-door estimate and returns estimated_out_the_door, amount_financed_estimate, apr_percent and apr_source, term_months, estimated_monthly_payment (rounded to $5) with the unrounded value and an outward-rounded range, total_interest_estimate, total_cost_including_trade_equity (PRIMARY total: cash down plus all payments plus net trade equity given up), cash_outlay_excluding_trade_equity (cash down plus payments only; total_cost_estimate is its deprecated alias) and financing_eligibility with flags (demo rules), plus lowest_monthly, lowest_total_cost (decided by total_cost_including_trade_equity) and lowest_cash_outlay_excluding_trade_equity. Those lowest_* keys are UNFILTERED math winners. Present recommended_scenario, lowest_monthly_eligible or lowest_total_cost_eligible instead: they skip scenarios the demo financing rules flag, so an ineligible scenario is never the recommendation. A scenario {"name":"cash","cash":true} prices paying cash (no loan, no interest); cash_purchase always gives the cash amount due. Each scenario has trade_risk (negative_equity_rolled_in, loan_to_value_pct and warnings, for example LTV over 110%) and credit_tier_source. Prefer this over repeated get_payment_estimate calls. Up to 6 scenarios. For a single scenario use get_payment_estimate. Estimate, not an offer; dealer sets price, lender sets rate. Leases are not modeled.

Input Schema

Name	Required	Description
`buyer_zip`	No	Buyer's five-digit ZIP. Alone it resolves buyer state, county and city (echoed in tax_location.resolution with the source).
`scenarios`	Yes	1 to 6 what-if scenarios, e.g. [{"name":"0 down"},{"name":"3k down 72","down_payment":3000,"term_months":72}]. Omitted fields default to $0 down, 60 months, good credit.
`buyer_city`	No	Buyer's city.
`listing_id`	Yes	dealer_key:VIN from search_inventory.
`buyer_state`	No	Buyer's two-letter state for tax and fees. Default: the selling store's state.
`buyer_county`	No	Buyer's county without 'County'.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 21, 2026

addedInput schema / $defs / PaymentScenario / properties / cash

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "True to price paying cash: no loan or interest; omit apr, term_months, credit_tier and down_payment.",
+  "title": "Cash"
+}

Changed1 schema field changedOct 21, 2026

changedInput schema / properties / buyer_zip / description

Previous value: -"Buyer's five-digit ZIP; sets state and city when buyer_state is omitted."New value: +"Buyer's five-digit ZIP. Alone it resolves buyer state, county and city (echoed in tax_location.resolution with the source)."

Changed1 schema field changedOct 21, 2026

changedInput schema / $defs / PaymentScenario / properties / credit_tier / description

Previous value: -"Picks the demo APR when apr is omitted."New value: +"Picks the demo APR when apr is omitted. Credit tiers (demo APR new / used): excellent about 720 and up (6.0% / 8.5%); good about 660 to 719 (7.5% / 11.0%); fair about 620 to 659 (11.5% / 16.0%); poor below about 620 (15.5% / 20.0%)."

AddedOct 20, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses that lowest_* keys are UNFILTERED math winners, that recommended_scenario/lowest_*_eligible skip demo-rule-flagged scenarios, that an ineligible scenario is never recommended, what cash=true does, and the 'estimate, not an offer; leases are not modeled' caveat. This is rich behavioral context an agent could not infer from the schema.

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 the sibling routing, and every clause carries operational information (return keys, eligibility filtering, caveats). It is dense and run-on, with a heavy enumeration of return fields, but given the tool's complexity and the absence of an output schema that content largely earns its place.

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 complex, 6-parameter tool with no annotations and no output schema, it covers purpose, alternatives, defaults, eligibility semantics, return keys, and limitations. An agent has everything needed to call it correctly and interpret the result.

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; the description adds value by mapping scenario dimensions (cash down, term, credit tier/APR, trade-in, incentives) and spelling out the cash scenario and the $0 down/60 month/good credit defaults. It complements rather than merely repeats 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?

States a precise verb (compare) and resource (financing what-ifs for ONE listing), plus the scope constraint 'side by side in one call'. It explicitly names the sibling it differs from (repeated get_payment_estimate calls / get_payment_estimate for a single scenario), so an agent can route without opening a schema.

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?

Gives explicit when-to-use and when-not: 'Prefer this over repeated get_payment_estimate calls' and 'For a single scenario use get_payment_estimate', with a hard limit of 'Up to 6 scenarios'. Alternatives and selection conditions are fully specified.

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

All Moonshot Lab (demo) 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?