Skip to main content
Glama
ComplyEaze

ComplyEaze Bridge: TallyPrime MCP server for Claude Desktop

Official

verify_import

Destructive

Verify a locally imported batch against Tally, write Proof-of-Post files, and report posted, unverified, and duplicate vouchers without posting to Tally.

Instructions

Read back a manually imported local batch and write Proof-of-Post files. This never dispatches import XML to Tally. The result gives verification_status, counts, every voucher that is not posted_verified (unverified_vouchers; for a native post a voucher may be bound_not_in_window, book_rolled_back or sent_not_attributed, never absence, with post_span_binding naming how the post was attributed and a plain summary to give the person first; a book restored from a backup and then keyed past the post's voucher mark before this check is not seen as rolled back, and if Tally then reused the post's MasterIDs a bound voucher could read posted_verified while being another voucher with the same content: unmeasured, bridge#1050), duplicates, unrelated_duplicates_in_window and ambiguous_within_batch in full, never cut to fit. Only the posted_verified vouchers are paged, as items from offset out of verified_total; when the response cap shortens them it sets truncated and next_offset. To read further pages, call again with proof_sha256 set to the returned proof.sha256 and offset set to next_offset: those pages come from the persisted proof and never read Tally again. The call is refused with verification_proof_changed if a newer verification replaced that proof, and with verification_too_large_to_report if the parts never cut do not fit the response cap. The full proof is always written to disk. Reads the batch's date window from Tally, then creates or replaces the batch's saved proof files and saves a status record, and may also save a verified baseline, a masters-check record and, for a native post, the binding of its vouchers to the Tally vouchers its post created, in ComplyEaze Bridge's local folder on this computer (paging an existing proof only reads it); writes nothing to Tally.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
offsetNo
batch_idYes
company_guidYes
proof_sha256No

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.1

TDQS

A4/5.0
Behavior5/5

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

With annotations present, the description adds substantial depth beyond them: it explains local proof-file writes, status-record creation, possible baseline and masters-check saves, paging via persisted proofs, specific refusal conditions, and that Tally is never written to. This is rich behavioral context that goes well beyond readOnlyHint=false and destructiveHint=true.

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

Conciseness2/5

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

The description is a dense, run-on block with nested parentheticals and semicolon-chained clauses. The first sentence front-loads the purpose well, but the remainder is very difficult to parse and is far longer than necessary for an agent to select and invoke the tool.

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?

Given the tool's complexity, absent output schema, and the available annotations, the description is complete enough: it covers return fields, paging, truncated/next_offset, error refusals, proof persistence, and local file writes. An agent has what it needs to call the tool correctly.

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 0%, so the description must compensate for four parameters. It explains offset and proof_sha256 clearly, and gives context for batch through 'the batch's date window' and 'batch's saved proof files,' but company_guid is never mentioned. Partial compensation justifies a mid-range score.

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 description names a specific verb and resource: 'Read back a manually imported local batch and write Proof-of-Post files.' It also distinguishes itself from an import-dispatch tool by stating it 'never dispatches import XML to Tally.' The purpose is unambiguous and not a restatement of the tool name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains how to page an existing proof using proof_sha256 and offset, which is useful procedural guidance. However, it does not say when to choose this tool over sibling verification or reporting tools, nor does it name alternatives or exclusions beyond the 'never dispatches import XML' limitation.

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