Skip to main content
Glama
ComplyEaze

ComplyEaze Bridge: TallyPrime MCP server for Claude Desktop

Official

profit_and_loss

Read-only

Generates a Profit and Loss statement for a date range from TallyPrime, derived from the Trial Balance and validated against Tally's own Balance Sheet for accuracy.

Instructions

Return the Profit and Loss for a date range, derived from Tally's native Trial Balance: one line per reserved P&L primary group (Sales Accounts, Direct Incomes, Purchase Accounts, Direct Expenses, Indirect Incomes, Indirect Expenses), each the window's signed debit plus credit movement (a debit negative), with gross_result and net_result (a profit positive). The top-level lines is null while net_result 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 both gross_result and net_result are established, and not_established otherwise with the same reason the nested result carries (the weaker result decides). 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. Tally's own Profit and Loss is read too and compared by display name in tie_out (matched, matched_empty_as_zero, differs or not_compared). Gross and net are also refused as tally_profit_and_loss_differs unless it ties: no line differs, no derived line is missing from it, and no line of its with an amount is uncompared, except its Cost of Sales : heading while that equals the derived Purchase Accounts plus Direct Expenses exactly (observed once, on one book). A stock line refuses. 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/5.0
Behavior5/5

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

Far exceeds the annotation baseline of readOnlyHint/destructiveHint. It discloses currency preconditions (multi-currency books refused), stock refusal, the full gate/`state`/`reason` taxonomy, the exception for the `Cost of Sales :` heading, measurement coverage limits, and that it writes metadata-only receipts locally while writing nothing 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.

Conciseness2/5

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

The purpose is front-loaded, but the remainder is a dense multi-hundred-word run-on packing refusal reasons, gate details, and edge cases into single sprawling sentences. Much of this belongs in structured fields (e.g., an output schema or error enum) rather than prose, hurting scanability.

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 thoroughly: it documents line shape, gross_result/net_result, state, reason values, unclassified handling, tie_out outcomes, and failure modes. An agent can anticipate nearly every return condition.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and none of the three parameters (company_guid, from, to) are named or documented in the description. It adds contextual constraints (single company/mode/book-extent, INR-only, supported date boundaries, multi-year windows unmeasured), but the caller still gets no per-parameter meaning, format, or example from the description.

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 (Return), resource (Profit and Loss), and scope (date range), then immediately clarifies the derivation source (Tally's native Trial Balance) and the exact line structure. This distinguishes it cleanly from siblings like trial_balance and balance_sheet.

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 the derivation chain and refusal conditions, but the description never explicitly says when to choose this tool over balance_sheet or trial_balance, nor what a caller should do on `not_established`. The conditions for a successful read are detailed, yet the routing guidance is left to inference.

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