Skip to main content
Glama
MarketingBNG

tally-mcp

by MarketingBNG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

tally_create_master

Create a new TallyPrime master—group, cost centre, unit, stock item, voucher type, or budget—with validation and a preview before confirming the write.

Instructions

Create a NEW master in TallyPrime: an account group, cost centre, unit of measure, stock group, godown (location), stock item, voucher type or budget. For ledgers use tally_create_ledger.

Fields by kind: group needs parent (an existing group — its nature follows the parent). costCentre takes parent and category. unit takes formalName and decimalPlaces (name is the symbol, e.g. "kg"). stockGroup and godown take parent. stockItem takes parent (stock group), baseUnits (required) and an optional opening quantity and rate. voucherType needs parent (the type it is based on, e.g. "Sales") and takes numberingMethod. budget takes parent only; budget AMOUNTS are entered in TallyPrime itself.

REFUSES a name that already exists (TallyPrime would otherwise overwrite it) and any parent, category or unit that does not exist.

WRITES TO TALLYPRIME, in two steps. This call only PREVIEWS: it checks the change against the live books and returns exactly what would be written plus a confirmToken — nothing is changed. Show the preview to the user, and only after they approve it call tally_confirm_write with the token. Never confirm on your own initiative, and never confirm a preview the user has not seen.

Input Schema

NameRequiredDescriptionDefault
kindYesgroup, costCentre, unit, stockGroup, godown, stockItem, voucherType or budget. (Ledgers have their own tools.)
nameYes
parentNogroup: parent group (required). costCentre: parent cost centre. stockGroup: parent stock group. godown: parent godown. stockItem: its stock group. voucherType: the type it is based on, e.g. "Sales" or "Journal" (required). budget: parent budget. Empty for top level.
companyNoCompany name. Omit to use whichever company TallyPrime has loaded. If given and it is not the loaded one, the call fails with TALLY_COMPANY_NOT_LOADED rather than returning another company's data.
categoryNocostCentre only: its cost category.
baseUnitsNostockItem only: unit symbol, e.g. "kg". Required on create.
formalNameNounit only: full name, e.g. "Kilograms".
openingRateNostockItem only: opening rate per base unit.
decimalPlacesNounit only: decimal places for quantities.
numberingMethodNovoucherType only: number vouchers automatically or by hand.
openingQuantityNostockItem only: opening quantity in its base unit.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.2.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only give safety flags; the description adds real behavior beyond them: it refuses duplicate names (TallyPrime would otherwise overwrite) and nonexistent parents/categories/units, and it discloses the two-step preview/confirmToken write flow plus the human-approval requirement. This is the richest part of the definition.

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-loaded with purpose, then a dense 'Fields by kind' block, refusals, and the write workflow. Every sentence carries information, but the length is near the limit for the value added, with mild overlap between the description's ledger note and the schema's own parenthetical.

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, and the description compensates by promising a preview payload plus a confirmToken and explaining the confirm step. Combined with the per-kind field map and refusal rules, an agent has everything needed to call it correctly.

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?

Schema coverage is already 91%, but the description adds cross-parameter semantics the schema cannot express: which fields each kind requires (group/costCentre/unit/stockItem each get a per-kind field list, with parent and baseUnits marked essential). It also clarifies that 'name is the symbol' for units, resolving ambiguity beyond the per-parameter text.

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?

Opens with a specific verb and resource ('Create a NEW master in TallyPrime') and enumerates every creatable kind, so the agent knows exactly what the tool produces. It explicitly names the sibling it is not ('For ledgers use tally_create_ledger'), making it distinguishable 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?

Explicit routing to tally_create_ledger for ledgers, and a full when-to-use workflow: this call only PREVIEWS, then tally_confirm_write with the token after user approval. It even states the exclusion ('never confirm on your own initiative'), leaving nothing to inference.

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