Skip to main content
Glama
lokesh-sparrow

PNPC-MCP-Tally-Prime

query_sql

Read-only

Run a read-only SQL SELECT against synced TallyPrime data in the session's in-memory cache to analyze ledgers, vouchers, and stock movement, or to query auto-populated report tables.

Instructions

Run a read-only SQL SELECT query against this session's in-memory cache (gone when the session ends). Tables: ledgers(name, parent, closing_balance, trn, state, country), groups(name, parent), stock_items(name, parent, closing_balance), vouchers(guid, date, voucher_type, voucher_number, party_ledger, amount, narration), voucher_items(voucher_guid, date, voucher_type, voucher_number, stock_item, qty, rate, amount, is_deemed_positive, godown, batch), voucher_ledger_entries(voucher_guid, date, voucher_type, voucher_number, ledger, amount, is_deemed_positive, cost_centre, bill_name, bill_type, description) — all six populated only by explicitly calling sync_to_sql/sync_vouchers_to_sql/sync_voucher_items_to_sql/sync_voucher_ledger_entries_to_sql first. Movement analysis, godown-wise stock, and batch/ageing detail are just SELECTs over voucher_items — there is no separate report tool for them. Splitting a ledger's balance apart by voucher (e.g. a combined VAT ledger into Output vs Input), or reconciling a party ledger's movements voucher by voucher, is just a SELECT over voucher_ledger_entries the same way — voucher_ledger_entries.amount is signed (negative debit, positive credit), so GROUP BY ledger, voucher_type with SUM(amount) is the natural query. profit_and_loss(ledger_name, group_name, closing_balance, period_from, period_to), stock_summary(name, parent, opening_qty, closing_qty, opening_value, closing_value, as_of_date), balance_sheet(group_name, amount, as_of_date), trial_balance(name, debit_amount, credit_amount, period_from, period_to), vat_summary(ledger_name, category, closing_balance, period_from, period_to), and gst_summary(ledger_name, category, closing_balance, period_from, period_to) are populated automatically, no separate sync step — every get_profit_and_loss/get_stock_summary/get_balance_sheet/get_trial_balance/get_vat_liability_summary/get_gst_liability_summary call refreshes its table with that call's result, so a follow-up question about the same report can query it here instead of re-fetching from Tally. Each of these six only ever holds the most recent call's data, not a history — re-call the report tool if you need a different period. Every call here checks which company is actually open in Tally right now against what the cache was last synced/queried for, however that company was arrived at (set_company, Tally's own UI, or a connector restart) — a mismatch clears the stale cache and refuses to run, rather than silently answering with a previous company's rows under the new company's name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sqlYesA single SELECT statement

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.3

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds substantial context beyond them: the cache is ephemeral ('gone when the session ends'), report tables hold only the most recent call's data, and a company mismatch clears the cache and refuses execution rather than silently answering with stale rows. This is rich behavioral disclosure that annotations alone cannot convey.

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

Conciseness3/5

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

The core purpose is front-loaded in the first clause, and the dense content is largely justified by the tool's complexity. However, it is delivered as one giant run-on paragraph with no sub-structure, and the report-table enumeration plus the company-check explanation could be tightened, so structure and readability suffer.

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?

For a one-param, no-output-schema tool, the description covers everything an agent needs: the queryable tables and their columns, sync prerequisites, which tables auto-refresh, cache lifetime, sign conventions, and the company-mismatch safety behavior. Nothing material 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% and the single 'sql' param is documented as 'a single SELECT statement', so baseline is 3. The description goes further by documenting the full column schema of every queryable table and the sign convention of voucher_ledger_entries.amount, which directly tells the agent how to construct the parameter value.

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 (run a read-only SQL SELECT) against a named resource (this session's in-memory cache) and enumerates the exact tables available. It explicitly positions itself against siblings by noting that movement analysis, godown-wise stock, batch/ageing, and ledger splitting are 'just SELECTs' with no separate report tool, so an agent can distinguish it from get_stock_summary and similar.

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?

Gives explicit when-to-use routing: sync_to_sql/sync_vouchers_to_sql must be called first for the six core tables, while the six report tables are auto-populated and refreshed by the corresponding get_* calls. It also states the guard condition (open-company mismatch clears stale cache and refuses to run), which is exactly the kind of prerequisite an agent needs before invoking.

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