Skip to main content
Glama
ComplyEaze Bridge: TallyPrime MCP server for Claude Desktop

ComplyEaze Bridge: TallyPrime MCP server for Claude Desktop

Official

trial_balance

Read-only

Returns ledger-wise Trial Balance for a date range from TallyPrime using native TBAL fields, limited to plain base-currency ledgers.

Instructions

Return native ledger-wise Trial Balance for a date range, using Tally's TBAL fields without scanning vouchers. Requires an INR base currency and supported date boundaries. A book with several Currency masters is read through the base Tally identifies: only its plain base-currency ledgers are returned, with ledgers_scope base_currency_ledgers_only, the ledgers kept in another currency named under foreign_currency_ledgers_excluded, and the base-currency ledgers whose balances Tally shows in another currency named under base_currency_ledgers_mixed_excluded; totals then cover those plain ledgers only (totals_scope) and are not expected to balance. Preserves empty amounts; a ledger whose closing is not its opening plus its debit and credit totals carries movements_differ_by (the exact difference, nothing corrected; seen on a Closing Stock ledger whose closing balance was keyed on Tally's screen, where Tally kept the opening as the closing and showed the change only in the debit total, so its closing is not necessarily the figure Tally's statements use), and the first line counts such ledgers; paired source stability is not voucher-level reconciliation. Pagination limits output only. A first page (offset 0) always captures a fresh report and holds it in memory; a later page for the same period (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 report. A change that moves neither mark is not seen. A voucher delete, a cancel, a save with no change and a master change made in Tally's own screens each moved a mark when measured (protocol reference section 11c.5, one run each), but a change that moves neither can leave a later page up to 10 minutes old. For one ledger's movement counted from the window's vouchers, with how many vouchers touched it, use ledger_movement instead. 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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "company_guid": "<company_guid>",
      "from": "<from>",
      "to": "<to>"
    },
    "name": "trial_balance"
  }
}

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).
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 / 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 / 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."
    • 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.5/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses that totals will not balance for multi-currency books, names the scope fields (ledgers_scope, totals_scope, foreign_currency_ledgers_excluded), explains the movements_differ_by anomaly and that nothing is corrected, and documents the snapshot reuse/refusal contract including staleness up to 10 minutes and the exact error cause values. It also discloses the local receipt-log side effect and confirms nothing is written to Tally.

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?

Purpose is front-loaded in the first sentence, but the body is one very long compound sentence with deeply nested parentheticals (the Closing Stock ledger anecdote, 'protocol reference section 11c.5, one run each', 'at the cost of one small extent read') that cost more parsing effort than they return. Some of that detail could be compressed or moved to a reference.

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?

With no output schema, the description carries the full burden and does so: it enumerates the returned scope fields, the snapshot object's members, the per-ledger movements_differ_by field, and the first-line count of such ledgers. For a complex read tool with multi-currency edge cases, an agent has what it needs to interpret the result.

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: offset 0 always produces a fresh report held in memory while offset > 0 is served from it, pagination limits output only, and snapshot_id triggers listing_snapshot_changed rather than silently switching reports. That is semantics the schema does not convey.

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?

States a specific verb and resource — 'Return native ledger-wise Trial Balance for a date range' — and names the mechanism ('Tally's TBAL fields without scanning vouchers'), which separates it from voucher-based siblings like vouchers and ledger_movement. An agent can identify it without opening the 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?

Gives prerequisites (INR base currency, supported date boundaries) and an explicit alternative: 'For one ledger's movement counted from the window's vouchers, with how many vouchers touched it, use ledger_movement instead.' It does not contrast against close siblings like balance_sheet, profit_and_loss, or statement_tie_out, so the routing guidance is clear but incomplete.

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