Skip to main content
Glama
Sign In
MarketingBNG

tally-mcp

by MarketingBNG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

tally_create_voucher

Create a new TallyPrime voucher for journals, payments, receipts, sales, purchases, or notes via ledger lines or item invoices, then preview before confirming.

Instructions

Post a NEW voucher in TallyPrime: Journal, Payment, Receipt, Contra, Sales, Purchase, Credit Note, Debit Note, Delivery Note, Receipt Note or any custom type.

Two forms: ACCOUNTING (ledger lines only) or ITEM INVOICE (give items: stock item, quantity, rate and the sales/purchase ledger, plus the party and any tax ledgers as entries). Any ledger line or item line can be split across cost centres. For stock transfers or production use tally_create_stock_journal.

WHEN TO USE: audit adjustments, provisions, reclassifications, recording a payment, receipt, sale or purchase.

Each line is a ledger, a side (Dr/Cr) and a positive amount. Debits must equal credits exactly. Party lines can carry bill-wise allocations (New Ref for an invoice, Agst Ref to settle one). GST/TDS are posted as ordinary ledger lines to the tax ledgers, with the amounts you give: nothing calculates tax for you.

REFUSES: an unbalanced voucher, an unknown ledger or voucher type, a date before the books begin. The preview warns about likely duplicates already in the books.

WRITES TO TALLYPRIME, in two steps. This call only PREVIEWS: it checks the change against the live books and returns exactly what would be written plus a confirmToken — nothing is changed. Show the preview to the user, and only after they approve it call tally_confirm_write with the token. Never confirm on your own initiative, and never confirm a preview the user has not seen.

Input Schema

NameRequiredDescriptionDefault
dateYesVoucher date, ISO YYYY-MM-DD.
itemsNoStock item lines, for an ITEM invoice (Sales, Purchase, Credit/Debit Note) or a Delivery / Receipt Note. Each is item, quantity, rate and the sales or purchase ledger it posts to; the side follows the voucher type (a sale credits, a purchase debits).
companyNoCompany name. Omit to use whichever company TallyPrime has loaded. If given and it is not the loaded one, the call fails with TALLY_COMPANY_NOT_LOADED rather than returning another company's data.
entriesYesLedger lines. Debits must equal credits exactly, counting any item lines. On an item invoice these are the party and any tax, freight or discount ledgers.
narrationNo
referenceNoSupplier invoice number or other reference.
partyLedgerNoThe party (customer/supplier) of the voucher, if any.
voucherTypeYesVoucher type as in TallyPrime: Journal, Payment, Receipt, Contra, Sales, Purchase, Credit Note, Debit Note, or a custom type.
voucherNumberNoOnly for types numbered manually. Omit to let TallyPrime number it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.2.0

TDQS

A4.8/5.0
Behavior5/5

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

Discloses behavior well beyond the annotations: explicit REFUSES conditions (unbalanced voucher, unknown ledger/voucher type, pre-opening date), a duplicate warning in the preview, the exactly-balanced debit/credit requirement, that no tax is calculated for you, and the preview/confirmToken workflow. This is consistent with readOnlyHint=false and destructiveHint=false (this call only previews) and adds substantial operational context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is long but organized and front-loaded: purpose first, then the two forms, then WHEN TO USE, REFUSES, and the write/confirm flow. Almost every sentence carries operational content, though a few (e.g. the bill-wise and tax-ledger restatements) edge toward what the schema already says.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema, the description covers the gaps: it explains that the return is a preview containing exactly what would be written plus a confirmToken, and directs the follow-up call to tally_confirm_write. Combined with the refusal and balance rules, an agent has everything needed to invoke it safely.

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?

Schema coverage is already 89%, so the baseline is 3, but the description adds real meaning: it explains the ACCOUNTING vs ITEM-INVOICE forms, that item lines supply line and party/tax ledgers via `entries`, that amounts are positive with side conveyed by Dr/Cr, and that cost centres can split any line. These are semantic relationships the schema states only in fragments.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Post a NEW voucher in TallyPrime') and enumerates the supported voucher types. It explicitly distinguishes the two authoring modes (accounting vs item invoice) and routes stock transfers/production to the sibling tally_create_stock_journal, so an agent can tell it apart from other create/alter tools without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'WHEN TO USE' lists concrete scenarios (audit adjustments, provisions, reclassifications, payments, receipts, sales, purchases) and names the alternative tool for stock transfers/production. It also specifies the two-step preview-then-confirm flow and the rule never to confirm an unseen preview, which is exactly the guidance an agent needs.

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

Deploy Server

Other Tools