ComplyEaze Bridge MCP 0.4.1

In plain words: ComplyEaze Bridge 0.4.1, since 0.4.0 (2 Oct 2026)

These changes are in ComplyEaze Bridge 0.4.1. Each line names the pull
requests it comes from, except where it names an issue.

What you can do now

• No new tool. On a company large enough to be counted first,
  voucher_presence can now answer absent for a voucher it finds nowhere in
  a date range that holds vouchers and was checked against that count. An empty
  range is called absent only on a company that has never held a voucher, as
  before (#985, #1020).

Safer or fixed

• parse_bank_statement accepts a statement file or password file path only
  when its text names a local disk. A path that starts with two separators
  (two slashes, two backslashes or one of each), such as the Windows long-path
  form (starting with \\?\) or a network share (\\computer\folder), is
  now refused: copy the file to this computer and give its path there (#1024).
• vouchers and voucher_presence now call a date range with vouchers in it
  complete by one rule: only when every voucher read was checked against a
  separate count of that range. Before, vouchers called any such range
  complete (unless it withheld a voucher), and voucher_presence called none
  complete. On a small or new company, which ComplyEaze Bridge does not count
  first, both now say partial (#985, #1020).
• A voucher changed in Tally between the count and the read now refuses the
  read (voucher_window_part_not_admitted, cause part_census_mismatch),
  also when the range is read in one request, where it used to return without
  that check. Call again once while the book is quiet; if it repeats, read the
  range in Tally. ledger_movement, purchase_register, build_import_xml,
  verifying an import and the party detail of outstandings can give the same
  refusal. After a post was sent, this refusal on the read-back means the
  voucher may already be in Tally: use verify_import on the same batch and
  never post it again. In some cases, verifying an import for one day that
  Tally cannot serve in one request is now read in parts instead of refused,
  which sends more requests to Tally (#985, #1020).
• When post_import refuses a batch before it is sent because some of its
  rows may already be in the book (import_preexisting_identity), the answer
  now names those rows by their transaction ids and says what to check in Tally
  next, instead of returning a bare code, unless the response size limit
  leaves no room for the list. The same batches are refused as before (#901,
  #908).
• vouchers returns a voucher's master_id (Tally's internal voucher id) as
  the plain number ("1"), not as Tally sends it with a leading space
  (" 1"), so it matches the same id returned by verify_import (#989, #1021).
• If voucher posting is turned on, you approve a batch in its approval dialog,
  and the post is then refused before it is sent (for example because the
  import journal is busy, the batch is not found, or the call names a
  different company from the batch's), your approval is withdrawn, and the next
  post that gets past those checks asks you again. Before, in these cases the
  approval stayed held for up to 15 minutes, and posting any other batch was
  refused until it was used or lapsed (#857, #904).

Known limits

• A date range is called complete when the vouchers read match a separate
  count of the range. If Tally's own date selection leaves a voucher out, the
  count and the read both miss it, and the range is still called complete. A
  small or new company is not counted, so it cannot get absent; adding a
  count for it is tracked in #1029, with the multi-day and after-post cases
  (#985).
• parse_bank_statement checks the text of the path. A mapped drive letter
  still passes, and so, on a Mac, does a path under a mounted network volume
  (#1024).
• A batch refused just before it is sent can still return no rows and no next
  step. The rows named before that can be more than the vouchers the book
  holds, when several rows look the same; count the vouchers in Tally before
  leaving any row out. A row is still refused when a voucher that an earlier
  batch or a hand entry put in the book has the same date, type, ledgers,
  amounts and sides (#865, #901).
• Tried against TallyPrime 7.1 Silver in a lab on 2 October 2026, before
  #1020 merged: one-day ranges on two synthetic books, and the read-back of one
  posted Journal. Not tried: a range of several days read in one request, the
  new refusal itself (seen only in tests), how often it appears on a busy book
  with several users, and other Tally editions. The other changes have not been
  run against TallyPrime; each is covered by automated tests. No one on our
  side installed the Windows package of this build in Claude Desktop on a
  Windows PC. The release check starts each package, lists its tools and reads
  a sample bank statement, and does not run against TallyPrime.

---

ComplyEaze Bridge is still being developed, and this release is not yet
code-signed or notarized, so your computer may warn you before opening it.
Compare each download with its .sha256 file.

It includes an unsigned third-party PDFium shared library
(bblanchon/pdfium-binaries, pinned by SHA-256 in
packaging/pdfium/pdfium.lock.json) beside the server binary. The asset
checksums and payload-free smoke evidence identify the exact archive and
source commit.

Build attestation: each archive has a GitHub build attestation. To check that a
file you downloaded is the one this repository's release workflow built, run
gh attestation verify <file>.mcpb --repo ComplyEaze/bridge --signer-workflow ComplyEaze/bridge/.github/workflows/release-mcpb-preview.yml --source-ref refs/heads/master --deny-self-hosted-runners (the GitHub CLI needs to be logged
in). It shows which workflow run and commit built the file. It is not a code
signature and does not show the code is safe.

What the release check covers: the workflow builds and smoke-tests the
packaged stdio server on hosted Windows x64 and Apple Silicon Mac runners. That
proves the archive launches, exposes its local tool catalog, and parses a
synthetic encrypted bank statement with the bundled PDFium; it does not
establish live Tally behaviour or Claude Desktop conversational tool calls on
either host. What has and has not been run against a real TallyPrime is listed
in the README. Native Windows Tally/Claude Desktop validation remains
outstanding, and Intel Mac is not qualified.

---

What's Changed

New and changed

• Name the rows a post is refused for when they are already in the book (#901, part 1) by @lamemustafa in #908

Fixes

• Download and home pages: accept the Terms of Use, then quit and reopen Claude Desktop by @lamemustafa in #1014
• Withdraw a clicked approval when a post is refused before its checks (#857) by @lamemustafa in #904
• Return a voucher's master_id as the plain number text, not Tally's padded form (#989) by @akshit-khandelwal47 in #1021
• Admit a statement or password file path only when its text names a local disk by @lamemustafa in #1024
• Label a voucher window complete by one rule: admitted against its census (#985) by @akshit-khandelwal47 in #1020
• bridge-tax-audit: a repeated figure id is a typed refusal, not a panic (#644) by @lamemustafa in #826

Maintenance

• Name 0.4.0 as the published release in the README, the security policy and the tool guide by @lamemustafa in #1015
• Record what a Company collection fetch returns for a company's details by @lamemustafa in #1011
• Security and privacy page: describe release 0.4.0 by @lamemustafa in #1016
• Correct the security policy's supported versions and release facts by @lamemustafa in #1023
• Cache the Playwright browsers and bound the install with a timeout and retries by @lamemustafa in #1022
• Set the version to 0.4.1 and draft its changelog section by @lamemustafa in #1030
• Record how long Claude Desktop waited on one tool call (reference §11f) by @lamemustafa in #1035
• Skip the heavy jobs on a master push the merge queue already ran green by @lamemustafa in #1007
• Record the live runs of a window read whole against its census (#985) by @akshit-khandelwal47 in #1025

Full Changelog: mcp-v0.4.0...mcp-v0.4.1

ComplyEaze Bridge MCP 0.4.0

Superseded by 0.4.1. This build is in the range of a published security advisory, GHSA-vm5g-r3p7-wxx7: the bank statement tool opened file paths that name a network location (Windows). Install 0.4.1 or later.

---

In plain words: ComplyEaze Bridge 0.4.0, since mcp-preview-0.3.0 (26 Sep 2026)

These changes are in ComplyEaze Bridge 0.4.0. Each line names the pull
requests it comes from, except where it names an issue.

What you can do now

• Read a company's masters as a list: voucher types (with their numbering
  method), godowns, units, stock groups, or ledger groups, in pages. The book is
  checked before and after the read. For godowns, units and stock groups, a book
  with very many masters is refused, with the size named, rather than answered
  in part (#952).
• See what a party's unallocated amount is made of, from data the tool already
  reads, and what that data cannot tell apart. Each bill now carries its own
  date and credit period, and payable and receivable follow the sign of the
  bill's balance (#945, #946, #957, #959, #961).
• See what ComplyEaze Bridge keeps on this computer. local_data_report (and
  bridge_mcp --local-data-report on the command line) counts files, bytes and
  the age of the oldest file by kind, and gives the state of the import journal
  and how many saved batches are not settled. It changes no book and deletes
  nothing; like every call, it records its own receipt line in the local log. It
  names no file path unless you ask on the command line (#925).
• Read the purchase register of tax in the books: the Purchase and Debit Note
  vouchers of a date window that touch a ledger under Duties & Taxes, with the
  tax amount each entry records under the ledger's GST duty head. Other voucher
  types that touch those ledgers (Sales, Journal, Payment) are listed apart with
  exact counts (at most 100 are listed), and an entry whose ledger has no recognised GST head is listed and
  never given one. Nothing is posted and nothing is inferred: whether an entry
  belongs in a return is for you to decide (#971).
• Ask outstandings for one party, with detail, to see why a bill is open and
  what an unallocated amount holds, party by party. A bill trail lists the
  allocations of each of the party's bills, oldest first, leaving out those in
  cancelled and optional vouchers, and says whether they
  add up to Tally's own balance for the bill. The unadjusted view lists the
  party's on-account, advance and pending credit or debit note allocations and
  compares the on-account total with its unallocated amount; a note is
  recognised only when its voucher type is named exactly Credit Note or Debit
  Note. A bill that does
  not tie, or whose identity is ambiguous, is shown as such and nothing is
  merged. The detail reads the company's vouchers from the start of the books,
  so a large book can be refused, with a next step (#981).
• Read Profit and Loss and Balance Sheet. A figure is shown only when it ties
  line for line to Tally's own statement. Otherwise ComplyEaze Bridge's own
  statement is withheld; Tally's own amount for each line is still returned,
  with the derived amount on each line that differs, and the lines that differ
  are named. A book with stock items is expected to be
  refused, because no such book has been measured, and the tie-out itself has
  been measured on two synthetic books only (#774).
• Read closing stock values per item. An item is returned only when the values
  add up to Tally's own Stock Summary and ComplyEaze Bridge read exactly as many
  items as Tally's own count; otherwise no item is returned, with the reason and
  the next step. A company with no stock items is told so. A value keeps
  Tally's sign, as in the Trial Balance: stock held is a negative number.
  Quantities are not returned, because nothing checks them, and names, parents
  and units are returned but not checked. Only a 31 March and small books are
  read (#980, #979, #1001).
• Read books that define more than one currency. Outstandings set aside
  foreign-currency ledgers, and a rupee ledger with a foreign-currency
  balance, and name them. Compliance ledgers and the Trial Balance are read
  through the book's base currency. The vouchers tool withholds a voucher
  whose amount Tally stored in a foreign currency instead of refusing the
  whole date window. The desktop app follows the same read (#642, #647, #649, #715,
  #781, #824, #825).
• Read a book too large for one read, in parts, including ledgers under parents
  that cannot be named, and have the ledger count cross-checked against the
  company's own count. A movement read names an oversized ledger catalogue and
  refuses an unknown ledger before it reads any voucher (#679, #885, #891, #936,
  #938, #939, #960).
• Recognise SGST/UTGST as a GST duty head (#968).
• The app and the extension carry the ComplyEaze Bridge tick logo as their icon
  (#950, #978).
• A ledger read on a several-currency book, or one whose base currency is not
  INR, is refused before any request to Tally, instead of returning bare
  numbers (#751).
• A recognised bank-statement cash line is now asked its purpose. An
  unanswered line blocks the import file; "don't know" posts to a suspense
  ledger, tagged and listed. Other unmapped cash lines still go to suspense,
  tagged and counted (#817).

Safer or fixed

• profit_and_loss and balance_sheet no longer open with "state": "observed"
  when nothing was established. The top-level state is observed only when
  the tool's result is established; otherwise it is not_established, with
  the same reason as the nested result. This changes the tool's output; no
  figure, check or withheld line changes (#984).
• Every tool is refused until the Terms of Use are accepted, and the extension
  carries a privacy policy (#943).
• The party-master balance snapshot ends at today's date, not at a stray voucher
  date (#896).
• The Markdown proof shows the verification status and any duplicate vouchers in
  the batch (#811).
• ComplyEaze Bridge sends one request to Tally at a time, across all its
  running processes (#883).
• Each send to Tally is recorded in the local log with its place, kind, size,
  outcome and time, and no book content (#918, #941).
• ComplyEaze Bridge refuses to build or post a row that another batch already
  sent to Tally (#876, #898).
• A bank statement's result returns no amount except the figures you supplied
  and an open cash line's amount, and names the saved proposals file by its id
  alone (#848, #850).
• The configured redaction also applies to ledger names in posting and
  verification results (#851).
• The native posting windows say ComplyEaze Bridge (#970).
• Each package's build is attested, and the attestation is checked before it is
  published (#923).
• If you are slow at the approval window, the agent's call no longer waits
  on it. The agent is told the approval is pending and asks again. A click
  made while no call is waiting is posted by the next call, not one call later
  (#792, #854).
• The approval window for a batch names how many vouchers it covers, in its
  title and its button. The review window shows a debit the way the post
  window does (#757, #762).
• A voucher you cancel in Tally after ComplyEaze Bridge posted it reads back
  as posted but not effective, not as changed. Cancelled vouchers are no
  longer reported as duplicates of each other (#771, #789).
• A recorded review can no longer answer for a different doubt than the one it
  covers (#755, #769, #809, #813, #831).
• Tally's own error text on a rejected line is read safely, including text
  with an & in it (#763).
• Each tool now says whether it changes anything. Reads are marked read-only
  and say they only record local receipt lines for the call, never book
  content. Some assistants may now run the read tools without asking each
  time (#909, #921).
• The tools that save a file on this computer are marked as writes: preparing
  an import file and reading a bank statement add new files, while
  verification and acknowledgement replace the batch's saved proof and are
  marked destructive. Posting stays marked destructive, and no tool is marked
  as reaching outside this computer. parse_bank_statement had been marked
  read-only by mistake (#909, #921).

Known limits

• Stock: the closing-value total is checked against Tally's own Stock Summary on
  one synthetic book, and the item count against the rows on one synthetic
  company, and the sign of a value was measured on one synthetic company. A
  book with many stock items is refused: the read is for small books, and
  typical stock-heavy books refuse today. A book in which no item carries a value
  returns nothing. A book with
  stock items is expected to be refused by Profit and Loss and Balance Sheet,
  because no such book has been measured (#774, #980, #1001).
• A book with very many masters is refused by masters for godowns, units and
  stock groups, and how common that is across real books has not been measured
  (#952).
• local_data_report has not been run on a Windows host, and how it reports a
  Windows junction is unverified. It does not cover the desktop app's other
  settings, its database or its logs (#925).
• The purchase register has been read from a disposable synthetic book only. A
  purchase typed on screen, item invoices whose purchase ledger sits in an
  inventory allocation, and books with several currencies are not covered, and
  it does not decide whether a Debit Note is a purchase return or a debit note to
  a customer (#971).
• The party detail of outstandings has been measured on one synthetic book.
  Its cost on a large book is not measured, and a window that needs too many
  requests is refused (#981).

Also in source

• The tax-au...

Bridge MCPB unsigned preview: mcp-preview-0.3.0

Superseded by 0.4.1. This build is in the range of a published security advisory, GHSA-vm5g-r3p7-wxx7: the bank statement tool opened file paths that name a network location (Windows). Install 0.4.1 or later.

---

This is an unsigned Bridge MCPB preview for evaluation only.

It is not a production release, is not code-signed or notarized, and must not
be presented as one. It includes an unsigned third-party PDFium shared library
(bblanchon/pdfium-binaries, pinned by SHA-256 in
packaging/pdfium/pdfium.lock.json) beside the server binary. The asset checksums and payload-free smoke evidence
identify the exact archive and source commit.

Validation scope: the preview workflow builds and smoke-tests the packaged
stdio server on hosted Windows x64 and Apple Silicon Mac runners. That proves
the archive launches, exposes its local tool catalog, and parses a synthetic
encrypted bank statement with the bundled PDFium; it does not establish
live Tally behaviour or Claude Desktop conversational tool calls on either
host. Native Windows Tally/Claude Desktop validation remains outstanding, and
Intel Mac is not qualified.

Separately from this package check: on 22 September 2026, on development builds before this release, against licensed TallyPrime Silver 7.1 and a synthetic company, one Journal (issue #579) and a Payment, a Contra and two Receipts (PR #600, approval dialog on macOS) were posted and read back as posted. Those builds accepted an approval before it was bound to a one-time token (#665). This package has not yet been run by us in a controlled test against a live Tally.

Bridge MCPB unsigned preview: mcp-preview-0.2.0

This is an unsigned Bridge MCPB preview for evaluation only.

It is not a production release, is not code-signed or notarized, and must not
be presented as one. The asset checksums and payload-free smoke evidence
identify the exact archive and source commit.

Validation scope: the preview workflow builds and smoke-tests the packaged
stdio server on hosted Windows x64 and Apple Silicon Mac runners. That proves
the archive launches and exposes its local tool catalog; it does not establish
live Tally behaviour or Claude Desktop conversational tool calls on either
host. Native Windows Tally/Claude Desktop validation remains outstanding, and
Intel Mac is not qualified.

Bridge v0.1.0

Bridge v0.1.0 is the first public open-source release.

Highlights:

• React, Rust, and Tauri desktop application foundation.
• Tally, GST, DSC, document, sync, and local database workflows.
• Hardened HTTPS endpoints, bounded responses, credential handling, DSC PIN transport, and PKCS#11 discovery.
• Repository-local Windows and macOS application icons and working Windows MSI/NSIS packaging.
• Required frontend, Rust format, GitGuardian, Windows, and macOS checks on protected main.

Supported development and release hosts: Windows and macOS. See README.md for prerequisites and validation commands.