Skip to main content
Glama
Sign In
DeskCalc Verify

DeskCalc Verify

Official
by DeskCalc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Reconcile two confirmed tapes

compare_verifications
Read-onlyIdempotent

Compare two confirmed verifications line by line to the cent, revealing matched items, amount mismatches, one-sided positions, and total differences; verify both documents first.

Instructions

Compare the positions of two confirmed verifications to the cent, e.g. invoice vs delivery note, order, or bank statement. Returns matched positions, positions with a different amount (same text), positions only on one side and the difference of the totals. Verify both documents with verify_numbers first.

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": {
      "review_a": "<review_a>",
      "review_b": "<review_b>"
    },
    "name": "compare_verifications"
  }
}

Input Schema

NameRequiredDescriptionDefault
review_aYesreview_id of the first confirmed verification.
review_bYesreview_id of the second confirmed verification.
ignore_signNoCompare amounts without sign (e.g. invoice amounts vs payments shown as negative).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new behavioral content by enumerating the outcome categories (matched positions, amount mismatches with same text, one-sided positions, total difference) and the matching rule (amount to the cent, text-identical).

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?

Three sentences, front-loaded with the core action and scope, followed by return semantics and the prerequisite. No filler or restatement of the tool title.

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?

For a three-parameter, read-only comparison tool with no output schema, the description covers purpose, precondition, matching rule and result categories. It leaves open edge cases such as what happens with unverified or unknown review_ids, but nothing essential to a correct call is missing.

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 review_a, review_b and ignore_sign are already documented precisely, including the sign-agnostic comparison case. The description adds only the soft constraint that both review_ids must refer to confirmed verifications, which is useful but marginal.

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 (compare/reconcile) and resource (two confirmed verifications) plus the precision level ('to the cent'), and gives concrete document-pair examples (invoice vs delivery note, order, bank statement) that make it unmistakable next to verify_numbers and get_verification.

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?

Explicitly requires verifying both documents with verify_numbers first, which is a real precondition, and the examples imply when this tool is the right one. It does not name an alternative or say what to do when documents are unconfirmed or unmatched, so it stops short of full routing guidance.

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

Deploy Server

Other Tools