Skip to main content
Glama
lokesh-sparrow

PNPC-MCP-Tally-Prime

by lokesh-sparrow
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

create_ledger

Create new ledgers in TallyPrime or update existing ones by passing the old name, with support for parent group, contact details, credit limits, and opening balance.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
trnNoTax Registration Number (UAE VAT TRN) for this party ledger, e.g. '100326595400003'.
nameYesName of the new ledger, or the new name when renaming an existing one
emailNoContact email for this ledger.
phoneNoLandline phone number for this ledger.
stateNoState/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.
mobileNoMobile number for this ledger.
parentYesParent group, e.g. 'Sundry Debtors', 'Sundry Creditors', 'Bank Accounts'
addressNoMailing address, one line per array entry (e.g. ['Office 12, Port Saeed', 'Deira']).
countryNoCountry, 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.
oldNameNoExact 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.
pincodeNoPostal/PIN code (optional — omit for countries that don't use one).
websiteNoWebsite for this ledger.
creditLimitNoCredit limit amount for this party ledger. Setting this also enables 'override credit limit' so the limit actually takes effect.
extraFieldsNoEscape 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.
mailingNameNoMailing name for the address, if different from the ledger name.
openingBalanceNoOpening balance (optional, defaults to 0)
billCreditPeriodNoCredit period in days for bill-wise settlement.
maintainBillWiseNoEnable 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.
addressApplicableFromNoDate 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. Dates show when Glama detected each change.

  1. Changed7 schema fields changedv1.0.4
    • 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"
+}
  2. First observedv1.0.3

TDQS

A4/5.0
Behavior3/5

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

Annotations already communicate that this is a write operation, is not idempotent, and is not flagged destructive. The description adds the useful update/rename behavior, but does not disclose what happens in edge cases such as an oldName that does not exist or whether unspecified fields are overwritten on update. With annotations present, this is adequate but not rich.

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

Conciseness5/5

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

The description is a single, front-loaded sentence with no filler. It states the primary action first, then the secondary mode, and every word earns its place.

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?

Given the rich 100%-covered input schema and the explicit annotations, the description is mostly complete for selection and invocation. The main gap is the lack of any mention of return value or success/failure indication, especially since no output schema is provided. Still, the core behavior and mode selection are well covered.

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%, with detailed explanations for all 19 parameters including examples and caveats. The tool description itself adds little beyond pointing to oldName, so the schema carries the parameter-semantics burden and the baseline of 3 applies.

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?

The description uses a specific verb ('Create') and a concrete resource ('ledger (account) in TallyPrime'), and immediately clarifies the dual create/update capability with 'rename/update an existing one by passing oldName'. This clearly differentiates it from sibling tools like create_group and 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 Guidelines4/5

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

The description gives clear usage context: create a new ledger, or update/rename an existing one by supplying oldName. It does not explicitly name alternative tools or state when not to use it, but the primary usage scenario is unambiguous.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lokesh-sparrow/PNPC-MCP-Tally-Prime'

If you have feedback or need assistance with the MCP directory API, please join our Discord server