Skip to main content
Glama
ComplyEaze

ComplyEaze Bridge: TallyPrime MCP server for Claude Desktop

Official

balance_sheet

Read-only

Derive a validated balance sheet for a date range from Tally's Trial Balance, returning primary group closing balances and Profit & Loss result.

Instructions

Return the Balance Sheet for a date range, derived from Tally's native Trial Balance: one line per reserved Balance Sheet primary group (Capital Account, Loans (Liability), Current Liabilities, Suspense A/c, Branch / Divisions, Fixed Assets, Investments, Current Assets, Misc. Expenses (ASSET)), each the signed closing balance at to (a debit negative), and result.profit_and_loss: the Profit & Loss A/c ledger's closing and the carried result (that closing plus every P&L ledger's closing; in a part-year window the year's earlier result sits in that ledger). The top-level lines is null while carried is not established, so a derived line is never shown as the statement. Reads the Trial Balance, the group tree and Tally's own Balance Sheet inside one company, mode and book-extent bracket; requires observed INR currency (a book with more than one currency master is refused) and supported date boundaries. Each line reports amount (sum, present_count, empty_count): the sum is over the amounts Tally returned, and the empty ones it left out are counted. A result is established only if every ledger is classified (a ledger under a user-created primary group, or whose group chain is incomplete, is listed in unclassified, up to 100, with unclassified_total), no Stock-in-Hand ledger carries an amount, and Tally's own Balance Sheet for the window ties line for line to the derived one (balance_sheet_gate). Otherwise it is not_established with a reason (unclassified_ledger_carries_an_amount, closing_stock_not_derivable_from_trial_balance, profit_and_loss_ledger_not_returned, tally_balance_sheet_differs, or for gross and net tally_profit_and_loss_differs); for the two differs reasons, lines names the lines that did not tie. The top-level state is observed only while carried is established, and not_established otherwise with the same reason the nested result carries. A book with stock items is expected to refuse; no inventory book has been measured. A Tally line with an amount the derivation has no counterpart for, such as a heading or a difference in opening balances, refuses rather than being guessed at. Tally's own statements carry no company identity and are bound only by the checks around the read. The gate has been measured over one full year on one book and one month on another; a window spanning more than one financial year is unmeasured. 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
company_guidYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.1

TDQS

A4.1/5.0
Behavior5/5

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

Annotations declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds substantial context beyond annotations: it explains the gate mechanism (balance_sheet_gate), refusal reasons, the unclassified ledger limit, stock item behavior, logging of receipt lines, and that nothing is written to Tally. This is exemplary transparency far beyond the structured fields.

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 description is extremely dense and long, essentially a specification document embedded in the tool description. While information-rich, it is not front-loaded or concise; it reads as a single sprawling paragraph covering derivation, states, gates, and logging, making it hard for an agent to quickly extract the essential call information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of the tool and no output schema, the description is largely complete: it explains return structure (lines, amount with sum/present_count/empty_count, result.profit_and_loss, state), refusal conditions, and data sources. It is thorough, though its density and lack of structure slightly reduce usability.

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 compensate. It explains the semantics of `to` as the closing-balance date and `from`/`to` as a date range window, and explains that company_guid bounds the read to one company. While the schema provides patterns and types, the description adds conceptual meaning (date boundaries, currency constraints) that the schema lacks.

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 the Balance Sheet'), names the data source (Tally's native Trial Balance), and enumerates the exact primary groups returned. This clearly distinguishes it from siblings like trial_balance and profit_and_loss, which it references by name.

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?

Usage is implied through preconditions (observed INR currency, single company/mode book, supported date boundaries) and references to sibling concepts (Trial Balance, P&L A/c), but there is no explicit when-to-use-this-vs-alternatives guidance. The description explains the derivation rather than choosing between tools.

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