PNPC-MCP-Tally-Prime

create_ledger

Create a new TallyPrime ledger or rename and update an existing one by passing oldName, setting parent group, GST/PAN, contact, and opening balance details.

Instructions

Create a new ledger (account) in TallyPrime, or rename/update an existing one by passing oldName

Input Schema

TableJSON Schema

Name	Required	Description
`pan`	No	India PAN (Permanent Account Number) for this party ledger, e.g. 'BOUPA8950A'.
`trn`	No	Tax Registration Number (UAE VAT TRN) for this party ledger, e.g. '100326595400003'.
`name`	Yes	Name of the new ledger, or the new name when renaming an existing one
`email`	No	Contact email for this ledger.
`gstin`	No	India GSTIN (GST Identification Number) for this party ledger, e.g. '33BOUPA8950A1Z1'. This is India's equivalent of the UAE trn field, not an alias for it — set whichever applies to the company's country.
`phone`	No	Landline phone number for this ledger.
`state`	No	State/Emirate, e.g. 'Dubai'. Plain free text — Tally does not validate this against a master list, so match this company's existing convention (check get_company_info or an existing ledger) rather than a formal name.
`mobile`	No	Mobile number for this ledger.
`parent`	Yes	Parent group, e.g. 'Sundry Debtors', 'Sundry Creditors', 'Bank Accounts'
`address`	No	Mailing address, one line per array entry (e.g. ['Office 12, Port Saeed', 'Deira']).
`country`	No	Country, e.g. 'UAE'. Plain free text — Tally does not validate or normalize this (e.g. 'United Arab Emirates' is stored literally, not converted to 'UAE'), so match this company's existing convention (check get_company_info or an existing ledger) instead of guessing a formal name.
`oldName`	No	Exact name of an existing ledger to alter/rename (optional). If provided, updates that ledger instead of creating a new one — pass the same value as 'name' to update parent/opening balance without renaming.
`pincode`	No	Postal/PIN code (optional — omit for countries that don't use one).
`website`	No	Website for this ledger.
`creditLimit`	No	Credit limit amount for this party ledger. Setting this also enables 'override credit limit' so the limit actually takes effect.
`extraFields`	No	Escape hatch for any other native Tally ledger field not covered above — pass exact Tally XML tag names as keys (e.g. {'LEDGERCONTACT': 'Ahmed'}). Not validated; use exact Tally field names from a master export.
`mailingName`	No	Mailing name for the address, if different from the ledger name.
`contactPerson`	No	Contact person's name for this ledger — distinct from the ledger/party name itself.
`vatDealerType`	No	UAE VAT dealer type for this party ledger, e.g. 'Regular', 'Unregistered'. This is UAE's equivalent of India's gstRegistrationType, not an alias for it — set whichever applies to the company's country.
`openingBalance`	No	Opening balance (optional, defaults to 0)
`gstTypeOfSupply`	No	India GST type of supply for this ledger — 'Goods' or 'Services'. Confirmed live as a real, independently settable field.
`billCreditPeriod`	No	Credit period in days for bill-wise settlement.
`maintainBillWise`	No	Enable bill-wise tracking on this ledger (required for create_voucher's Agst Ref / New Ref bill allocation to work). Almost always wanted for Sundry Debtors/Creditors party ledgers. Defaults to false/off.
`gstRegistrationType`	No	India GST registration type for this party, e.g. 'Regular', 'Composition', 'Unregistered', 'Consumer'. Plain text matching Tally's own options — check an existing ledger or Tally's own dropdown if unsure of this company's exact wording.
`addressApplicableFrom`	No	Date in DD-MM-YYYY format from which this address is effective. Required by Tally for the address to actually persist (it's a date-versioned list internally) — defaults to today if any address field is set and this is omitted.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv1.12.0Sep 11, 2026

addedInput schema / properties / contactPerson

Added value: +{
+  "description": "Contact person's name for this ledger — distinct from the ledger/party name itself.",
+  "type": "string"
+}

addedInput schema / properties / gstRegistrationType

Added value: +{
+  "description": "India GST registration type for this party, e.g. 'Regular', 'Composition', 'Unregistered', 'Consumer'. Plain text matching Tally's own options — check an existing ledger or Tally's own dropdown if unsure of this company's exact wording.",
+  "type": "string"
+}

addedInput schema / properties / gstTypeOfSupply

Added value: +{
+  "description": "India GST type of supply for this ledger — 'Goods' or 'Services'. Confirmed live as a real, independently settable field.",
+  "type": "string"
+}

addedInput schema / properties / gstin

Added value: +{
+  "description": "India GSTIN (GST Identification Number) for this party ledger, e.g. '33BOUPA8950A1Z1'. This is India's equivalent of the UAE trn field, not an alias for it — set whichever applies to the company's country.",
+  "type": "string"
+}

addedInput schema / properties / pan

Added value: +{
+  "description": "India PAN (Permanent Account Number) for this party ledger, e.g. 'BOUPA8950A'.",
+  "type": "string"
+}

addedInput schema / properties / vatDealerType

Added value: +{
+  "description": "UAE VAT dealer type for this party ledger, e.g. 'Regular', 'Unregistered'. This is UAE's equivalent of India's gstRegistrationType, not an alias for it — set whichever applies to the company's country.",
+  "type": "string"
+}

Changed7 schema fields changedv1.0.4Aug 19, 2026

addedInput schema / properties / address

Added value: +{
+  "description": "Mailing address, one line per array entry (e.g. ['Office 12, Port Saeed', 'Deira']).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / addressApplicableFrom

Added value: +{
+  "description": "Date in DD-MM-YYYY format from which this address is effective. Required by Tally for the address to actually persist (it's a date-versioned list internally) — defaults to today if any address field is set and this is omitted.",
+  "type": "string"
+}

addedInput schema / properties / country

Added value: +{
+  "description": "Country, e.g. 'UAE'. Plain free text — Tally does not validate or normalize this (e.g. 'United Arab Emirates' is stored literally, not converted to 'UAE'), so match this company's existing convention (check get_company_info or an existing ledger) instead of guessing a formal name.",
+  "type": "string"
+}

changedInput schema / properties / extraFields / description

Previous value: -"Escape hatch for any other native Tally ledger field not covered above — pass exact Tally XML tag names as keys (e.g. {'LEDGERCONTACT': 'Ahmed'}). Not validated; use exact Tally field names from a master export. Address/State/Country/Pincode are known NOT to take effect via this or any plain tag in this Tally version — confirmed by live testing, not yet resolved."New value: +"Escape hatch for any other native Tally ledger field not covered above — pass exact Tally XML tag names as keys (e.g. {'LEDGERCONTACT': 'Ahmed'}). Not validated; use exact Tally field names from a master export."

addedInput schema / properties / mailingName

Added value: +{
+  "description": "Mailing name for the address, if different from the ledger name.",
+  "type": "string"
+}

addedInput schema / properties / pincode

Added value: +{
+  "description": "Postal/PIN code (optional — omit for countries that don't use one).",
+  "type": "string"
+}

addedInput schema / properties / state

Added value: +{
+  "description": "State/Emirate, e.g. 'Dubai'. Plain free text — Tally does not validate this against a master list, so match this company's existing convention (check get_company_info or an existing ledger) rather than a formal name.",
+  "type": "string"
+}

First observedv1.0.3Aug 19, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare this a non-readOnly, non-idempotent write with openWorldHint=false. The description adds the meaningful behavior that passing oldName mutates an existing ledger rather than creating one, which the annotations do not convey. However, it omits error/duplicate-name behavior and the re-run implications of idempotentHint=false, so it adds only moderate value on top of the annotations.

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?

A single front-loaded sentence that states the primary create behavior first and the update mode second, with no wasted words. It is arguably thin given the tool's complexity, but nothing should be cut.

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

Completeness3/5

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

For a 25-parameter mutation with nested objects and no output schema, the description is minimal, though the rich schema carries most parameter burden. Missing are the surrounding workflow context (verify/set the company, read existing ledgers) and any note on what the call returns or how failures surface.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the schema documents all 25 parameters in detail, so the baseline is 3. The description only restates the oldName semantics already captured in the schema, adding no new parameter meaning.

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

Purpose4/5

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

The description names a specific verb and resource ('Create a new ledger (account) in TallyPrime') and adds the non-obvious dual-mode behavior ('or rename/update an existing one by passing oldName'). It is clear what the tool does, but it never distinguishes itself from related siblings such as create_group, create_voucher, or get_ledgers.

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

Usage Guidelines2/5

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

It hints at one usage path ('by passing oldName') but gives no when-to-use vs. when-not guidance, no reference to the read/delete siblings (get_ledgers, delete_master), and no prerequisite such as setting the active company. An agent must infer almost all routing decisions.

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

Deploy Server

create_ledger

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools