Skip to main content
Glama
lokesh-sparrow

PNPC-MCP-Tally-Prime

get_ledgers

Read-only

Retrieve TallyPrime ledgers to verify exact account names. Pass a rough or partial name for ranked closest matches; omit query for full list. Empty results signal the ledger does not exist yet.

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, STATE, and COUNTRY (the values set via create_ledger's trn/state/country fields, blank if never set) — check these 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. Dates show when Glama detected each change.

  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.7/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses matching mechanics (exact/prefix/substring then loose in-order character match), output limit (top 20 ranked best first), the meaning of empty results, and exactly which fields are included (VATTINNUMBER, STATE, COUNTRY) along with downstream implications for invoice creation. It even cites a live confirmation about multiple addresses.

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?

The description is long, but every sentence carries useful information: mode selection, matching rules, output limits, field details, and procedural advice for invoice creation. It is front-loaded with the core action and then expands into necessary context. A little trimming could improve scannability, but the length is justified.

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?

With no output schema, the description compensates by explaining return contents and limits. It covers both usage modes, provides edge cases (empty result, multiple addresses), and gives actionable downstream guidance (using VATTINNUMBER/STATE/COUNTRY for invoice buyer details). An agent has everything needed to invoke this tool correctly in a real workflow.

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

Parameters5/5

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

Although schema coverage is 100% for the single 'query' param, the description adds substantial semantics: how matching works, example behavior ('vro' finds 'VRO Technology'), the maximum result count, and what an empty result implies. This goes far beyond the schema's bare description and genuinely helps an agent use the parameter correctly.

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 opens with a clear verb and resource ('Get ledgers (accounts) from TallyPrime') and immediately distinguishes two modes: omit query to list all, or pass query for fuzzy-matched shortlist. This precisely differentiates it from sibling get_* tools like get_groups or get_voucher_types.

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 explicitly states when the query mode is useful: when you have a rough/partial name and need exact Tally spelling before creating a voucher or ledger, without pulling the entire list. It also explains how empty results signal 'create the ledger'. While it doesn't name alternative tools to consider, the guidance is concrete and contextual enough for an agent to decide correctly.

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