Skip to main content
Glama

Penny Rounding

by com.gumballtools

Round a cash total the way the post-penny rules actually work

round_cash_total
Read-only

Settle a transaction under post-penny cash rounding: exact subtotal, tax on the exact subtotal, then round the final total to the nearest nickel — and only for cash.

Use this for any "what does X round to" or "what do I owe in cash" question. Four things are wrong in most explanations of this, and each one changes the answer:

  1. CASH ONLY. Card, EFT, and gift-card payments are still priced to the cent. The same basket legitimately comes to two different amounts by tender. If asked about a card payment, do not round.

  2. THE TOTAL, NOT EACH ITEM. Rounding per item multiplies the effect by the basket size. Five items at $0.99 total $4.95 — already a nickel, no rounding — where per-item rounding would collect $5.00.

  3. AFTER TAX. Tax is computed on the exact subtotal and the rounding comes last. Rounding the base first changes the tax owed.

  4. THE DIGIT DECIDES. 1, 2, 6, 7 round down; 3, 4, 8, 9 round up; 0 and 5 stand. Do not reason about "nearest" from scratch, and do not assume rounding is always up.

Input: pass subtotal as a dollar string ("19.99") or items as a list. A NUMERIC amount is read as CENTS and a STRING as dollars — 1999 and "19.99" are the same amount, 19.99 as a number is refused. Pass taxRatePercent as a percentage (8.25, not 0.0825); rounding depends on it, so omitting it usually gives the wrong nickel. tender is cash or card, default cash. rule is symmetric (default), always-down, always-up, or none.

Returns: the exact subtotal, tax, exact total, the rounded amount due, the signed delta, which digit decided it, warnings, and a disclaimer field.

THIS IS NOT LEGAL OR TAX ADVICE. There was no federal rounding law as of September 2026 and state law varies. Do not tell a user what their jurisdiction requires — report the arithmetic and the caveats.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ruleNosymmetric (default) is the Common Cents Act and Canadian method. always-down is Indiana's rule for cash payments of TAX, not a retail rule. always-up is not law anywhere for retail and is here only to quantify it. none is what a card gets.
itemsNoLine items, totalled in exact cents. Rounding applies to the TOTAL only.
tenderNoDefault cash. A card is NEVER rounded — if the user is paying by card, the exact total is the answer and any rounding rule is ignored.
subtotalNoThe pre-tax subtotal. Use this or `items`.
taxRatePercentNoPercentage, e.g. 8.25 — not 0.0825. Supply it whenever it is known: rounding happens after tax, so the rate decides which nickel the total lands on.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

The description goes well beyond the readOnlyHint and openWorldHint annotations. It discloses that rounding applies only to cash, only to the total, only after tax, and only according to the trailing digit; it also warns that omitting taxRatePercent usually gives the wrong nickel and that the tool reports arithmetic, not legal requirements. This is rich behavioral context that prevents serious misuse.

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

Conciseness5/5

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

The description is long but appropriately so given the tool's edge cases. It is front-loaded with the core algorithm, uses bullets to isolate the four failure modes, and every remaining section — input format, return values, and legal caveat — 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?

With no output schema present, the description still enumerates the return fields: exact subtotal, tax, exact total, rounded amount due, signed delta, deciding digit, warnings, and disclaimer. Combined with the detailed parameter semantics and the cash/card rule, the description gives an agent everything needed to invoke the tool correctly and frame the result safely.

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

Parameters5/5

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

Although the schema already documents all parameters, the description adds crucial semantics: numbers are read as cents, strings as dollars, non-integer numbers are refused, taxRatePercent is a percentage like 8.25 rather than 0.0825, and tender defaults to cash. The rule parameter is also tied to legal meanings, which materially reduces incorrect invocation.

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 first sentence states a specific operation — settle a transaction under post-penny cash rounding — and gives the exact algorithm: exact subtotal, tax on subtotal, then round the final total to the nearest nickel for cash only. The cash-only emphasis and the four common-misconception bullets clearly distinguish it from related pricing or rounding-analysis 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?

The description is explicit about when to use it: 'Use this for any "what does X round to" or "what do I owe in cash" question' and when not to apply rounding: card, EFT, and gift-card payments should not be rounded. It does not explicitly name price_band or rounding_impact as alternatives, so it stops just short of full sibling-tool routing.

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

All Penny Rounding toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: price_band finds optimal list prices within a rounding band, round_cash_total computes the exact cash amount for a single transaction, and rounding_impact aggregates rounding effects across many prices. There is no meaningful overlap or ambiguity between them.

Naming Consistency3/5

All names use snake_case and are readable, but they do not follow a single grammatical pattern: price_band is a noun phrase, round_cash_total is verb-object, and rounding_impact is a gerund-noun phrase. This is a mixed convention rather than a predictable verb_noun scheme.

Tool Count5/5

Three tools is well-scoped for this narrow domain. Each tool earns its place by covering a distinct need: single-transaction rounding, pricing decisions, and aggregate impact analysis.

Completeness5/5

The set covers the full practical surface of cash rounding arithmetic: computing a rounded total, optimizing a list price within a rounding band, and measuring aggregate rounding impact over a price list. Supporting options like tender type, tax rate, and rounding rule are included where needed.

Resources