Skip to main content
Glama
DeskCalc Verify

DeskCalc Verify

Official

Check numbers in DeskCalc

verify_numbers

Builds a labelled adding-machine tape in DeskCalc so users can check, correct and confirm figures from receipts, statements or invoices, returning the confirmed total and a cent-exact check.

Instructions

Show numbers as a labelled adding-machine tape in DeskCalc so the user can check every line, correct it and press Confirm. Returns the confirmed total, the lines, the user's corrections and - if you pass the printed figures - a cent-exact check of the document. Use it before you rely on a sum you extracted from receipts, statements or invoices. If the result is "pending", tell the user to finish the check in DeskCalc and call get_verification with the review_id. Line kinds: (1) amount: {label, value}. (2) quantity x unit price: {label, qty, price, value?} - value is the printed line total, checked against qty x price. (3) VAT/sales tax: {type:"tax", rate, included?, value?} - put it after the taxable lines; DeskCalc computes the tax from the subtotal above and recomputes it when the user corrects a line; value is the printed tax amount; included=true for gross prices ("incl. VAT"). (4) discount/surcharge in percent on the subtotal above: {type:"percent", rate, value?} - rate -3 for "3 % Rabatt", -2 for "2 % Skonto", +5 for a surcharge; value is the printed amount. A DISCOUNT ON A SINGLE POSITION ("Rabatt"/"Disc." column): {label, qty, price, discount: 10, value: printed line total} - discount in percent; DeskCalc shows qty x price and the discount below it, the check compares the printed line total. Never derive the discount from the printed total. Prices per 100/1000 units: convert to a unit price or give the line total as an amount. (5) MIXED TAX RATES (e.g. 20 % and 10 % on one invoice): a tax line always applies to the whole subtotal above, so put the positions of each rate in their own group: {type:"group", label:"20 %"}, its positions, its tax line; then {type:"group", label:"10 %"}, ... DeskCalc adds a GT (grand total) line. If the result has gt_outdated=true (the user corrected a line, the GT line is a snapshot), call verify_numbers again with exactly the arguments in "rerun" and use that second result. (6) MANY RECEIPTS (expenses, a stack of bills): ONE call, ONE tape - one amount line per receipt (label "14.10. Hotel"), never one call per receipt. If the receipts print their VAT, ALWAYS give each receipt its own group: the gross amount, then its tax line with included=true and the PRINTED VAT as value - only then can a misprinted VAT be found (the GT is still the total of the receipts). If an expense report prints a total, pass it as expected_total. (7) PRINTED SUBTOTALS / CARRY-OVERS (bank statement, ledger over several pages, "Übertrag", "Zwischensumme"): {type:"subtotal", label:"Übertrag S.1", value} at that place - DeskCalc shows the running total there and the check names the first carry-over that is wrong. An opening balance is a normal amount line. (8) CROSS-FOOTING A TABLE (net, tax, gross columns): one line per row {label, value: gross, net, tax} and nothing else in that call; pass expected_total (gross column total), expected_net_total and expected_tax_total if printed (row_labels: omit - the tape uses DeskCalc's language). DeskCalc shows each row as its own block: net, tax, and the printed gross as a checkpoint. (9) FOREIGN CURRENCY: {label, foreign: 100, currency:"USD", fx_rate: 0.92, value: 92.00} - fx_rate is home currency per 1 unit; if the document quotes the inverse (1 EUR = 1.08 USD), give the printed home amount as a plain amount line and name the rate in the label. For invoices also pass expected_total (the printed amount payable). After a confirmed check, offer save_audit_record (PDF for the working papers); to reconcile two documents (invoice vs delivery note, order or payment), verify both, then call compare_verifications. If you use a figure that is NOT printed on the document (e.g. a fee from a published table, a rate you looked up), say so in the label, e.g. "(Tab. A, web)", and tell the user - the tape must not make your own assumptions look like the document. Numbers: plain, "." as decimal separator, negative for credits. Labels: SHORT, max ~25 characters, e.g. "Pos.1 Wandfarbe" or "14.10. Hotel" - longer labels are cut off on the tape. Title: 1-3 words; it becomes the tab name in DeskCalc.

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": {
      "title": "<title>",
      "items": "<items>"
    },
    "name": "verify_numbers"
  }
}

Input Schema

NameRequiredDescriptionDefault
itemsYesThe lines in document order.
titleYesShort tab name, e.g. "Baumarkt 10/26" or "Spesen Oktober".
row_labelsNoCross-footing: tape labels of the net, tax and gross lines. Omit: DeskCalc's language is used.
wait_secondsNoHow long to wait for the user before returning "pending" (default 45 s).
expected_totalNoThe printed total / amount payable of the document, checked to the cent against the confirmed tape.
replace_review_idNoSecond pass after gt_outdated: the review_id from "rerun" - DeskCalc reuses that tab.
expected_net_totalNoCross-footing: printed total of the net column.
expected_tax_totalNoCross-footing: printed total of the tax column.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only cover the safety/idempotency profile; the description adds the real behavior: the tape is user-editable and blocks until Confirm, wait_seconds defaults to 45 s, a 'pending' outcome is possible, gt_outdated forces a second pass with the exact 'rerun' arguments, and labels are truncated at ~25 chars. It also warns that non-document figures must be disclosed so the tape doesn't launder assumptions.

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 organized as numbered line kinds (1)-(9), and nearly every sentence carries an operational rule. It is still a dense wall of text spanning many distinct scenarios, so scanning cost is high; light grouping or headers would improve it.

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?

Covers the hard cases an agent would otherwise get wrong: mixed tax rates needing groups, receipt stacks as one call, printed carry-overs, cross-footing with expected_net_total/expected_tax_total, and foreign currency. With no output schema, it still explains the outcomes (confirmed total, corrections, cent-exact check, pending, gt_outdated) adequately.

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?

Despite 100% schema coverage, the description adds composition rules the schema cannot express: which item fields combine for each line kind, that tax lines apply to the whole subtotal above, that discount must never be derived from the printed total, and that fx_rate is home-per-one-unit with the inverse-printing workaround. This is genuine meaning beyond the field-level docs.

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 specific verb and resource ('Show numbers as a labelled adding-machine tape in DeskCalc') plus the intended user action (check, correct, press Confirm) and names the sibling it hands off to (get_verification). An agent can distinguish it from compare_verifications and save_audit_record directly from the text.

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?

Explicitly says when to use it ('before you rely on a sum you extracted from receipts, statements or invoices'), what to do on 'pending' (tell the user, call get_verification with review_id), when to re-call with 'rerun', and when to chain save_audit_record or compare_verifications. Routing to every sibling is named.

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