PNPC-MCP-Tally-Prime

update_credit_note

DestructiveIdempotent

Updates an existing TallyPrime credit note by date and voucher number, replacing item lines, party, and narration while preventing voucher-number collisions.

Instructions

Update an existing item-invoice Credit Note in TallyPrime, replacing its item lines, party, and narration. Same fields as create_credit_note, plus voucherNumber. Matched by date + voucher number — use get_ledger_vouchers or get_vouchers first to confirm it exists and is unique. Refuses if another voucher type shares the same number on that date (confirmed live: Tally's Alter lookup ignores voucher type and can silently corrupt the wrong one) — resolve the collision in Tally first if that happens.

Input Schema

Name	Required	Description
`date`	Yes	Existing credit note's date in DD-MM-YYYY format
`items`	Yes	One entry per returned line — replaces all existing lines.
`billName`	No	Bill reference to settle against, e.g. the original invoice's bill name. Defaults to 'Agst Ref' billType.
`billType`	No	Defaults to 'Agst Ref' — settling against the original invoice's bill, unlike create_sales_invoice's 'New Ref' default.
`buyerTrn`	No	The buyer's TRN on this credit note — same voucher-level field as create_credit_note's buyerTrn.
`buyerName`	No	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.
`narration`	No	Narration / description
`reference`	No	Free-text reference for this credit note.
`vatLedger`	No	Default VAT ledger for items without their own override.
`buyerState`	No	The buyer's Emirate/state on this credit note's Party Details.
`partyLedger`	Yes	Customer ledger name (the party being credited)
`voucherType`	No	Voucher type of the existing voucher, if it isn't the default 'Credit Note' (e.g. 'Tax Invoice'). Used to find it and to check no other voucher shares its number.
`buyerCountry`	No	The buyer's country on this credit note's Party Details.
`referenceDate`	No	Date for the reference above, in DD-MM-YYYY format.
`voucherNumber`	Yes	Exact voucher number of the credit note to update
`vatRatePercent`	No	Default VAT rate. Required if vatLedger is set.
`placeOfSupplyCountry`	No	UAE VAT Place of Supply Country for this credit note.
`placeOfSupplyEmirate`	No	UAE VAT Place of Supply Emirate for this credit note.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.14.1Nov 9, 2026

addedInput schema / 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"
+}

Changed2 schema fields changedv1.14.0Nov 6, 2026

addedInput schema / properties / items / items / properties / description

Added value: +{
+  "description": "Description lines shown under this stock line on the invoice, one array entry per line (e.g. a size, colour or service period). Optional.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / voucherType

Added value: +{
+  "description": "Voucher type of the existing voucher, if it isn't the default 'Credit Note' (e.g. 'Tax Invoice'). Used to find it and to check no other voucher shares its number.",
+  "type": "string"
+}

Addedv1.11.2Sep 4, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Goes well beyond the annotations by disclosing full-replacement semantics ('replaces all existing lines'), the composite key used for matching, and a live-confirmed failure mode where Tally's Alter lookup ignores voucher type and can corrupt the wrong voucher. Minor gap: it doesn't describe what a successful update returns or confirm mutation is atomic.

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 the matching key, then the guardrail — a sensible order with no filler. The parenthetical about Tally's Alter lookup is dense but earns its place as a rationale for the refusal behavior.

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

Completeness4/5

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

For an 18-parameter destructive mutation with no output schema, the description covers identification, replacement scope, prerequisites and an edge-case refusal, while annotations carry the destructive/idempotent profile. It is close to complete; only the post-update outcome and handling of omitted optional fields are unstated.

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: voucherNumber and date together form the lookup key, voucherType is used both to find the voucher and to detect number collisions, and items overwrites rather than appends. It doesn't explain how optional fields (billType, buyerState, placeOfSupply*) behave when omitted on an update.

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?

Names a specific verb and resource ('Update an existing item-invoice Credit Note in TallyPrime') and immediately delimits scope by saying it replaces item lines, party and narration. It explicitly differentiates from the closest sibling: 'Same fields as create_credit_note, plus voucherNumber.'

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?

States a prerequisite workflow with named alternatives ('use get_ledger_vouchers or get_vouchers first to confirm it exists and is unique'), plus the when-not condition (refuses if another voucher type shares the number on that date) and the remediation ('resolve the collision in Tally first'). Nothing about selection 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

update_credit_note

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools