Skip to main content
Glama
ComplyEaze

ComplyEaze Bridge: TallyPrime MCP server for Claude Desktop

Official

masters

Read-only

List one kind per call from a TallyPrime company: voucher types, godowns, units, stock groups, cost centres, cost categories, or account groups, with IDs, parents, and flags.

Instructions

List a company's masters of one kind: voucher types with the numbering value Tally reports at the type level (see below: it is not their numbering method), active and optional flags and series_numbering (the numbering method, under Automatic its sub-method, and the duplicate setting of the type's series), godowns, units (with decimal places and whether simple), stock groups, cost centres (with their category), cost categories (with three allocation flags), or account groups (groups). Each row of another kind carries name, guid, master_id, alter_id and parent (null where it does not apply or is absent; a parent that is Tally's reserved root is written as U+FFFD #4; Primary, as in the group tree); a groups row carries name, parent and reserved_name only. Voucher types also carry active, optional (true, false or null when Tally did not say) and numbering_method (automatic, manual, default, {"unrecognised": <raw text>} for any other value Tally reports, or null when absent) and series_numbering ({"observation":"observed","method":"automatic"|"manual"|"automatic_manual_override"|{"unrecognised": <raw text>},"duplicates":"prevented"|"not_prevented"}, with "sub_method":"auto_retain"|"auto_renumber"|"absent"|{"unrecognised": <raw text>} under automatic and under no other method, {"observation":"series_count","count":n} when a type has no series or several, and nothing is read from it, or {"observation":"field_invalid","code":...}), read from a second paired read of the voucher-type export and joined to each row by GUID with the name as a second equality, so a type on one side only, or a GUID and name that disagree between the two reads, refuses the whole read (masters_numbering_names_differ for a type in one read only, masters_numbering_identity_differs for a GUID and name that disagree), as do masters_numbering_collection_changed (the numbering read changed between its two reads) and masters_bound_premise_violated (the numbering answer's row count or size), and a moved book is reported as masters_extent_changed in place of a join or premise refusal; units carry decimal_places and simple; cost centres carry category (always present: a centre without one is refused), cost categories allocates_revenue, allocates_non_revenue and affects_stock; cost centres and categories are returned whether or not the company's Cost Centres setting is on (a book with the setting off was read with its centres, and a book with it on with its own), an empty cost-centre list does not say whether the feature is off or none is defined, and an empty cost-category list is refused (masters_cost_categories_empty, on the expectation that the predefined Primary Cost Category always exists), and ComplyEaze Bridge does not return how a voucher was allocated to a cost centre. One kind per call, read inside one company, mode and book-extent bracket: the extent before and after must be equal and each collection is read twice and compared, so a book that changed during the read is refused. Whole reads only. Godowns, units, stock groups, cost centres and cost categories are read only when the book's master-alteration mark times an assumed worst-case row for that kind fits 16 MB (the mark counts the masters of every kind, so a book with few of this kind can be refused), and otherwise refuse before any request with masters_too_large and size (master_alter_id, estimated_bytes, limit_bytes, limit_master_alter_id); that admits marks up to 1,152 for godowns, 1,168 for units, 1,160 for stock groups, 1,037 for cost centres and 1,264 for cost categories. Retrying refuses again. The refusal's size carries limit_master_alter_id, the largest mark this kind is read at. Both stock-heavy client books measured, with marks of about 100,000 and 300,000, refuse godowns, units and stock groups (cost centres and cost categories were not tried on them); how common such marks are across live books is unmeasured. voucher_types and groups have no size check before the read (voucher types keep the policy of ComplyEaze Bridge's other voucher-type read, and their second, numbering read is likewise sent with no size check). After a read of any kind other than groups, each row's length is checked against the assumed worst-case row (masters_row_exceeds_bound), and the row count, the rows' AlterIDs (at or under the mark, none repeated) and the response size (each collection is read twice, and the size check runs after both reads) are checked against the mark and the admitted size; a breach of those three refuses the whole read as masters_bound_premise_violated and returns no partial list, unless the closing extent shows the book moved, which is reported instead (masters_extent_changed). A response ComplyEaze Bridge cannot read refuses at once with a masters_* cause, and a voucher_types answer with no rows refuses as masters_voucher_types_empty, because every company has predefined voucher types. Not returned: alias names, counts and hints (no company NUM* fields), stock items, ledgers (use ledger_masters), and any write. The row shape was captured from one synthetic book on one licensed TallyPrime 7.1 (cost centres: three synthetic books, the third captured in a separate sitting whose own status read recorded TallyPrime 7.1, licence Silver, Education mode off; cost categories: two): the type-level numbering_method it carries is not the voucher type's numbering method: it read None for types a person had set to Automatic and to Manual on the screen, and the method is kept per number series, which series_numbering returns instead, so no value of numbering_method (default, automatic, manual or any other) says how a post is numbered. series_numbering was measured on one synthetic book (TallyPrime 7.1 Silver, Windows): 24 voucher types, each with one series named Default, of which three (Journal Automatic, Payment Manual with duplicates prevented, Receipt Manual with duplicates not prevented) were checked against Tally's screen; Automatic (Manual Override) through this tool (it is mapped from the series text measured on a synthetic book on 13 October 2026), more than one series, Multi-user Auto, a single series not named Default, a voucher type created new and other releases were not measured, an unrecognised method is never manual, and the integrated read, the two requests sent as one tool call, was run live on two synthetic books on 14 October 2026 and returned the numbering set or checked on Tally's screen for six types. sub_method is the series' own NUMBERINGSUBMETHOD (auto_retain is the screen's Retain Original Voucher No., auto_renumber its Renumber Vouchers, absent a series that printed none, and any other text, a blank one included, is returned raw under unrecognised); a Manual series printed Auto Retain too, which is not the numbering in force there, so it is not returned for one. It was measured on a second synthetic book (TallyPrime 7.1 Silver, Windows) and one voucher type, Receipt, set to Renumber Vouchers and back: with it on Renumber Vouchers, numbers already in the book changed, at the switch, when a voucher with an earlier date was entered by hand, and when one was sent by import without a number (the import's answer reported nothing altered and no voucher's AlterID moved); any other wording, a series that prints no sub-method, other voucher types, a batch of several vouchers, Gold, other releases and the same through ComplyEaze Bridge's own post are not measured. A value other than Automatic, Manual or Default is returned raw under unrecognised, not refused. default is Tally's reported value, not evidence that a type numbers automatically. The company's voucher-type count (NUMVOUCHERTYPES) did not equal the rows returned on two books (35 vs 26, 33 vs 24), and on one book equalled the number-series count (inferred to count series, unmeasured), so do not check these rows against it. The completeness of the voucher-type list is unverified: absence from it is not evidence that a voucher type is absent from the book. Under mask_parties, godown, stock-group, cost-centre and cost-category names, their parents and a cost centre's category are masked, because a job-work godown, a supplier-named stock group or a customer-named cost centre can carry a party's name (Tally's reserved root as a parent is left as it is). Voucher-type, unit and account-group names are not masked: they are configuration labels, not counterparties. Education mode is refused. A first page (offset 0) always captures a fresh read and holds it in memory; a later page for the same kind (offset > 0) is served from it while the company's book extent, including ALTVCHID and ALTMSTID, is unchanged, at the cost of one small extent read. Each result reports snapshot (id, master_alter_id, voucher_alter_id, read_at, reused). Pass the first page's snapshot_id on later pages to have the call refused with listing_snapshot_changed (cause book_changed_since_first_page or snapshot_not_held) instead of continuing from a different read. A change that moves neither mark is not seen, so a later page can be up to 10 minutes old after such a change. 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
kindYesWhich masters to list, one kind per call: voucher_types, godowns, units, stock_groups, cost_centres, cost_categories or groups (account groups).
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.
snapshot_idNoOptional, on a later page only: the first page's snapshot_id, so the call is refused (listing_snapshot_changed) rather than continuing from a different read.
company_guidYesThe company's company_guid, as list_companies returns it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 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 / kind / description
      Added value: +"Which masters to list, one kind per call: voucher_types, godowns, units, stock_groups, cost_centres, cost_categories or groups (account groups)."
    • changedInput schema / properties / kind / enum
      Previous value: -[
      -  "voucher_types",
      -  "godowns",
      -  "units",
      -  "stock_groups",
      -  "groups"
      -]New value: +[
      +  "voucher_types",
      +  "godowns",
      +  "units",
      +  "stock_groups",
      +  "cost_centres",
      +  "cost_categories",
      +  "groups"
      +]
    • 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 / snapshot_id / description
      Added value: +"Optional, on a later page only: the first page's snapshot_id, so the call is refused (listing_snapshot_changed) rather than continuing from a different read."
  2. 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 a safe read (readOnlyHint true, destructiveHint false, openWorldHint false), but the description adds extensive behavior beyond them: size pre-checks with kind-specific mark thresholds, the full set of masters_* refusal causes, snapshot reuse/expiry semantics, mask_parties behavior, and local logging. This is far more than the annotations convey.

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 in the first clause, but the body is a single enormous block mixing invocation-critical facts (refusals, masking, pagination) with measurement provenance, unmeasured-case disclaimers and synthetic-book history. Critical details like the snapshot contract are buried far down, and much of the text does not help an agent select or 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?

For a seven-kind listing tool with no output schema, the description carries the full burden and does: it documents per-kind row shapes, refusal conditions, masking rules, pagination and snapshot semantics, and the absence of writes. An agent has everything needed to call it correctly and interpret results.

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, but the description adds real meaning: how offset interacts with the in-memory first-page snapshot, when snapshot_id causes listing_snapshot_changed, and what each kind value returns. It stops short of exhaustively documenting limit behavior beyond the schema's default note.

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?

Opens with a specific verb and resource: 'List a company's masters of one kind', then enumerates the seven kinds by name. It also explicitly distinguishes itself from the closest sibling by stating ledgers are not returned and pointing to ledger_masters.

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

Usage Guidelines5/5

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

Gives explicit when-to-use rules ('One kind per call', 'Whole reads only', education mode refused), states what is not returned (aliases, counts, hints, stock items, ledgers, writes) and names the alternative for ledgers. It also explains the pagination/snapshot contract that governs how calls must be sequenced.

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