Skip to main content
Glama
lokesh-sparrow

PNPC-MCP-Tally-Prime

by lokesh-sparrow
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

get_ledgers

Read-only

Retrieve TallyPrime ledger accounts to find exact names before creating vouchers or new ledgers; omit query for all, use query for fuzzy matches.

Instructions

Get ledgers (accounts) from TallyPrime. Omit query to get every ledger. Pass query to instead get a fuzzy-ranked shortlist of the closest-matching ledger names — useful when you have a rough or partial name (e.g. from a client document) and need Tally's exact spelling before creating a voucher or a new ledger, without pulling and scanning the entire ledger list yourself. Matches on exact/prefix/substring, then falls back to a loose in-order character match for abbreviations and typos (e.g. 'vro' finds 'VRO Technology'). Returns at most the top 20 matches, ranked best first; an empty result means create the ledger — nothing close enough exists yet. Each ledger includes VATTINNUMBER, VATDEALERTYPE, STATE, and COUNTRY (the values set via create_ledger's trn/vatDealerType/state/country fields, blank if never set), plus GSTIN, PAN, GSTREGISTRATIONTYPE, GSTTYPEOFSUPPLY, and CONTACTPERSON (set via create_ledger's gstin/pan/gstRegistrationType/gstTypeOfSupply/contactPerson fields — GSTIN/PAN/GSTREGISTRATIONTYPE are India's fields, distinct from trn/VATDEALERTYPE which are UAE-specific; a company only uses one country's set or the other, not both) — check the relevant ones before creating a Sales/Purchase invoice (or Credit/Debit Note, Delivery/Receipt Note) for that party: Tally itself defaults a new invoice's Buyer/Place-of-Supply details from the party ledger's own master data, so use these same values for buyerTrn/buyerState/buyerCountry rather than leaving them blank or guessing. Only ask the user to confirm instead of defaulting when the party has multiple registered delivery locations/addresses and it's genuinely unclear which one applies to this specific transaction (confirmed live: a real customer ledger can carry dozens of named addresses, and one invoice's Buyer address and Consignee/Ship-to address can legitimately differ from both the ledger's default and each other).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNoRough or partial ledger name to fuzzy-match against. Omit to get the full ledger list instead.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.11.2
    • addedInput schema / properties / query
      Added value: +{
+  "description": "Rough or partial ledger name to fuzzy-match against. Omit to get the full ledger list instead.",
+  "type": "string"
+}
  2. First observedv1.0.3

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover safety (readOnlyHint, openWorldHint), and the description adds substantial behavior beyond them: the matching cascade (exact/prefix/substring then loose in-order char match), a result cap (top 20, ranked best first), the empty-result meaning, and the downstream Tally defaulting behavior that motivates fetching these fields. No claim contradicts 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?

Front-loads the two most decision-critical facts (omit vs pass query) in the opening sentences, which is exactly right. It is dense as one long paragraph without visual breaks, and the field-by-field breakdown is verbose, but nearly every clause carries actionable guidance rather than filler.

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?

No output schema exists, so the description carries the return-value burden, which it does thoroughly: it enumerates which ledger fields are returned, ties each group to the create_ledger inputs that set them, explains the India-vs-UAE field distinction, and describes how to use the values for invoice fields. Nothing needed to call or interpret it correctly is missing.

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% for the single query param, so the baseline is 3, but the description adds real meaning beyond the schema: it explains the fuzzy-matching algorithm, the ranking, the top-20 cap, and the semantic consequence of omitting the param. This is more than restating the schema field.

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 ('Get ledgers (accounts) from TallyPrime') and immediately distinguishes the two modes: omit query for the full list, pass query for a fuzzy-ranked shortlist. An agent can tell it apart from siblings like get_groups or create_ledger without opening any 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?

Explicitly says when to use each mode ('useful when you have a rough or partial name ... and need Tally's exact spelling before creating a voucher or a new ledger'), and gives a concrete when-not-then rule ('an empty result means create the ledger'). It even specifies the confirmation fallback (only when multiple delivery locations make the choice genuinely ambiguous).

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