Skip to main content
Glama
tally-prime-mcp

tally-prime-mcp

delete_master

Permanently delete a Tally ledger, group, stock item, or similar master after taking a backup; requires confirmation and fails if referenced by vouchers.

Instructions

Permanently delete a ledger, group, stock item, stock group, godown, unit or cost centre (a backup is taken first). Tally refuses if it is still used by vouchers or other masters. Requires confirm: true; get the user's approval first.

Input Schema

NameRequiredDescriptionDefault
nameYes
typeYes
companyNoCompany name as shown in Tally. Omit to use the currently active company.
confirmYesMust be true
dry_runNoIf true, only return the XML that would be sent; nothing is written to Tally and no backup is taken.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: permanent/deleting nature, backup taken first, Tally-side refusal when referenced by vouchers, and the confirmation gate are all disclosed. This is exactly the behavioral context an agent needs before a destructive call.

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?

Three tight sentences, front-loaded with the destructive scope before the caveats. No filler; each sentence adds either scope, failure mode, or the confirmation requirement.

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?

For a destructive master tool with no output schema, it covers consequences (permanence, backup, refusal conditions) and the confirmation gate. Minor gap: it never points to list_backups or explains where the backup lands, nor mentions dry_run for safe rehearsal.

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 coverage is 60%, and the description mostly restates what the schema says ('Requires confirm: true' duplicates the schema's 'Must be true'). It never mentions the dry_run escape hatch or the company parameter, which would have been meaningfully additive.

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 ('Permanently delete') plus an enumerated set of resources and distinguishes itself from the delete_voucher / alter_master siblings by naming exactly which master types it covers. An agent can route here without inspecting the schema.

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?

Gives a clear precondition ('Requires confirm: true') and a process instruction ('get the user's approval first'), plus an implicit precondition that the object must be unused. It does not explicitly say when to prefer alter_master or create_master, so sibling exclusions are only implied.

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