Skip to main content
Glama
ComplyEaze

ComplyEaze Bridge: TallyPrime MCP server for Claude Desktop

Official
by ComplyEaze
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

trial_balance

Read-only

Generate a ledger-wise balance report for a date range using Tally TBAL fields without scanning vouchers; requires INR base currency and supports paginated, snapshot-consistent results.

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; 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. 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
toYes
fromYes
limitNo
offsetNo
snapshot_idNo
company_guidYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.1

TDQS

A4/5.0
Behavior5/5

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

Far exceeds the annotation baseline: it discloses currency-scoping behavior, that totals are not expected to balance, empty-amount preservation, snapshot caching mechanics with concrete staleness bounds, refusal codes, and metadata-only receipt logging with an explicit 'writes nothing to Tally'. This is unusually rich behavioral disclosure.

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?

Front-loads purpose well, but the body is a dense wall of parenthetical detail (field names, protocol section references, staleness anecdotes) that is hard to scan. Most sentences carry real behavior, but the volume works against quick selection.

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 compensates by naming the returned structures (ledgers_scope, foreign_currency_ledgers_excluded, base_currency_ledgers_mixed_excluded, totals_scope, snapshot). An agent has enough to interpret the response without opening anything else.

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 0%, so the description must carry the load, and it does for most: from/to as a date range, offset semantics (offset 0 vs offset > 0), snapshot_id pass-through, and 'pagination limits output only' for limit. company_guid is never explained, leaving one gap.

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?

Specific verb and resource: 'Return native ledger-wise Trial Balance for a date range, using Tally's TBAL fields without scanning vouchers.' The 'without scanning vouchers' clause implicitly separates it from voucher-reading siblings, but no sibling (balance_sheet, profit_and_loss) is named to make the choice explicit.

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

Usage Guidelines3/5

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

Prerequisites are stated (INR base currency, supported date boundaries) and the snapshot_id usage pattern is spelled out. However, when to choose this over sibling reports like balance_sheet or profit_and_loss is never addressed, leaving the core selection question to inference.

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

Deploy Server

Other Tools