How to build an MCP server for TallyPrime
Short answer
An MCP server for TallyPrime is a small program that turns the HTTP XML/JSON interface (and optionally ODBC) into a handful of typed tools such as outstanding bills, ledger vouchers and stock position. Start read-only, add your own authentication and logging, and any MCP client, including Claude and ChatGPT, can use it.
Model Context Protocol gives AI clients a standard way to call tools. For Tally that means you write the server once and let several assistants use it, instead of building a custom integration for each. The work is mostly about Tally specifics rather than MCP itself.
Those specifics matter: Tally answers one request at a time, depends on a loaded company, returns verbose XML, and has no concept of a user. A good server hides all of that behind tools with small, predictable outputs.
What follows is a design checklist: tools to expose, how to talk to Tally, where to run it and how to keep it safe.
What teams use it for
Party outstanding lookup
A tool takes a party name and optional date and returns open bills with ageing, so any MCP client can answer who owes what.
Voucher search
Search vouchers by type, party, amount range or narration text with a row cap, returning voucher number, date and amounts.
Stock position
Return closing quantity and value for an item and godown, supporting questions during sales or purchase conversations.
Bill of materials read
For manufacturers using Tally's manufacturing journal setup, expose component lists and standard quantities for planning questions.
Draft voucher creation
A guarded tool that validates a payload against masters and stores it as a draft file; a separate human step imports it.
TallyPrime integration surface
- Tally HTTP endpoint: POST an XML envelope with HEADER, BODY and static variables to the configured port; newer releases also support JSON. Verify against your release.
- Collections and reports: request standard reports such as Outstandings or Stock Summary, or define a custom collection in TDL for compact output.
- Import path: TALLYMESSAGE payloads containing VOUCHER, LEDGER or STOCKITEM objects with ACTION attributes; responses report created, altered and error counts.
- ODBC: read-only tabular access that some teams prefer for search style tools; table and field coverage depends on release.
- Company context: the SVCURRENTCOMPANY static variable selects the company, and the server should require it on every call.
How it works
- 1
Pick the SDK and transport
Use an official MCP SDK in TypeScript or Python. Stdio suits a single user on the Tally machine; Streamable HTTP suits a shared LAN server.
- 2
Write the Tally client
One class that builds envelopes, sends requests with timeouts and parses responses. Serialize calls since Tally handles requests sequentially.
- 3
Define tools with strict schemas
Name, description and typed parameters for each tool, with company required and sensible row limits. Return JSON, not raw XML.
- 4
Add authentication and scoping
Issue API tokens per user or per client, map tokens to allowed tools and companies, and refuse everything else.
- 5
Handle failure modes
Return clear errors for closed company, port unreachable, malformed XML and timeouts so the model can explain them.
- 6
Log and monitor
Record caller, tool, arguments and response size. Alert on spikes that suggest a loop or a misbehaving client.
Example flows
Tool call for open bills
Trigger: Client calls get_outstanding with company and party.
- Server validates token and that the party exists in the cached ledger list.
- It builds a report request and sends it to Tally.
- It parses bills into JSON, sorted by due date, capped at a row limit.
Result: The client receives compact, citable data.
Guarded draft voucher
Trigger: Assistant proposes a receipt entry.
- Server checks ledger names, amount sign and date range against rules.
- It writes the import XML to a drafts store, not to Tally.
- A web page shows the draft; an accountant approves.
- The server imports it and returns the voucher reference.
Result: Writes are possible without bypassing review.
Keeping data on-prem
The server naturally lives on the same network as Tally, and nothing in MCP requires the cloud. Run it on the Tally machine for a one-user setup or on a small LAN server that can reach the Tally port. Pair it with an on-prem open-weight model and an MCP-capable client so that prompts, tool results and logs stay inside the building. If remote staff need access, publish it through a VPN rather than opening the Tally port.
Security checklist
- Treat the Tally port as unauthenticated; only the MCP server host should reach it.
- Per-token tool allowlists and per-company scoping, since Tally itself will not enforce them.
- Never concatenate model-provided text into XML without escaping; validate names against known masters.
- Keep immutable logs of each call, and review write drafts regularly.
Ways to get it done
Community or marketplace Tally MCP servers
Effort: Hours, with security review.
Quick experiments; review code and data handling first.
Build in-house
Effort: Two to four weeks for a read-only set.
Teams who need exact control over tools and logging.
Netray-built server with approvals
Effort: Pilot in a few weeks.
Firms wanting write drafts, scoping and audit out of the box.
Pitfalls
- !Exposing a generic run_xml tool lets a model issue any request, including destructive imports.
- !Large tool results exhaust client context; summarise and paginate.
- !Tally requests can block while a user has a dialog open; build timeouts and retries.
- !Caching ledger lists without invalidation produces stale validations after master changes.
- !Different Tally releases return differently shaped XML; add tests per version you support.
Frequently asked questions
Which tools should the first version expose?
Read-only ones: list companies, find party, outstanding bills, ledger vouchers, stock position. They cover most questions and carry no risk to the books. Add draft-only write tools after you trust the read behaviour.
Stdio or HTTP transport?
Stdio is simplest when a single person uses a client on the Tally machine. HTTP is better for shared use, central logging and token-based access, and should sit behind your network controls.
Does MCP work with ChatGPT as well as Claude?
MCP is an open protocol supported by several clients, with support evolving over time. Check which transports and features your chosen client supports before committing.
How do I handle multiple companies?
Require the company name on every tool call, validate it against a list from Tally, and scope tokens to specific companies. Never rely on the currently open company by default.
Can the server write to Tally safely?
Only with validation and human approval. Imports change the books, so keep writes as drafts and log who approved each one.
Want MCP server working on your TallyPrime?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment