Skip to main content
Glama
ComplyEaze

ComplyEaze Bridge: TallyPrime MCP server for Claude Desktop

Official

profit_and_loss

Read-only

Return a P&L for a TallyPrime date range, derived from Trial Balance movements and checked against Tally's own Balance Sheet.

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

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).
company_guidYesThe company's company_guid, as list_companies returns it.

Schema Changelog

Changes observed during successful MCP inspections.

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

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

Annotations only cover the read-only/idempotency profile, and the description adds substantial context beyond that: it appends metadata-only receipt lines to a local log (explaining the idempotentHint=false), refuses on multi-currency masters, unclassified ledgers, Stock-in-Hand amounts, and Balance Sheet mismatches, and enumerates each `reason`. It discloses what gets written where ('writes nothing to Tally') and the exact gating logic.

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?

The purpose and derivation are correctly front-loaded, but the description is a very long wall of text that buries key facts. Sentences such as how far the gate has been measured ('one full year on one book and one month on another') add length without helping an agent invoke the tool correctly.

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 return-value burden and does so thoroughly: it documents `lines`, `gross_result`, `net_result`, `state`, `tie_out`, `unclassified`/`unclassified_total`, `balance_sheet_gate` and the `reason` enum. For a tool this complex it leaves an agent well equipped to interpret the response.

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 description coverage is 100%, so the three parameters (company_guid, from, to) are fully documented by the schema itself; the baseline is 3. The description adds little per-parameter syntax, and its mention of 'mode and book-extent bracket' refers to concepts not exposed as parameters, which does not enrich parameter semantics.

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 Profit and Loss for a date range'), then pins down exactly what each output line is (one line per reserved P&L primary group derived from the Trial Balance) and how gross/net are computed. This clearly separates it from siblings like balance_sheet, trial_balance and cash_flow, which an agent can distinguish without opening any schema.

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 — you call it to get a derived P&L — and the description notes it reads/refuses rather than pointing to alternatives ('a book with stock items is expected to refuse'). It never says when to prefer trial_balance, balance_sheet or statement_tie_out, nor when to avoid this tool, so the when-to-use guidance is only inferable.

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