Skip to main content
Glama
PNPC-MCP-Tally-Prime

PNPC-MCP-Tally-Prime

create_vouchers_batch

Post many vouchers in one call, split into verified chunks, and confirm which ones actually posted—so bulk Tally entries can be retried without creating duplicates.

Instructions

Post many vouchers (Journal, Payment, Receipt, etc. — same shape as create_voucher, one entry per voucher) in one call, for bulk work where posting one at a time is impractical (e.g. hundreds of balance-confirmation adjustment journals). Internally splits into chunks (default 10, max 50 — Tally's own gateway has a 10-second timeout per request, and a bigger single import risks silently exceeding it) and, after each chunk posts, runs ONE bulk query to confirm exactly which vouchers in that chunk actually exist in Tally now — this always runs, even if the post itself errored or timed out, because a client-side timeout does not mean Tally didn't still create some or all of them server-side; retrying without checking first risks posting duplicates. Verification matches each voucher back by (voucherType, narration) — NOT voucherNumber, confirmed live to be unreliable even when set explicitly (Tally silently reassigned its own auto-series number instead for a Journal voucher); reference was tried next and also came back empty on read. narration is what's confirmed live to persist exactly as sent, so it's REQUIRED and must be non-empty on every voucher, and must be unique per voucherType across the whole batch — two vouchers sharing the same (voucherType, narration) can't be told apart afterward and are rejected up front as invalid rather than silently mismatched (e.g. embed each row's own reference/id in the narration text). The result names exactly which vouchers were confirmed and which were not, per chunk, so a partial failure can be retried by resending only the ones that didn't land — never blindly resend the whole batch. Does not go through preview_write/confirm_write given the scale involved; sending a small batch (2-3 vouchers) first to confirm shape/ledger names before a large run is recommended.

Input Schema

NameRequiredDescriptionDefault
vouchersYesOne entry per voucher, same fields as create_voucher — narration is required here and must be unique per voucherType across the batch (see the tool description).
chunkSizeNoVouchers per internal request. Defaults to 10. Keep at or below 50 — Tally's gateway has a 10-second timeout per request and larger imports take proportionally longer server-side.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.14.1
    • addedInput schema / properties / vouchers / items / properties / buyerName
      Added value: +{
      +  "description": "Name to print in this voucher's Buyer (Bill to) box, when it should differ from the customer ledger's own name — Tally's per-voucher Party Details mailing name. The ledger itself is not changed. Useful when many sales are posted against one shared ledger (e.g. cash or card sales) but each invoice needs its own readable buyer name.",
      +  "type": "string"
      +}
  2. Changed2 schema fields changedv1.14.0
    • addedInput schema / properties / vouchers / items / properties / mode
      Added value: +{
      +  "description": "Tally's voucher entry mode (the 'Change Voucher Mode' choice in the voucher screen). 'Accounting Invoice' posts it as an invoice with plain ledger lines, the way invoice-mode Tax Invoices are entered — partyLedger is then required. 'As Voucher' posts the normal Dr/Cr voucher view and records that mode. Omit to post the normal voucher view without stamping a mode (right for Payment, Receipt, Contra). For Item Invoice (stock lines) use create_sales_invoice and its siblings instead.",
      +  "enum": [
      +    "As Voucher",
      +    "Accounting Invoice"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / vouchers / items / properties / partyLedger
      Added value: +{
      +  "description": "The customer or supplier ledger the invoice is raised on — required with mode 'Accounting Invoice', and must be one of this voucher's own ledger lines (it's placed first and marked as the party, as Tally does).",
      +  "type": "string"
      +}
  3. Changed3 schema fields changedv1.13.1
    • addedInput schema / properties / vouchers / items / properties / creditDescription
      Added value: +{
      +  "description": "Same as debitDescription, for the credit leg.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / vouchers / items / properties / debitDescription
      Added value: +{
      +  "description": "Additional description lines for the debit leg (Tally's 'Additional Descriptions for Ledgers'), one array entry per line. Optional.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / vouchers / items / properties / entries / items / properties / description
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  4. Addedv1.13.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only state readOnly=false, idempotentHint=false and destructiveHint=false; the description adds far more — internal chunking with the 10s Tally gateway timeout, mandatory post-chunk verification that runs even on client-side error/timeout, and the duplicate-posting hazard that makes retries unsafe. Missing only the exact shape of the returned per-chunk confirmation list. No contradiction with idempotentHint=false, which it in fact reinforces.

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?

Front-loaded with purpose, then mechanics, then error/retry policy — a sensible order. It is dense and heavily parenthetical, and the narration-uniqueness rule is repeated in the tool description, the vouchers param description and the narration field description, though that redundancy is defensible for a silent-duplicate hazard.

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 destructive-risk bulk mutation with no output schema, the description covers what an agent most needs: chunking limits, that verification always runs, that partial failures must be retried by resending only the unconfirmed vouchers, and that the result enumerates confirmed vs unconfirmed per chunk. Complexity is high and the description meets it.

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 100% so baseline is 3, but the description adds real meaning the schema does not: narration must be unique per voucherType across the whole batch and is the verification key, voucherNumber is deliberately not used for matching, and chunkSize is capped at 50 for a stated timeout reason. The uniqueness constraint is the decisive extra.

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?

Opens with a specific verb+resource+sibling reference: 'Post many vouchers ... one entry per voucher ... same shape as create_voucher', which instantly separates it from create_voucher (single) and create_sales_invoice (item invoices). The scope (bulk, hundreds of items) is stated before any mechanics.

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?

Explicitly says when to use it ('bulk work where posting one at a time is impractical, e.g. hundreds of balance-confirmation adjustment journals'), routes item-invoice work to create_sales_invoice, explains why it bypasses preview_write/confirm_write, and recommends a 2-3 voucher shakeout batch first. Nothing is left to inference.

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