Skip to main content
Glama
ComplyEaze

ComplyEaze Bridge: TallyPrime MCP server for Claude Desktop

Official

ledger_masters

Read-only

Returns a company's ledger masters with opening balances and optional compliance details such as GSTIN, PAN, MSME, bank, contact, address, group ancestry, and GST duty head.

Instructions

Return a company's ledger masters with each one's opening balance as of the start of the books (opening_balance, opening_balance_as_of), on a freshly observed supported product and mode. fields=basic (the default) or fields=compliance, which adds paired party-master observations (GSTIN, PAN, MSME, bank, contact and address), each ledger's group ancestry and its gst_duty_head. GSTIN (compliance): party_gstin is the GSTIN in force on party_gstin_as_of, which is the optional as_of (YYYYMMDD or YYYY-MM-DD, such as 20260331 for a year end) or else this computer's date; as_of without fields=compliance is refused as ledger_masters_as_of_requires_compliance. It comes from the ledger's dated registration history, or from the flat GSTIN field only when that history is empty or was not returned; an empty flat field names no GSTIN. party_gstin_status names the source: in_force, flat_field, no_gstin_in_force (a history with no GSTIN on that date; party_gstin_registration_type says whether that entry is registered) or not_reported. history_unreadable fails closed: the history came back undated, misdated, malformed, repeated or contradictory, so party_gstin is null and the flat field is not used. party_gstin_flat is always the flat field as read, and gstin_sources_disagree is true when it names a GSTIN that the in-force history entry does not; both are reported, neither is chosen. For another date, such as a transaction's, pass it as as_of or read the dated entries in compliance.gst_registrations. Duty head (compliance): gst_duty_head is recognized (with head: cgst, igst, state_tax, sgst_utgst, ut_tax or cess, and raw, the spelling Tally returned), unrecognized (raw kept), not_tax_ledger, contradictory or absent. state_tax (raw State Tax) and sgst_utgst (raw SGST/UTGST) are two spellings Tally has returned for a state-side head and are kept as two heads: a consumer summing state tax must include both. Ancestry (compliance): chain (nearest group first, each hop's own name and reserved_name), complete (true only if the chain was resolved all the way to the reserved account root) and gap (null when complete, else why resolution stopped: no_parent, group_absent, group_name_repeated, reserved_name_missing, cycle or exhausted). An incomplete chain is never padded or guessed: chain is exactly what was resolved, so check complete before treating it as exhaustive. A reserved_name beginning with U+FFFD #4; is a Tally reserved value (Tally writes it as ); U+FFFD#4; Primary is the account root, distinct from a group a user named Primary. Group filter: group filters by group name. group_scope "immediate" (the default) matches only the ledger's own parent and does NOT include ledgers under sub-groups of group; "ancestry" matches any group in the resolved chain, the whole subtree (a ledger under Bank OD A/c matches Loans (Liability)), with either fields value, and a gap in a chain never counts as a match. Any group filter reads the group collection (with fields=basic, one added paired read), and the result carries group_filter: excluded_subgroup_ledgers (count of ledgers left out because they sit under a sub-group of group, always 0 under ancestry scope, with group_count and up to 20 of those names in groups) and unresolved_ancestry_ledgers (ledgers not returned whose chain stops before reaching group, so ComplyEaze Bridge cannot say whether they belong under it; counted over the whole book, so a gap anywhere is counted). Large books (compliance): when the master-alteration mark (an upper bound on the ledgers, since every master raises it) puts the estimated response over budget, the ledgers are counted first, then read whole or, if the count does not fit, in parts by parent group; every ledger counted must come back exactly once, or the whole call is refused. Above a mark of 22,857 the ledgers are counted by AlterID span, in slices of at most 4,000, one request each for GUIDs only. Above 400,000 the call is refused before any ledger read, with cause ledger_catalogue_too_large and size, so a company with fewer ledgers may be refused. Each refusal names its cause: parent_over_budget, parent_partition_too_many_parts, parent_complement_over_budget, ledger_without_parent, parent_name_unsupported (with unsupported_parent_ledgers), parent_partition_duplicate_ledger_identity, the parent_part_* coverage causes, parent_part_response_too_large, ledger_span_slice_over_bound, ledger_span_duplicate_identity, ledger_span_census_empty, ledger_span_slice_malformed, ledger_span_identity_mismatch, ledger_span_slice_response_too_large or ledger_count_catalogue_too_large. Retrying a size refusal refuses again, and fields=basic still reads the book. For ledger_count_differs (two counts, or a count and the ledgers read, disagree) or ledger_count_company_differs (Tally's own ledger count is higher than the census's), retry once while the book is quiet; ledger_count_company_invalid means that count's answer was damaged, and ledger_count_company_response_too_large that it was larger than the response limit: retry once, then use fields=basic. A counted read reports ledger_count_cross_check.status: matched, company_count_lower, or unavailable when Tally's answer carried no count, so the check did not run. Currencies (compliance): a book with several Currency masters is read through the base Tally identifies: its plain base-currency ledgers are returned with ledgers_scope base_currency_ledgers_only, and the ledgers kept in another currency (foreign_currency_ledgers_excluded) and the base-currency ledgers whose balances Tally shows in another currency (base_currency_ledgers_mixed_excluded) are named, never read. Paging: a first page (offset 0) always reads Tally afresh and holds the read; a later page is served from it while the book extent, including ALTMSTID and ALTVCHID, is unchanged, and each result reports snapshot. Pass the first page's snapshot_id on later pages to have the call refused as listing_snapshot_changed instead of continuing from a different read (cause book_changed_since_first_page, or snapshot_not_held for an id not held). With fields=compliance, repeat the first page's as_of on later pages: a snapshot serves only pages read as of the same date, so a later page without it (or across midnight) reads afresh, or is refused when it names the snapshot. A change that moves neither mark is not seen. Each screen action measured so far moved a mark (a regroup, an opening change, a ledger create or delete, a voucher delete, a cancel, a save with no change; protocol reference section 11c.5, one run each), but a change that moves neither can leave a later page up to 10 minutes old. 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
as_ofNo
groupNo
limitNo
fieldsNobasic
offsetNo
group_scopeNoimmediate
snapshot_idNo
company_guidYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare read-only/non-destructive, but the description goes far beyond them: it enumerates every refusal cause, the count-then-read strategy for large books, the 400,000 mark refusal, currency handling, snapshot staleness ('up to 10 minutes old'), and states explicitly that it writes nothing to Tally and only appends metadata-only receipt lines locally. Nothing here contradicts the annotations.

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

Conciseness3/5

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

The purpose is front-loaded in sentence one, which is good, but the body is a very long, densely nested wall of text mixing paging, counting, currency, GST and refusal semantics. Much of it is genuinely informative, yet the sheer size makes it hard to scan and pushes it past what a tool description should reasonably hold.

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 tool with 8 parameters, no output schema and 0% schema coverage, the description is remarkably complete: it documents the response fields, refusal causes, snapshot semantics and scope flags an agent would otherwise have to discover by trial. An agent could call this correctly without further documentation.

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?

Schema description coverage is 0%, so the description carries the full burden and does so richly: `as_of` format and date semantics, `fields` basic/compliance differences, `group` filtering, the full immediate-vs-ancestry meaning of `group_scope`, `offset` first-page behavior, and `snapshot_id` propagation. Only `limit` and `company_guid` are left unaddressed, which is a minor omission against an otherwise exhaustive treatment.

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 gives a specific verb and resource ('Return a company's ledger masters') plus the exact scope (each ledger's opening balance as of the start of the books) and names the concrete output fields. Combined with the name `ledger_masters`, an agent can tell this apart from `masters`, `validate_masters` and `ledger_movement` without opening a schema.

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 clear operational context: when to pass `as_of` (e.g. a transaction's date) versus reading `compliance.gst_registrations`, when `as_of` is refused, when to reuse `snapshot_id`, and retry guidance for count mismatches. It never explicitly compares itself to sibling tools like `masters` or `validate_masters`, so it stops short of the top band.

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