Skip to main content
Glama
ComplyEaze

ComplyEaze Bridge: TallyPrime MCP server for Claude Desktop

Official

purchase_register

Read-only

Read Purchase and Debit Note vouchers in a date window that touch Duties & Taxes ledgers, showing GST duty-head tax per entry. Read-only; never computes returns or input-credit eligibility.

Instructions

Read-only: a register of what the books record, not a GST return. It does not decide input tax credit eligibility or blocked credit, matches nothing against GSTR-2B or any portal, checks no GSTIN (party_gstin is returned only when the voucher carries one), returns reference_date only when the voucher carries one, as Tally sent it (reference likewise; measured on one synthetic book, on one Purchase), does not classify an item invoice's purchase as taxable (has_taxable_entry is false when no entry sits on a Purchase Accounts ledger), and never sums tax across heads or vouchers. It does not treat reverse-charge journals, imports (IGST paid at customs) or input service distribution specially: a voucher that touches a Duties & Taxes ledger is listed by the rule below and nothing more. A GST duty head does not say whether a ledger is input or output, and a Debit Note can be a purchase return or a debit note issued to a customer: each row carries party_group (the voucher party's predefined group, for example Sundry Creditors or Sundry Debtors, when it resolves) and the tool does not guess which it is. It inherits the compliance read's refusals (an INR base currency is required; a book too large to list is refused; see ledger_masters) and refuses with register_master_mark_unavailable when Tally does not report the master-alteration mark. Each page re-reads the masters and the window, so rows can shift between pages. Return the Purchase and Debit Note vouchers of a date window that touch a ledger under Duties & Taxes, with the tax each entry carries taken only from the GST duty head recorded on that ledger's master -- never from a ledger name and never from an amount. Reads the full voucher window before pagination (use narrow dates) and the ledger masters twice, before and after it. Per row: tax_in_books lists each entry on a ledger whose head ComplyEaze Bridge recognises as {ledger, head, raw_head, amount}; duties_taxes_entries_without_gst_head lists entries on Duties & Taxes ledgers that carry no GST head and never assigns them one: observation not_tax_ledger is a ledger whose own tax type is not GST (usually TDS or another payable), absent is a ledger with no head whose tax type is GST or was not reported, which may be a GST ledger whose head is missing (tax_type says which); duties_taxes_entries_with_unrecognised_head lists entries whose head is not in the recognised vocabulary or contradicts the ledger's tax type, with the raw spelling and its observation; entries_on_ledgers_with_unresolved_group lists entries on ledgers whose group chain could not be resolved; taxable_entries are entries on Purchase Accounts ledgers only (a GST purchase booked to a fixed-asset or expense ledger has has_taxable_entry false); party_entries are the voucher party's own; other_entries is everything else (round-off included) with no role inferred. status is the first that applies of head_conflict, has_unrecognised_head, has_unresolved_group, has_entries_without_gst_head, has_other_entries, complete. The response state follows the rule vouchers uses: complete only when every voucher read was checked against a separate count of the window (a census, which ComplyEaze Bridge sends for every book that has held a voucher, however few), otherwise partial with reason nonempty_window_unqualified and the rows still returned; an empty window is complete when its corroboration read confirms it. A row's status is separate: it says whether every entry the voucher touches classified, and the state does not change it. Amounts are as the books state them (negative is a debit), never re-signed and never summed across heads; there is no input-credit or direction field. reference, party_gstin, is_invoice, post_dated follow vouchers: absent means not observed, and cancelled, optional and post_dated vouchers are returned flagged, not excluded. Every other voucher type that touches Duties & Taxes (Sales, Journal, Payment and so on) is listed apart in other_voucher_types_touching_duties_taxes, not in items: whether it belongs in a return is the CA's call. A voucher with no resolved class is listed under unclassified_voucher_type; a voucher that touches only unplaceable ledgers under vouchers_with_unplaced_ledgers; a Purchase or Debit Note voucher with no entry on a Duties & Taxes ledger under purchase_vouchers_without_duties_taxes_entry (exempt or unregistered purchases, tax booked to a ledger filed elsewhere, or a cancelled voucher). A cancelled voucher is listed there with cancelled true whether or not it was taxed, because the cancelled vouchers measured came back from Tally with no ledger entries; a cancelled voucher that keeps its entries is not measured. Rows are in items (paged by offset and limit like vouchers); each has has_taxable_entry, false when no entry sits on a Purchase Accounts ledger (an item invoice may hold it in an inventory allocation). The side lists carry exact counts (total) and at most 100 items (listed); every ledger name in the response is masked like vouchers masks it. A voucher that names a ledger the masters do not list, a master or voucher that changed while the window was read, or a ledger set aside for its currency, refuses (ledger_snapshot_drifted, voucher_window_changed_during_read, register_ledger_currency_excluded) and releases no rows; a row dated outside the window refuses as window_not_honoured, or as voucher_window_part_not_admitted when the window was counted. A sgst_utgst head is a state-side head that a consumer summing state tax must include alongside state_tax. Not measured: a REFERENCEDATE on a sale, item invoices whose purchase ledger sits in an inventory allocation, and books with several currencies. Each call appends metadata-only receipt lines (tool, company, counts, request and response fingerprints; no book content) to ComplyEaze Bridge's local log on this computer; it writes nothing to Tally.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesThe last day of the date range, included (YYYYMMDD or YYYY-MM-DD).
fromYesThe first day of the date range, included (YYYYMMDD or YYYY-MM-DD).
limitNoThe most rows to return on this page. The default and the maximum are this server's row limit (500 unless it is configured otherwise).
offsetNoHow many rows to skip before this page: 0, the default, is the first page.
company_guidYesThe company's company_guid, as list_companies returns it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.4.3
    • addedInput schema / properties / company_guid / description
      Added value: +"The company's company_guid, as list_companies returns it."
    • addedInput schema / properties / from / description
      Added value: +"The first day of the date range, included (YYYYMMDD or YYYY-MM-DD)."
    • removedInput schema / properties / limit / default
      Removed value: -500
    • addedInput schema / properties / limit / description
      Added value: +"The most rows to return on this page. The default and the maximum are this server's row limit (500 unless it is configured otherwise)."
    • addedInput schema / properties / offset / description
      Added value: +"How many rows to skip before this page: 0, the default, is the first page."
    • addedInput schema / properties / to / description
      Added value: +"The last day of the date range, included (YYYYMMDD or YYYY-MM-DD)."
  2. First observedv0.4.1

