This server enables interaction with TallyPrime accounting software via MCP tools.
Read financial data: Ledgers, groups, stock items, vouchers (day book and ledger-specific), profit & loss, balance sheet, trial balance, stock summary, bills receivable/payable, voucher types, cost centres, and company info.
Create master data & vouchers: Add ledgers, groups, stock items, and post vouchers (Payment, Receipt, Sales, Purchase, Journal, etc.) with debit/credit entries.
Update records: Modify stock items (group/unit) and update vouchers (replace entries/narration) by type, date, and voucher number.
Delete stock items: Remove stock items only if they have no transactions.
Ad-hoc analysis with SQL cache: Sync Tally data (last 365 days) into a local in-memory SQL database and run read-only SELECT queries for flexible reporting.
Remote & local access: Run as an HTTP server for remote MCP clients (with optional token) or use stdio with Claude Desktop.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Tally MCP Server Show me the profit & loss statement for this month"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that lets Claude read from and write to TallyPrime via its built-in XML/HTTP gateway.
Claude Desktop <--stdio--> ┐
├─ this MCP server <--HTTP/XML--> TallyPrime (localhost:9000)
Remote MCP client <--HTTP--> ┘Locally, Claude Desktop launches this server as a stdio process. Remotely, it can also run as an HTTP server. Either way, tool calls get translated into Tally's XML request format, sent to Tally's HTTP gateway, and returned as cleaned-up JSON. There's also an optional local SQL cache (PGLite) for ad-hoc queries beyond the fixed report tools.
Related MCP server: TallyMind MCP
Node.js 18+
TallyPrime installed, running, with a company open
Tally's HTTP gateway enabled:
F1 (Help) > Settings > Connectivity > Client/Server configuration and set
TallyPrime acts as to Both or Server, port 9000 (default).
npm install
npm run buildOption A — Extension (recommended): package as a .dxt and install
with one click. See docs/EXTENSION_PACKAGING.md.
Option B — manual config: edit your Claude Desktop config file:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Add:
{
"mcpServers": {
"tally": {
"command": "node",
"args": ["D:\\Projects\\Tally-MCP-Server\\dist\\index.js"],
"env": {
"TALLY_URL": "http://localhost:9000"
}
}
}
}Restart Claude Desktop. You should see a hammer/tools icon indicating the
tally server is connected.
17 tools total — read (ledgers, stock, groups, voucher types, cost centres,
day book, ledger vouchers, company info, P&L, balance sheet, trial balance,
stock summary, bills receivable/payable), write (create ledger, group,
stock item, voucher), and SQL cache (sync_to_sql, query_sql). Full
reference with args: docs/TOOLS.md.
Dates use DD-MM-YYYY format, matching Tally's convention.
TALLY_MCP_TOKEN=<secret> npm run start:httpdocs/ARCHITECTURE.md — request flow, file responsibilities
docs/TALLY_XML_GUIDE.md — how Tally's XML gateway works, gotchas
docs/TOOLS.md — full tool reference + how to add a new tool
docs/SQL_CACHE.md — the PGLite SQL cache, schema, examples
docs/HTTP_DEPLOYMENT.md — running as a remote HTTP server
docs/EXTENSION_PACKAGING.md — packaging as a .dxt Claude Desktop Extension
src/
tally.ts Tally HTTP client: sends XML, handles connection/timeout errors
clean.ts Normalizes Tally's raw XML->JSON into predictable JSON
templates.ts Renders the Nunjucks XML templates in templates/
db.ts PGLite SQL cache: sync_to_sql / query_sql
tools.ts MCP tool definitions + XML request builders
server.ts Shared MCP Server construction (used by both entry points)
index.ts stdio entry point (local Claude Desktop)
http-server.ts HTTP entry point (remote clients)
templates/
*.xml.njk Nunjucks templates for each Tally XML request shape
manifest.json Claude Desktop Extension (.dxt) manifestVariable | Default | Purpose |
|
| Tally's HTTP gateway address |
|
| Port for |
| (unset) | Bearer token required on the HTTP server's |
"Could not reach TallyPrime" — Tally isn't running, or the HTTP gateway isn't enabled on port 9000.
"Tally returned an empty response" — Tally is running but no company is open.
create_ledger / create_voucher fails with errors — check that the
parent group / ledger names exactly match what exists in Tally (names are
case-sensitive and must match exactly).
Editing or deleting existing vouchers/ledgers/masters
Inventory vouchers (Stock Journal, Manufacturing Journal, etc.)
GST-specific reports (GSTR-1, GSTR-3B)
Multi-company support (currently always targets whichever company is open)
Get all stock items from TallyPrime
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states 'Get all stock items' without mentioning potential side effects, constraints, or whether the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, perfectly concise with no extraneous information. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description is adequate but fails to specify what fields are returned or any limitations like pagination. Additional context would improve agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so description needs no parameter explanation. Baseline 4 for zero-parameter tools applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (get) and resource (stock items) from TallyPrime, effectively distinguishing it from sibling tool get_voucher_types which deals with a different entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool or when to prefer alternatives. It simply describes the function without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all voucher types configured in TallyPrime (e.g. Payment, Sales, Journal)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Straightforward read operation with no parameters; no annotations to contradict. Slightly limited by lacking detail on return format or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and front-loaded with clear action and context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and examples; lacks output schema to fully describe return format, but acceptable for a simple list retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline 4; description adds value by naming resource and examples, though no further meaning needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specifically states 'Get all voucher types configured in TallyPrime' with concrete examples (Payment, Sales, Journal), clearly distinguishing it from sibling tool 'get_stock_items'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for retrieving voucher types, but no explicit guidance on when to use versus alternatives or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.1get_stock_itemsget_voucher_typesScored across 2 tools
Both tools have clearly distinct purposes: one retrieves stock items, the other retrieves voucher types. No overlap between them.
Both tools follow a consistent 'get_noun' snake_case pattern, making the naming predictable.
Only 2 tools for a Tally integration is far too few. Typical Tally servers include many more operations (create, update, delete) for various entities.
Only read operations for two entities are provided. Missing all mutation operations and other essential entities like ledgers, journals, or invoices.
AI for Tally Prime and Tally ERP 9. Hosted MCP server to ask your accounts in any language.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Hosted Amazon Seller and Vendor MCP server for Claude, ChatGPT, Cursor, Codex, Gemini, Copilot.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
