ComplyEaze Bridge: TallyPrime MCP server for Claude Desktop

Official

Overview Schema Source Related Servers Discussions Admin

local_data_report

Read-only

Reports locally stored data by class, with counts, sizes, oldest file age, and import journal state: sent, posted, unsettled, and never-dispatched batches.

Instructions

Reports what ComplyEaze Bridge stores locally, by class, with counts, sizes, the age of the oldest file and the state of its import journal: how many batches were sent or found posted, how many of those are not settled (not_settled_binding_refused: native posts whose binding to their own vouchers was refused, including one Tally rejected in part or whole; they stay not settled, their vouchers may or may not be in the book, and the person checks them in Tally; not_settled_reviewed_not_attributed: those, or posts with no answer recorded, a person recorded checking (acknowledge_post_review content_only), still not settled; the not_settled_ counts do not overlap), and how many have no recorded dispatch and were never verified as posted (no_dispatch_never_verified: it can include a batch imported by hand, which may be in Tally, so it never proves a batch absent). Reads its own data folder and the per-user folder of dispatch lease locks (names, sizes, times), and names no file path. A folder, link or journal it could not read or enter is reported as such (incomplete_reason and folders_that_could_not_be_listed, and this call's evidence is partial), never as empty or absent. It covers the folder the MCP server and desktop Journal flow share, not the app's other settings, mirror database or logs. The import journal, the skipped-rows file agent-import-statement-skips.jsonl and the imports folder are its memory of what it sent to Tally and of the statement rows it was told to skip: never suggest deleting them. 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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "local_data_report"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.1Oct 2, 2026

TDQS

A3.8/5.0

Behavior5/5

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

Goes far beyond the annotations: it discloses that no file path is named, that unreadable folders surface as incomplete_reason rather than as empty, that each call appends metadata-only receipt lines to a local log, and that it writes nothing to Tally. The per-batch journal taxonomy (not_settled_*, no_dispatch_never_verified, and the warning that no_dispatch never proves a batch absent) is exactly the kind of non-obvious behavior an agent would otherwise get wrong. The receipt-writing notice sits in mild tension with readOnlyHint=true, but it is disclosed rather than hidden, so this is not a contradiction.

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 single correct front-loaded sentence is followed by a roughly 300-word run-on whose middle clause nests three journal-state definitions inside parentheses inside a sentence about counts. The genuinely important operational warnings (never delete the journal/skips files, partial evidence on read failure, log append) are buried mid-paragraph rather than surfaced. The content earns its place; the packaging does not.

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?

With no output schema and zero parameters, the description carries the whole burden and mostly does: it describes the report's fields (classes, counts, sizes, oldest age, journal state, incomplete_reason) and the failure mode. Only the response format/ordering is unstated, which is minor for a diagnostic report.

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?

The tool takes no parameters, so the baseline is 4 and there is nothing for the description to compensate for. The note that it 'names no file path' usefully preempts an agent trying to pass a path.

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?

The opening sentence names a specific verb and resource ('Reports what ComplyEaze Bridge stores locally') and enumerates the report contents: counts, sizes, oldest file age, journal state. A scope exclusion is added ('not the app's other settings, mirror database or logs'), which separates it from diagnostic siblings like egress_log or tally_status without naming them. Clear, but an agent still has to infer the boundary against the other 28 tools.

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?

The description implies a diagnostic purpose (what is stored, whether the import journal is settled) and gives one prohibition ('never suggest deleting them'), but never states when to call this versus verify_import, read_evidence or egress_log. Usage is left to inference from the scope sentence rather than stated outright.

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