TDQS

A4.1/5.0
Behavior5/5

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

Far exceeds the annotations. It discloses pagination instability ('each page re-reads the masters and the window, so rows can shift'), the pre-pagination full-window read, local metadata-only receipt logging, that it writes nothing to Tally, and a full catalogue of refusal codes. Consistent with idempotentHint=false.

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?

A very long wall of text that front-loads a list of negations and buries the actual purpose in the middle. Many individual clauses carry real behavioral content, but the organization makes the definition hard to scan and the lede is lost.

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 tool with no output schema, the description fully documents the return surface: items, side lists with counts, per-row status, and top-level state semantics. An agent has what it needs to interpret results and errors.

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 coverage is 100%, so the baseline is 3. The description adds value by tying from/to to the 'use narrow dates' advice and confirming limit/offset paging behaves like `vouchers`. Most remaining prose concerns output fields rather than input parameters, so it does not go far beyond baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The core purpose is specific verb+resource: 'Return the Purchase and Debit Note vouchers of a date window that touch a ledger under Duties & Taxes.' It clearly distinguishes itself from a GST return and from run-of-the-mill voucher listing. However, this statement is buried after two paragraphs of negative framing, so an agent must read deep before the actual purpose is stated.

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?

Strong context on when-not: it explicitly says it does not decide input tax credit eligibility, does not match GSTR-2B, and does not classify a return. It also advises 'use narrow dates' and defers to 'ledger_masters' for refusals. It does not name sibling alternatives (e.g. sales_register) by condition, so it stops just short of an explicit when-vs-which routing.

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