Skip to main content
Glama
ComplyEaze

ComplyEaze Bridge: TallyPrime MCP server for Claude Desktop

Official

gst_by_counter_ledger

Read-only

Reads GST from Duties & Taxes on eligible purchase, debit note, journal and payment vouchers, totals tax per counter ledger for a date window, and sets aside unassignable vouchers.

Instructions

Read-only: the GST the books record, totalled per counter ledger, for a date window; not a return figure. It does not decide input tax credit eligibility, blocked credit, what was availed, input versus output, or which row of any return a ledger belongs in, and matches nothing against any portal. It reads what purchase_register and sales_register read (the ledger masters twice, the full voucher window, the same drift checks and refusals) and, for every voucher with an entry on a ledger under Duties & Taxes whose master carries a recognised GST duty head, takes that tax per head and attributes it to the voucher's one ledger under Purchase Accounts, Direct Expenses, Indirect Expenses or Fixed Assets, only when the voucher is a Purchase, Debit Note, Journal or Payment with a ledger under Sundry Creditors on it, has exactly one such counter ledger (a round-off ledger under Indirect Expenses counts as one), and nothing besides but the party, cash, bank and TDS or TCS ledgers: a duty head does not say input or output, so a sale, a credit note or a tax payment with no supplier on it is never attributed. counter_ledgers lists each such ledger with its ledger_guid (Tally's GUID of the ledger, which trial_balance returns as the ledger's guid; its movement there covers every voucher on it, set-aside ones included, so it is never a base for this tax), its predefined group, its parent (masked like a ledger name when it is a group the book named), vouchers, debit_side_tax (negative, as the books state it) and credit_side_tax (positive: tax booked back, which can be a reversal or output tax on an asset or goods returned or sold to a supplier; the tool does not tell them apart), per head (cgst, igst, state_tax, sgst_utgst, ut_tax, cess; state_tax and sgst_utgst are both state-side and kept apart), never netted. Every other voucher with GST is set aside in set_aside under the first reason that applies, with its count, its own tax totals and at most 100 vouchers listed: class_not_admitted (any class but Purchase, Debit Note, Journal and Payment: sales, credit notes, memoranda), head_conflict, unrecognised_head, head_absent (a Duties & Taxes ledger that may be GST has no head), duty_ledger_without_gst_type (a Duties & Taxes ledger typed neither GST nor TDS or TCS, such as Others, which may be a GST ledger left untyped), unresolved_group (a ledger whose group does not resolve, which may be a GST ledger), sign_and_flag_disagree, entries_do_not_balance (a ledger sits where this read does not look, such as an item invoice of a shape not measured whose purchase ledger is in an inventory allocation), sales_ledger_present (sales and credit notes), gst_on_both_sides (reverse-charge and set-off journals), other_ledgers_present (a ledger under any other group, such as Current Assets or Stock-in-Hand), no_creditor_party (no ledger under Sundry Creditors, such as a GST challan payment), no_counter_ledger and several_counter_ledgers. Nothing is apportioned. Cancelled, optional and post-dated vouchers are counted, not totalled (vouchers_cancelled_optional_or_post_dated); vouchers_without_gst_entry counts the vouchers with no Duties & Taxes entry of any kind but TDS or TCS, and vouchers_observed every voucher of the window. A window that is not complete is refused (gst_by_ledger_window_partial). Ledger names are masked like vouchers masks them. Measured on one synthetic book of TallyPrime 7.2 Silver: fourteen vouchers typed on Tally's screen, read one day at a time and, by the build before Direct Expenses and Fixed Assets were admitted, as one month of 64 vouchers that the window read in two parts (purchases on Indirect Expenses, Direct Expenses and Fixed Assets ledgers and on two expense ledgers at once, two item invoices whose purchase ledger was among their entries, one with freight, journals with input IGST, with a TDS ledger typed Others, a set-off and a reversal with no supplier, a debit note, two tax payments, one also paying interest, and a credit note with output tax). A registered book was read once, by an earlier build: none of December's six vouchers was set aside, and a supplier invoice entered twice was totalled twice, so a duplicate is not detected. Not measured: vouchers created by import, Gold and other releases, a registered book on this build, other item-invoice shapes, more than 64 vouchers in a window. A year on a large book may be refused as too large by the window read: use shorter windows. 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

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).
company_guidYesThe company's company_guid, as list_companies returns it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.5

TDQS

A4.2/5.0
Behavior5/5

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

Beyond readOnlyHint, it discloses refusals for incomplete windows, size limits on large books, set-aside categories with causes, duplicate non-detection, cancellation/optional/post-dated handling, local metadata logging, and that it writes nothing to Tally. This is unusually rich behavioral context for a read-only tool.

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 purpose is front-loaded, but the description is a very long, dense, run-on narrative with exhaustive set-aside reasons, synthetic-book measurements, and limitations. Much of this is useful, but it is far from appropriately sized and key operational caveats are buried in the wall of text.

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, non-idempotent read tool with no output schema, the description covers output fields, attribution rules, set-aside reasons, refusal behavior, logging side effects, and measured limitations. An agent has enough information to invoke it and interpret its gaps.

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?

All three parameters have full schema descriptions, including date formats and company_guid sourcing, so the schema already carries parameter semantics. The description adds window-completeness and size-limit behavior but does not add syntax or meaning beyond the schema.

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 opening sentence states a specific verb, resource, scope, and exclusion: read-only GST recorded by the books, totalled per counter ledger for a date window, explicitly not a return figure. It distinguishes itself from return-prep and ITC tools and names sibling reads (purchase_register, sales_register, trial_balance) whose data shape it shares.

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?

It gives strong when-not guidance (not a return figure, does not decide ITC eligibility, blocked credit, availed amounts, input vs output, or return rows) and identifies related tools. It falls short of an explicit selection rule such as 'use this instead of purchase_register when you need per-counter-ledger GST attribution,' leaving the agent to infer that mapping.

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