ComplyEaze Bridge: TallyPrime MCP server for Claude Desktop

Official

Overview Schema Source Related Servers Discussions Admin

egress_log

Read-only

Displays metadata-only receipts of ComplyEaze Bridge tool calls—tool, time, company, counts, and fingerprints—to review which calls ran and when, without changing the local log or Tally data.

Instructions

Everything the assistant reads from Tally through ComplyEaze Bridge in this chat, amounts included, is sent to the AI provider; redaction can only shorten party and ledger names, bank account numbers and ledger address lines, or drop narrations, and does not hide amounts, company names, PAN, GSTIN, IFSC, MSME or Udyam registration numbers, contact details or references, or the last four digits of a bank statement's account number (account_last4); under mask_parties a name written inside a narration or reference stays as it is. Never tell the user that no data has left their computer. Shows the receipts ComplyEaze Bridge keeps of its own tool calls, read from its local log file on this computer: tool, time, company, counts and fingerprints, no figures or book content (bounded to the most recent receipts). It does not show what the AI provider received. Use it when the user asks what ComplyEaze Bridge has done, or to show a reviewer which calls ran, on which company and when. Reading the log changes nothing in it; this call's own receipt lines are added after the read, like every call's. 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": "egress_log"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	How many of the most recent receipt lines to return (each completed call writes two): default 20, at most 256 (or the configured row limit, BRIDGE_AGENT_MAX_ROWS, if lower, which can cap the default too), and fewer past a size bound; `omitted_for_size` counts those cut for the reply.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.4.5Oct 29, 2026

changedInput schema / properties / limit / description

Previous value: -"How many of the most recent receipt lines to return (each completed call writes two): default 20, at most 256 (or the configured row limit, BRIDGE_AGENT_MAX_ROWS, if lower, which can cap the default too), and fewer when the newest receipt lines do not fit in the log read's size bound."New value: +"How many of the most recent receipt lines to return (each completed call writes two): default 20, at most 256 (or the configured row limit, BRIDGE_AGENT_MAX_ROWS, if lower, which can cap the default too), and fewer past a size bound; `omitted_for_size` counts those cut for the reply."

Changed1 schema field changedv0.4.3Oct 16, 2026

addedInput schema / properties / limit / description

Added value: +"How many of the most recent receipt lines to return (each completed call writes two): default 20, at most 256 (or the configured row limit, BRIDGE_AGENT_MAX_ROWS, if lower, which can cap the default too), and fewer when the newest receipt lines do not fit in the log read's size bound."

First observedv0.4.1Oct 2, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Beyond the annotations, it discloses that reading changes nothing, that each call appends metadata-only receipt lines to a local log, what redaction can and cannot hide, and that nothing is written to Tally. The local-log append is a side effect not fully captured by readOnlyHint, but the description is unusually explicit about it.

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 a dense wall of text that opens with a long privacy/redaction warning before stating what the tool actually does. Important information is present but poorly front-loaded and difficult to scan, which undermines efficient tool selection.

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, the description still explains the return contents: tool, time, company, counts, and fingerprints, with no figures or book content, bounded to the most recent receipts. It also explains side effects and privacy limits, leaving only minor gaps about exact output shape.

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?

There is only one parameter, limit, and the input schema already documents it at 100% coverage including default, maximum, and omitted_for_size behavior. The description adds no parameter-specific guidance beyond what the schema provides, so the baseline 3 applies.

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 description clearly states that the tool shows ComplyEaze Bridge's own receipts of its tool calls, read from a local log, and explicitly says it does not show what the AI provider received. The purpose is specific, but it is buried after a long privacy preamble rather than front-loaded.

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?

It gives explicit usage triggers: when the user asks what ComplyEaze Bridge has done, or when showing a reviewer which calls ran, on which company, and when. It does not name sibling alternatives or state when-not to use it, but the context is clear.

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