Skip to main content
Glama
ComplyEaze

ComplyEaze Bridge: TallyPrime MCP server for Claude Desktop

Official

negative_ledgers

Read-only

Return Tally's own Negative Ledgers list with each ledger's side and amount for a financial-year window; empty or unchecked answers are flagged, not treated as proof.

Instructions

Return Tally's own Negative Ledgers list for a window: the ledgers on Tally's Negative Ledgers list, each with its side (debit or credit) and its amount. The list is Tally's own and is returned as it is: the rule by which Tally lists a ledger is not established and is not derived here (on three books each listed ledger's balance sat on the side opposite its group; on the first, a ledger under Suspense A/c with a credit balance was not listed), and it is not compared with the trial balance or any other report, so a ledger Tally did not list is not shown to be absent and a listed amount is not shown to equal the ledger's closing balance elsewhere (the result's checks say not_checked). Each ledger name is masked under mask_parties. An empty list is returned as empty with state not_established: Tally's empty answer cannot be told from a report that was not rendered, so it does not say that no ledger is negative (negative_ledgers_empty_answer_is_not_a_finding). side is the side of the closing balance Tally carried the ledger on. from and to are the window of Tally's screen; only a whole financial year (1 April to 31 March) on one synthetic company was measured, and any other window is named in unmeasured_in_this_answer. The window must not start before the book (negative_ledgers_before_books); Education mode is refused (negative_ledgers_education_unqualified); an answer that is not exactly one signed amount per listed ledger, or that names a ledger twice, is refused (the call fails as negative_ledgers_read_failed and error.cause is negative_ledgers_balance_unexpected or negative_ledgers_ledger_repeated). The report's cost on a large book is not known and the report is one paired read (two requests), never retried: ask for one financial year first, and if a call times out do not repeat it. 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 window (YYYYMMDD or YYYY-MM-DD), on or after from. Only a whole financial year was measured: how Tally dates the closing balance of a part-year window was not.
fromYesThe first day of the window (YYYYMMDD or YYYY-MM-DD). Only a whole financial year, 1 April to 31 March, was measured: ask for that first.
company_guidYesThe company's company_guid, as list_companies returns it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.5

TDQS

A4.3/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: read-only with respect to Tally, local metadata-only receipt logging, paired-read/no-retry behavior, refusal conditions, and explicit error causes. No contradiction with readOnlyHint=true, destructiveHint=false, or openWorldHint=false.

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 is front-loaded, but the description is extremely dense, with long parenthetical examples and many nested caveats. Much of the content is useful, yet the structure could be tightened without losing essential guidance.

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?

Given the complexity, absent output schema, and risky interpretation surface, the description is complete: it explains the return shape, empty-list state, error behavior, masking, window limits, and read cost characteristics.

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 100%, so the schema already documents all three parameters. The description reinforces that from/to define the window and that only a whole financial year was measured, but it adds little parameter-level meaning beyond the schema descriptions.

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 Tally's own Negative Ledgers list for a window, with side and amount. It explicitly distinguishes this from trial balance and other reports, so the agent can tell what the tool is and is not.

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 clear usage constraints: ask for one financial year first, do not repeat a timed-out call, and avoid windows before the book. It also says the result is not compared with trial balance or other reports, though it does not explicitly route to a named sibling tool.

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