PNPC-MCP-Tally-Prime

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.11.2
Disambiguation4/5
Most tools have clearly distinct purposes and the descriptions do exceptional cross-referencing work (e.g. create_delivery_note explicitly contrasts itself with create_rejections_out, and get_vouchers vs get_ledger_vouchers are clearly scoped). The main ambiguity risk is the many near-identical create_X/update_X inventory voucher pairs (material in/out, rejections in/out, receipt/delivery notes) where an agent must read carefully to pick the right one.
Naming Consistency5/5
The naming scheme is uniformly verb_noun in snake_case: get_* for all reads, create_*/update_*/delete_* for writes, set_* for context changes, sync_* for SQL caching, and preview_write/confirm_write as a coherent pair. The only mild outlier is get_receipts_and_payments, which mirrors Tally's own report name and doesn't disrupt the pattern.
Tool Count2/5
At 85 tools this is far beyond the 25+ 'too many' threshold and places a heavy burden on agent tool-selection, driven mostly by systematic create_X/update_X pairs across ~17 voucher types. The TallyPrime domain genuinely is a full ERP and there's little redundancy, but the surface is still too large for practical navigation.
Completeness4/5
The tool set covers the full voucher lifecycle (create/update/delete for practically every major voucher type), master CRUD via create_*/delete_master, all core financial reports, VAT/GST liability summaries, and a sync_to_sql/query_sql layer that lets agents compute anything not exposed as a canned report. Minor gaps: several master types (unit, godown, stock group, cost centre, cost category) are create-only with no update path, and there's no cancel_voucher tool — only permanent delete.
Average 4.3/5 across 83 of 85 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 64 commits in the last 12 weeks
- Last stable release on September 3, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating, non-idempotent operation, but the description adds no behavioral detail beyond 'create'. It does not disclose what happens on duplicate names, whether existing stock items are replaced, whether Tally-side validation is performed, or what the caller should expect after invocation.
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?
The description is a single, focused sentence with no filler or redundant elaboration. It is efficient and immediately readable, though minimal in scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, no output schema, and many sibling creation tools, the description is too sparse. It omits necessary context like success/error behavior, required existing masters (e.g., group/unit), and the relationship to update_stock_item. The rich schema helps but does not compensate for the missing usage and outcome context.
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 description coverage is 100%, so every parameter is already well documented in the input schema. The tool description adds no parameter semantics, but the baseline of 3 applies because the schema carries the full burden and does so effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and the resource ('a new stock item in TallyPrime'), making the tool's basic function unambiguous. It is distinguishable from obvious siblings like update_stock_item and delete_stock_item by the word 'new', though it does not explicitly differentiate itself from other create_* tools beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no mention of prerequisites such as the stock group or unit already existing, and no note about cases where update_stock_item or create_stock_group would be more appropriate. The usage is only implied by the tool name, which is insufficient given the large sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=false. The description adds no behavioral details beyond what annotations provide, such as data format or scope, but there is no contradiction.
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?
The description is a single sentence that directly conveys the purpose. There is no wasted text, and it is appropriately concise for a parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and annotations cover basic safety info, the description is minimally adequate. However, it could indicate the format of returned data or link to related sibling tools for better completeness.
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?
The tool has 0 parameters and schema coverage is 100%. With no parameters, the baseline for this dimension is 4, and the description adds no additional semantic information about parameters, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it gets 'all stock items from TallyPrime', which is a specific verb+resource. However, it does not distinguish itself from sibling tools like get_stock_summary, so the purpose is clear but not uniquely differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. With many sibling tools (e.g., get_stock_summary, update_stock_item, create_stock_item), the description offers no context for selection, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description properly states it returns a balance sheet, which aligns with the read-only annotation. However, it doesn't describe what the response looks like (no output schema provided), whether it includes period comparisons, or if it respects the company set via set_company. For a report tool, these are useful behavioral details.
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?
The description is a single sentence with 11 words, no filler, and front-loads the key action and resource. Every word earns its place. Given the tool is simple (1 parameter, read-only), this is optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter read-only tool with 100% schema coverage, the description is adequate. However, without an output schema, it could benefit from mentioning what the balance sheet contains (e.g., assets, liabilities, equity) and whether it uses the currently set company/period from set_company/set_period. The current level is minimally complete but not informative beyond the tool's basic signature.
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 100% with one parameter (asOf) already described in the schema as 'As-of date in DD-MM-YYYY format'. The description adds no further semantics about the date meaning (e.g., whether it's the end date or an effective date). Since coverage is high, a baseline of 3 is appropriate – the schema carries the load, but the description misses an opportunity to clarify the date semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('Balance Sheet') and adds a contextual qualifier ('from TallyPrime as of a given date'). It distinguishes itself from siblings like get_profit_and_loss and get_trial_balance by targeting a specific report type, but it doesn't explicitly differentiate from close siblings like get_bills_receivable. A 4 is given because the purpose is very clear but sibling differentiation is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., get_trial_balance or get_profit_and_loss). It does not mention prerequisites, typical scenarios, or related tools. With 27 siblings covering many Tally operations, this omission makes it harder for an agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already indicates readOnlyHint=true, so the read-only nature is clear. The description adds no additional behavioral context (e.g., return format, permissions, or side effects). It is consistent but minimal.
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?
The description is a single sentence of 10 words with no wasted content. It is front-loaded with the purpose and immediately useful.
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?
Given the tool's simplicity (2 required params, no output schema, clear annotations), the description is adequate. It covers the core purpose and constraints. However, it could mention that the output is a financial report with income/expense categories, which would be helpful for an agent.
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 100%, with clear parameter descriptions for 'from' and 'to' (DD-MM-YYYY format). The description's mention of 'date range' adds no new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'Profit & Loss statement from TallyPrime', along with the date range constraint. However, it does not explicitly distinguish this tool from siblings like get_balance_sheet or get_trial_balance, which are also financial reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios where this tool is appropriate or when to prefer sibling tools like get_balance_sheet or get_ledgers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description correctly implies a read operation, consistent with the readOnlyHint annotation. It adds the context that Bills Receivable are outstanding and date-specific. However, it does not detail what 'outstanding' means, whether the result is paginated, or if there are any limits, but given annotations handle the idempotency, a 3 is fair.
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?
The description is a single, concise sentence that conveys the essential purpose without extraneous words. It front-loads the action and resource, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one simple parameter (well-documented), a readOnly annotation, and no output schema, the description is adequate. It covers the core functionality, though it could be slightly more complete by clarifying what 'outstanding' entails or how the output is structured.
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?
There is exactly one parameter (asOf) and its description in the schema is already clear: 'As-of date in DD-MM-YYYY format'. The description in the tool description does not add extra meaning beyond the schema's description. With 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'outstanding Bills Receivable' from TallyPrime, as of a given date. It uses a specific verb ('get') and resource ('Bills Receivable'), and the as-of date condition distinguishes it from generic list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used to get outstanding bills receivable as of a specific date. However, it does not explicitly state when to use this tool versus sibling tools like 'get_bills_payable' or 'get_vouchers', nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=false. Description adds no contradiction and is consistent. It does not elaborate further but is adequate given 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?
Single, concise sentence. Front-loaded with action. No wasted words, though could be slightly more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With many sibling tools and no output schema, the description is minimal but works for a simple zero-param retrieval tool. Lacks detail on return structure, but annotations partially compensate.
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 has zero parameters with 100% description coverage, so baseline is 4. Description adds no extra parameter info but is not needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States verb 'Get' and resource 'all cost centres from TallyPrime' clearly. However, it does not distinguish from sibling tools like get_groups or get_ledgers which also retrieve master data from TallyPrime.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives like get_groups. No mention of scope or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true, so the description correctly implies a safe read operation. The description adds that it retrieves 'configured' types, which hints at the data being pre-existing in Tally. However, it doesn't mention what happens if no company is selected or if Tally is empty. With annotations providing the safety profile, a 3 is appropriate.
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?
A single, compact sentence that immediately conveys the tool's purpose and provides clarifying examples. Zero wasted words, perfectly front-loaded.
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 zero-parameter, read-only tool with good annotations, the description is mostly complete. It explains the purpose and what data is returned. The only gap is not mentioning that you typically need set_company first, but this is a minor omission given the tool's simplicity and the annotations cover safety.
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?
The input schema has zero parameters with 100% coverage, so the schema already fully documents that no parameters are needed. The description adds value by explaining what the result contains (voucher types) with concrete examples, compensating for the lack of an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), the resource ('voucher types'), and explicitly distinguishes it from siblings by providing examples (Payment, Sales, Journal). It differentiates it from get_vouchers which returns voucher records rather than types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives like get_vouchers or other configuration tools. It doesn't mention prerequisites (e.g., company must be set via set_company) or when you'd need voucher types before creating vouchers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructive and non-read-only behavior. The description adds that item lines, party, order number, and narration are replaced, which is useful destructive context, but the promised 'matching/collision caveats' are only referenced, not disclosed. It neither contradicts annotations nor fully explains the destructive matching behavior.
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?
Two dense sentences with no filler, front-loading the core action and affected fields. The second sentence is economical but pays for its brevity by leaning on sibling references instead of stating the caveats inline.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive update with 6 parameters and no output schema, the description needs to state matching/collision behavior concretely; instead it defers entirely to update_sales_order, whose description is not provided. The schema mitigates some gaps, but the agent still cannot know what collisions may occur or how the update resolves them.
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 100%, so the schema already documents each parameter. The description adds the useful grouping that these are the same fields as create_sales_quotation plus voucherNumber, and that item lines are replaced, but it does not add per-parameter meaning beyond the schema.
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 (Update), a specific resource (existing Sales Quotation in TallyPrime), and the fields affected (item lines, party, order number, narration). It differentiates from create_sales_quotation by noting the added voucherNumber and from update_sales_order by name, so an agent can route correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by 'Update an existing Sales Quotation' and the comparison to create_sales_quotation, but there is no explicit when-to-use/when-not-to-use guidance. The reference to 'same matching/collision caveats as update_sales_order' assumes knowledge of another tool's description rather than stating the conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal a non-read-only, non-idempotent, non-destructive operation. The description adds useful domain context (cost tracking use case), but does not disclose duplicate-name handling, parent validation, or other creation-time behavior beyond the schema.
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?
A single sentence that states the action, gives practical examples, and points to the relevant field on another tool. No wasted words.
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 simple 3-parameter creation tool, the description plus full schema coverage and annotations are mostly sufficient. It could mention duplicate behavior or result shape, but an agent can safely select and invoke it based on the provided context.
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 description coverage is 100%, so the schema already documents name, parent, and category, including the default for category. The description adds only entity-level context and a cross-reference to create_voucher; it does not meaningfully expand parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb and resource ('Create a new Cost Centre in TallyPrime') and gives concrete examples (department, branch, project). However, it does not explicitly distinguish this from the sibling create_cost_category, though the cross-reference to create_voucher's costCentre fields helps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when you need a cost centre to tag voucher entries for cost tracking, and it points to create_voucher for related fields. It does not state when not to use it or how it differs from the closely related create_cost_category.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the core behavioral trait is covered. The description adds that results are 'outstanding' and tied to a specific date, which is useful but limited. No additional traits (e.g., pagination, what 'outstanding' means) are disclosed. With annotations handling the safety profile, this is adequate but not exceptional.
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?
A single sentence that starts with the core verb and resource, includes the key constraint ('outstanding', 'as of a given date'), and contains no extraneous words. Every part earns its place.
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 simple read tool with one parameter and no output schema, the description covers the essential purpose and filtering (date, outstanding status). It does not explain return format or provide examples, but given the low complexity, it is mostly adequate. Minor gap: missing what 'outstanding' means legally or in TallyPrime.
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 description coverage is 100% (the one parameter asOf has its own description). The tool description restates 'as of a given date', which aligns with the schema but adds no deeper meaning (e.g., date format, behavior if absent). With full schema coverage, a baseline of 3 is appropriate.
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 uses a specific verb ('Get'), resource ('Bills Payable'), and scope ('outstanding ... as of a given date'), making it clear what the tool does. It naturally distinguishes from sibling tools like get_bills_receivable (which retrieves incoming bills) and other get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. For example, it does not note that get_bills_receivable should be used for outstanding receivables, or that get_vouchers might provide more granular transaction details. The description merely states the function without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description describes a state-changing operation ('Switch... active company context'), contradicting the annotation readOnlyHint: true. This is a serious inconsistency that misleads the agent about the tool's safety profile. The description does not disclose other behavioral traits (e.g., permission requirements, side effects).
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?
Single sentence with no wasted words, efficiently conveying the action and a crucial validation tip. Perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too brief for a tool that changes state, especially given the contradictory annotation. It does not explain the implications of switching context, return values, or error conditions. The validation tip is helpful, but the overall completeness is low due to the unresolved contradiction.
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 covers 100% of parameter descriptions, but the description adds value by instructing to validate the company name before use, which goes beyond the schema's 'Exact name' description. This helps the agent avoid errors.
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?
Description states 'Switch TallyPrime's active company context' — a specific verb ('switch') and resource ('active company context'), clearly distinguishing it from sibling tools that mostly retrieve or create data (e.g., get_ledgers, create_ledger).
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?
Explicitly advises to validate the company name using get_ledgers, get_company_info, or the company list before calling, which is a clear pre-usage guideline. Does not mention when not to use, but the context of siblings makes the purpose obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, indicating it is a safe read operation. The description adds the date constraint but does not disclose additional behavioral traits such as the format of the report, whether it includes all stock items, or any limitations. With annotations covering the safety profile, a score of 3 is appropriate.
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?
The description is a single sentence that is front-loaded with the key action and resource. Every word is necessary, and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimally adequate. However, it does not explain what the stock summary report contains (e.g., quantities, values) or any return format. For a tool with no output schema, a bit more detail would improve completeness, but it is not severely lacking.
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 description coverage is 100% (the 'asOf' parameter includes format and constraints). The description's phrase 'as of a given date' aligns with the schema but adds no extra meaning beyond what is already in the schema. Baseline 3 is correct.
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 clearly states the verb 'Get', the resource 'Stock Summary report', and the constraint 'as of a given date'. This effectively distinguishes it from sibling tools like get_stock_items (individual items) and other financial reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a stock summary report for a specific date is needed, but it does not explicitly state when to use this tool over alternatives (e.g., get_stock_items for item-level details) or when not to use it. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation, so the bar is lowered. However, the description adds no extra behavioral context such as potential date validation, pagination, or what happens with empty ranges. It is neither contradictory nor helpful beyond the annotation.
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?
The description is a single, well-structured sentence that front-loads the action and resource. Every word is necessary; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters and no output schema, the description is adequate for a basic fetch operation. However, it omits any mention of the return format or dependencies (e.g., requiring a company to be set via sibling 'set_company'), which would improve completeness.
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?
The input schema provides 100% coverage of the two parameters, including format details (DD-MM-YYYY). The description only restates 'date range' without adding semantic nuance or example values, so it adds marginal value over the schema.
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 uses the specific verb 'Get' and the precise resource 'Trial Balance' from 'TallyPrime', with the clear scope 'for a date range'. This clearly distinguishes it from sibling tools like 'get_balance_sheet' or 'get_profit_and_loss', which address different financial reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a trial balance over a date range is needed, but it provides no explicit guidance on when not to use it, nor does it mention alternative sibling tools (e.g., 'get_balance_sheet') or prerequisites (e.g., setting a company). This leaves room for misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructive, idempotent), the description adds that it replaces item lines, party, and narration, which is consistent with destructiveHint. However, it does not describe error behavior, return values, or side effects beyond replacement. The reference to 'collision caveats' hints at potential conflicts but does not elaborate, leaving behavioral details partially unspecified.
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?
The description is concise (two sentences), front-loaded with the primary action, and efficiently references sibling tools for caveats. It avoids redundancy and is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete in that it relies on the sibling tool update_delivery_note for matching/collision caveats without summarizing them. It also lacks any mention of output or return format (there is no output schema), and does not explain failure conditions related to non-existent voucher numbers or other edge cases. While the core purpose is clear, the broader context is incomplete.
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?
The schema itself provides detailed descriptions for all parameters, including nested items and specific field explanations (e.g., godown auto-fill behavior). The tool description adds little beyond the schema, merely stating 'Same fields as create_receipt_note' and 'replacing item lines, party, and narration', which does not significantly enhance understanding of parameter semantics beyond what the schema already offers.
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 clearly states the action (update), the resource (Receipt Note in TallyPrime), and the scope (replacing item lines, party, and narration). It also distinguishes itself from create_receipt_note by explicitly adding voucherNumber, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description references 'Same matching/collision caveats as update_delivery_note' which provides some guidance by analogy, but it does not explicitly state when to use this tool over other update tools or when it should not be used. The tool name alone implies the document type, but the description lacks explicit usage conditions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose destructive and idempotent behavior, but the description fails to clarify a critical update semantics: whether omitted optional fields are left unchanged or reset to defaults. Since all fields except name are optional, this ambiguity materially affects correctness. The description adds no behavioral detail beyond the annotations and the reference to create_stock_item does not resolve this.
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?
The description is a single, clear sentence. The primary purpose is front-loaded and the reference to create_stock_item is concise. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and parameter scope, and the annotations provide idempotency and destructiveness. However, the key update behavior (partial vs. full update) is not specified, and error conditions (e.g., non-existent name) are not addressed. Given the tool has 7 optional parameters, this is a notable gap, but the reference to create_stock_item partially mitigates it.
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 description coverage is 100%, so every parameter is documented. The description adds value by pointing to create_stock_item for field semantics, but it doesn't elaborate on the parameters themselves. With full schema coverage, a baseline of 3 is appropriate.
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 clearly states the action ('Update') and the resource ('an existing stock item in TallyPrime'), and even references its create counterpart. It is specific and unambiguous, and distinguishes itself from the many create_* siblings by the use of 'Update' and 'existing'.
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 implies the tool is for modifying an existing item rather than creating one, and explicitly contrasts with create_stock_item via 'same fields as create_stock_item'. It does not explicitly state when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true (safe read) and openWorldHint=false. The description adds minimal extra behavioral context (source 'from TallyPrime') but does not disclose traits like response limits, auth requirements, or performance implications. It neither contradicts nor significantly enriches 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 14-word sentence that front-loads the core purpose. Every word earns its place—no filler, no repetition. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite zero parameters and good annotations, the absence of an output schema means the description should explain what the returned data includes (e.g., group names, IDs, hierarchy). It does not, leaving an AI agent uncertain about the tool's output structure. For a simple list tool, some completeness 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?
With zero parameters and 100% schema coverage, the description correctly implies no input is needed. It adds no redundant parameter info. Per guidelines, zero parameters earns a baseline of 4, and the description meets that adequately.
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 clearly states 'Get all account groups' with specific examples (Sundry Debtors, Fixed Assets), distinguishing it from siblings like get_ledgers or create_group. The verb+resource is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a list of account groups is needed, but provides no explicit guidance on when to avoid this tool or alternatives. With siblings like get_ledgers and get_stock_items, the context makes differentiation possible, but the description itself lacks explicit exclusions or comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the description does not need to restate safety. The description adds no further behavioral context beyond the basic operation (e.g., no mention of ordering, limits, pagination, or error handling). Adequate but not enriched.
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?
A single, front-loaded sentence of 12 words with no redundancy. Every word serves a purpose. Excellent conciseness.
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 simple read-only tool with no output schema, the description is nearly complete. It fully communicates the resource and constraints. Minor gaps: no mention of response structure, error handling for non-existent ledger, or whether results are paginated. Still, the agent can reasonably infer expected behavior.
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?
All three parameters have 100% schema description coverage. The description ('ledger name', 'date range') aligns with the schema but does not add new semantic meaning beyond what the schema already provides. Baseline of 3 is appropriate.
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 clearly states the action ('Get'), the specific resource ('voucher entries'), and the constraints ('posted to a specific ledger within a date range'). This distinguishes it from siblings like 'get_vouchers' (all vouchers) and 'get_ledgers' (list ledgers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when you need vouchers for a specific ledger in a date range) but does not provide explicit guidance on when to use versus alternatives, nor does it state any exclusions or when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safe/read-only nature. The description adds context that the result is a monthly summary rather than raw voucher data, which is useful behavioral information. But it doesn't elaborate on return format, pagination, or other operational behavior. With annotations present, this modest addition merits a 3.
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?
A single, well-structured sentence that front-loads the core action and resource, followed by the summary nature and a helpful sibling reference. No wasted words or redundant schema repetition.
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 simple two-parameter read-only tool with no output schema, the description gives the essential behavior: it retrieves a month-by-month Purchase Register for a date range. The output nature is briefly described, and the 'same design as get_sales_register' reference helps agents infer expected structure. Some return-field details are absent, but the tool's simplicity and annotations keep this adequate.
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?
The input schema fully describes both parameters ('from' and 'to') with format 'DD-MM-YYYY', so description coverage is 100%. The description adds only the general notion of a date range, which adds no meaning beyond the schema. Baseline 3 is appropriate.
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 clearly states the action ('Get'), the specific resource ('Purchase Register from TallyPrime'), and defines the output ('a month-by-month summary of Purchase voucher activity'). It also references the sibling tool get_sales_register, reinforcing its identity and distinguishing it as the purchase-specific analog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when a Purchase Register summary for a date range is needed. However, it does not explicitly state when not to use it or compare it to other register tools beyond noting the same design as get_sales_register. This leaves usage guidance largely inferred rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this tool as read-only (readOnlyHint: true) and not open-world (openWorldHint: false). The description appropriately confirms it changes global context for subsequent queries, which adds value by explaining the scoping effect. However, it does not disclose whether switching periods affects concurrent requests or if there is a default period reset behavior.
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?
The description is a single, focused sentence that efficiently conveys the tool's purpose and effect with no wasted words. All key information is front-loaded.
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?
Given the tool is simple (2 params, no output schema), the description covers the essential behavioral details. It explains the global effect and persistence until changed. However, it could mention that date format validation is enforced by the schema, and that the tool is typically used in conjunction with some sibling reporting tools. The score of 4 reflects slight room for improvement in completeness.
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 description coverage is 100%, so the schema already documents both parameters with format hints (DD-MM-YYYY). The description reinforces that these parameters set the global date range for reporting, but does not add new meaning beyond what the schema provides. A score of 3 reflects adequate but not enhanced parameter understanding.
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 uses the specific verb 'Switch' and clearly identifies the resource as 'TallyPrime's active reporting period'. It further explains that it changes the global from/to date context, which effectively distinguishes this tool from siblings like 'set_company' or 'get_vouchers'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states that the tool is used for subsequent report queries until changed again, implying it should be set before running reports. However, it does not explicitly state when not to use it versus alternatives, nor does it mention any prerequisites like having a company set first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds that it 'replaces' item lines, which is consistent with destructive behavior. However, it references 'Same matching/collision caveats as update_sales_order' without explaining what those caveats are, leaving a gap in behavioral disclosure beyond annotations.
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?
Two sentences with no filler. The primary action and key differentiators are front-loaded, and references to sibling tools are concise. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex operation with 6 parameters, 5 required, and a nested items array, the description is overly brief and relies on two external references ('Same fields as create_purchase_order' and 'Same matching/collision caveats as update_sales_order') without elaborating. There is no output schema, and the description does not explain return behavior, errors, or prerequisites. An agent cannot fully understand the tool's behavior from this description alone.
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 100% with detailed descriptions for every parameter, so the schema already carries the semantic load. The description adds minimal parameter info beyond noting that voucherNumber is the identifier and that fields match create_purchase_order. This is adequate given the schema, but the description does not compensate for any missing context beyond what the schema provides.
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 ('update') and resource ('Purchase Order'), and explicitly says it replaces item lines, party, order number, and narration. Clearly distinguishes from create_purchase_order by noting the extra voucherNumber field, and references update_sales_order for matching caveats, so an agent can tell it apart from siblings.
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?
Implicitly indicates use when updating an existing order (requires voucherNumber) versus creating a new one (create_purchase_order). It mentions 'Same fields as create_purchase_order' and 'plus voucherNumber', which implies that if you have a voucher number you use this tool. However, it does not explicitly enumerate when not to use it or list alternative tools for similar operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, idempotentHint=false) already signal this is a mutating, non-idempotent write, and the description's 'Create' is consistent with them. The description adds the prerequisite/ordering context between category and cost centre, which is useful. However, it does not disclose duplicate-name behavior, failure modes, or the need for a prior set_company call, so the added behavioral context is modest.
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?
Two short sentences with zero waste. The primary action is front-loaded, and each additional element — the parenthetical example and the prerequisite note — earns its place by disambiguating the concept and guiding when to call.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple 3-parameter create with no nested objects and a fully documented schema. However, there is no output schema and the description says nothing about return values, duplicate-name behavior, or the write-confirmation workflow hinted at by the preview_write and confirm_write siblings — clear gaps an agent must guess at.
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 description coverage is 100% — all three parameters (name, allocateToRevenue, allocateToNonRevenue) are already documented with types and defaults in the input schema. The description adds no parameter-specific meaning beyond the schema, so the baseline 3 applies.
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 ('Create a new Cost Category in TallyPrime') and clarifies the domain concept with concrete examples ('grouping of cost centres, e.g. Branch, Project'). This actively distinguishes it from the sibling create_cost_centre by defining the containment relationship between category and centre.
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?
Provides a clear usage context: 'Required before creating a cost centre under a category that doesn't exist yet.' This effectively tells an agent when this tool is the right choice, implying the alternative (proceeding with create_cost_centre) when the category already exists. It doesn't name alternatives explicitly or state exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate that this is a write operation, is not idempotent, and is not flagged destructive. The description adds the useful update/rename behavior, but does not disclose what happens in edge cases such as an oldName that does not exist or whether unspecified fields are overwritten on update. With annotations present, this is adequate but not rich.
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?
The description is a single, front-loaded sentence with no filler. It states the primary action first, then the secondary mode, and every word earns its place.
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?
Given the rich 100%-covered input schema and the explicit annotations, the description is mostly complete for selection and invocation. The main gap is the lack of any mention of return value or success/failure indication, especially since no output schema is provided. Still, the core behavior and mode selection are well covered.
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 description coverage is 100%, with detailed explanations for all 19 parameters including examples and caveats. The tool description itself adds little beyond pointing to oldName, so the schema carries the parameter-semantics burden and the baseline of 3 applies.
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 uses a specific verb ('Create') and a concrete resource ('ledger (account) in TallyPrime'), and immediately clarifies the dual create/update capability with 'rename/update an existing one by passing oldName'. This clearly differentiates it from sibling tools like create_group and get_ledgers.
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 gives clear usage context: create a new ledger, or update/rename an existing one by supplying oldName. It does not explicitly name alternative tools or state when not to use it, but the primary usage scenario is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits beyond the annotation hints: this is job-work memorandum tracking with no real accounting posting, stock is sent out, and it is not a sale. It also documents a known live error ('Voucher date is missing') and the exact remediation using set_period. The only weakness is the cryptic, undefined 'EXTRAPOLATED caveat' reference, which reduces some transparency.
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 compact and front-loaded: purpose first, relationship to sibling second, and error-handling guidance last. Every major point is covered without filler. It loses a point because 'Same EXTRAPOLATED caveat' is opaque and would mean nothing to an agent without access to the sibling tool's full documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is strong on purpose, side effects, and known failure recovery, which is a lot of context for a create-type tool with no output schema. However, it is not fully standalone: the 'EXTRAPOLATED caveat' is never explained, and the description does not mention what successful execution returns or confirms. These are meaningful gaps for an agent deciding whether the call succeeded.
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?
The schema already has 100% description coverage for all parameters, including date format, partyLedger, items, and voucherNumber behavior. The tool description reinforces the godown requirement and the date field error, but it does not add new field-level semantics beyond what the schema provides. Baseline 3 is appropriate.
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 specific verb and resource: 'Create a Material Out voucher'. It then defines the exact business purpose — recording stock sent to a job worker for processing — and explicitly distinguishes this from a sale ('not a sale') and from its inbound counterpart ('Mirror of create_material_in'). An agent can confidently tell this tool apart from creation_voucher, create_material_in, and sales-related tools.
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?
It gives clear context for when to use the tool: when stock is sent out to a job worker for processing, as a memorandum rather than a real accounting transaction. It also names create_material_in as a mirror and notes a recovery path via set_period. However, it does not explicitly enumerate all the alternatives it should not be used for (e.g., sales invoice, delivery note, rejection out), so the guidance is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false. The description adds genuine behavioral context: it is Tally's own canned report, accessed via a plain Export Data request, and returns the native RATIONAME/value array shape unchanged. This goes beyond the annotations and explains what the agent will receive and the operational nature of the 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?
The description is compact and front-loaded: it names the report and its scope in the first clause, then adds a useful parenthetical of contained ratios, followed by two short phrases about the request mechanism and return shape. Every sentence earns its place without redundancy.
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 simple read-only report tool with two documented parameters, the description covers the essential purpose, scope, and return shape. The phrase 'native RATIONAME/value array shape as-is' is helpful but slightly vague, and there is no mention of empty results or behavior when no data exists for the date range. Still, it is sufficient for a low-complexity tool.
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?
The input schema already fully documents both parameters (from, to) with descriptions and the DD-MM-YYYY format, so schema coverage is 100%. The description only restates that the report is for a date range, adding no new parameter-level meaning beyond what the schema provides.
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 uses a specific verb ('Get'), a clear resource ('Ratio Analysis report from TallyPrime'), and a date-range scope. The parenthetical list of ratios (Working Capital, Current Ratio, etc.) makes the report's content unambiguous and distinguishes it from sibling report tools like get_balance_sheet or get_profit_and_loss.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use this tool when you need Tally's canned Ratio Analysis for a date range. However, it does not explicitly state when not to use it, nor does it name alternative tools for related financial reports (e.g., get_balance_sheet, get_cash_flow), so the agent must infer the decision boundary from the report name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations all false (no read-only, no idempotent, no destructive flags), the description carries the burden. It discloses that the tool reverses stock and revenue, mentions the dual-role deletion caveats, and provides a live confirmation of the stock quantity increase. This goes beyond the schema and gives the agent a realistic expectation of side effects, though it does not discuss reversibility or error behavior in detail.
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 a single, dense paragraph that front-loads the purpose and key distinctions. It is efficient but packs many details (sign pattern, live confirmation, caveats) into one block without bullet points or headings. It remains readable and not overly long, though a structured format could slightly improve scannability.
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 tool with 16 parameters and no output schema, the description provides essential context: it explains the accounting semantics, references shared caveats, and gives a concrete validation example. It does not describe the response format or error handling, but the reference to create_sales_invoice for caveats helps fill gaps. The agent would need to consult that sibling for full behavioral detail, so it is not fully self-contained.
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 description coverage is 100% and the schema descriptions are detailed (e.g., billType default, godown auto-fill condition, voucherNumber guidance). The tool description adds no new per-parameter meaning beyond referring to the sales invoice's caveats, so it does not need to compensate. Baseline 3 is appropriate because the schema already documents all parameters thoroughly.
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 states a specific action (create a Credit Note) with a clear resource (item-invoice in TallyPrime) and explicitly differentiates it from create_sales_invoice by the flipped debit/credit convention. It also clarifies it is a Sales return that reverses stock and revenue, making its purpose unambiguous among the many create_* siblings.
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 gives clear usage context: it is for sales returns, references create_sales_invoice for shared caveats, and notes the difference in sign pattern vs sales invoice. However, it does not explicitly state when NOT to use this tool or name alternative return tools (e.g., create_rejections_in) beyond the sales invoice reference, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, and the description adds meaningful behavior beyond them: 'reversing stock and expense,' a live empirical confirmation ('returning 3 units correctly decreased the item's book quantity by exactly 3'), and caveat flags ('godown and dual-role deletion caveats'). The dual-role deletion caveat is only referenced, not explained, which slightly weakens the disclosure, but the description otherwise enriches the bare annotation set.
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?
Four sentences with the core purpose front-loaded; each sentence earns its place (what it does, structural relation to a sibling, live validation, caveat pointers). The empirical-validation sentence is slightly tangential but serves an assurance purpose, so nothing is wasted.
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 17-parameter mutation tool with zeroed annotations and no output schema, the description delivers the essential semantics plus empirical validation, and the schema itself carries exhaustive parameter context. The residual gaps are that the 'dual-role deletion' caveat is punted to another tool's documentation rather than self-contained, and there is no statement about the success/response shape beyond the schema's voucherNumber failure note.
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 description coverage is 100%, and the schema's parameter descriptions are exceptionally rich (billType default contrast, buyerTrn vs supplierTrn asymmetry, voucherNumber auto-number failure workaround), so the baseline of 3 applies. The description's 'same shape as create_purchase_invoice' note adds a useful comparative lens but no parameter-specific meaning beyond what the schema already provides.
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 ('Create an item-invoice Debit Note in TallyPrime') and goes further to define what a Debit Note is in this domain: 'a Purchase return, reversing stock and expense for returned items.' It also distinguishes itself from create_purchase_invoice ('debit/credit convention flipped... structurally a reverse Purchase entry'), which sets it apart from its closest sibling.
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 clear usage context by defining the tool as a purchase-return document and comparing its shape to create_purchase_invoice, including a shared-caveats pointer. However, it never explicitly states when NOT to use it or how to choose between it and create_credit_note, its mirror alternative — the agent must infer the selection rule from the accounting definition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true, so the safety profile is covered. The description adds beyond the structured data by disclosing the output shape ('DSPPERIOD/DSPACCINFO arrays as-is') and the fact that the report is confirmed live, which is meaningful behavior context for the agent.
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?
Two sentences cover purpose, reachability, liveliness, and output shape with no redundancy. The extra implementation detail (Export Data request) slightly lengthens the first sentence but is arguably useful context. Overall it is well-structured and front-loaded.
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 simple date-range read tool with no output schema, the description is sufficient: it states what it returns, the recognized report, and its availability. It could mention error handling or date invalidation, but such details are less critical given the annotation and schema coverage.
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?
Both parameters are fully described in the schema with DD-MM-YYYY format. The description merely restates 'date range' without adding extra meaning. Since schema coverage is 100%, a baseline of 3 is appropriate even though the description adds no parameter-specific details.
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 states a specific verb ('Get') and a specific resource ('Cash Flow statement from TallyPrime') with a date range. It explicitly contrasts against the VAT/GST return reports, differentiating it from sibling report tools. No ambiguity about report type or scope.
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?
It gives clear context: this is Tally's canned Cash Flow report, reachable via a plain Export Data request, and is confirmed live -- unlike the VAT/GST reports. This provides a when-to-use signal and excludes a class of alternatives, even though it does not name sibling tools like get_funds_flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that the result is Tally's native monthly-period breakdown returned as-is, signaling no normalization or aggregation. The 'plain Export Data request' phrasing reassures that no complex operation is involved. Pagination or empty-range behavior could be mentioned, but annotations already cover the safety profile.
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?
Two sentences with no filler; the first sentence carries the core purpose and the second adds behavioral output context. Information is front-loaded and each clause earns its place.
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 two-parameter read-only report tool, the description covers what it is, its scope, the access method, and the expected return shape. No output schema exists, but the description compensates by describing the native monthly-period breakdown. Nothing essential is missing for an agent to invoke it correctly.
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 description coverage is 100%, so both 'from' and 'to' already have format descriptions. The description only adds the notion of a date range, which is already implicit in the schema. Baseline 3 applies because the schema carries the parameter meaning.
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 the specific action ('Get the Funds Flow statement') and resource ('from TallyPrime for a date range'). The note that it is Tally's own canned report helps differentiate it from custom or aggregated report tools among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies this is the standard, direct Export Data route to Tally's Funds Flow report, but does not explicitly contrast it with related siblings like get_cash_flow or state when to prefer one. Some inference is required to choose among the many reporting tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description outlines the output shape (flat array of specific fields) and clarifies that it respects the date range (scoping correctly, unlike a previous buggy version). It does not mention side effects or error handling, but the readOnly annotation already covers safety. The transparency about what it does not return (no details) is valuable, so a score slightly above average is warranted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is heavily padded with irrelevant history about a previous buggy version and the rebuild process. While the key information (purpose, output, alternatives) is front-loaded, the long repetitive explanation about past issues reduces clarity and does not earn its place. It could be shortened by half without losing any essential guidance.
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?
The description covers the essential context: what the tool returns, the filtering mechanism, and when to use alternatives. It does not explain sorting, error scenarios, or pagination, but these are not required for basic invocation. Given the simple nature of a filtered get operation and the provided schema, the description is sufficiently complete.
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?
The schema already provides parameter names and descriptions (from, to with date format). The description adds that the tool is 'filtered by date range,' which clarifies the role of these parameters, but does not go beyond that. Since schema coverage is 100%, the additional semantic contribution is minimal, hence a middle score.
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 clearly states the tool retrieves vouchers (Day Book) from TallyPrime filtered by date range. It specifies the exact verb, resource, and scope, and distinguishes itself from related tools like get_ledger_vouchers and query_sql by noting it returns header-level data only. This makes it unambiguous for an agent.
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?
It explicitly tells agents when to use alternatives: 'use get_ledger_vouchers or query_sql for that' when stock item or ledger line detail is needed. This gives clear decision criteria, leaving no doubt about the appropriate context for this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations establish that this is not read-only and is not idempotent, so the description correctly conveys a mutating operation. It adds the dual create/rename behavior, which is useful, but it does not disclose consequences such as duplicate-name behavior, whether renaming affects related ledgers, or what happens if the parent group is missing.
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?
The description is a single concise sentence that front-loads the core action and immediately clarifies the two operational modes. Every phrase earns its place, with no filler or repetition of already-structured schema details.
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 three-parameter create/update tool with no output schema, the description covers the essential decision point (oldName) and the meaning of parent. It is slightly thin on failure modes and side effects, but the schema plus this description are sufficient for an agent to invoke it correctly in most cases.
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%, so the baseline is 3. The description adds meaning beyond the schema by explaining that 'parent' establishes nesting and that oldName switches the operation to rename/reparent, which directly clarifies parameter usage in context.
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 clearly states the action: creating a new account group nested under a parent, with an explicit alternative mode to rename/reparent an existing group via oldName. It names the specific resource type ('account group in TallyPrime') and distinguishes itself from read-oriented siblings like get_groups and other create_* tools.
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 gives a clear behavioral condition: pass oldName to rename/reparent rather than create a new group. It implies the default use case (new group) but does not explicitly mention alternatives like list groups first with get_groups or use create_stock_group for stock groups, so it is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all neutral false values and carry no safety profile, so the description carries the burden. It discloses the internal nesting structure (VOUCHERCOMPONENTLIST.LIST inside BATCHALLOCATIONS.LIST inside ALLINVENTORYENTRIES.LIST with PARENTITEM back-references), a live confirmation that creation produces no VAT/tax lines and a single balancing party ledger entry, and the voucher-type-active prerequisite. It does not address idempotency/duplicate behavior or the response format, but for a create tool the disclosed traits are substantial.
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 purpose is front-loaded, but the middle section spends several clauses on raw XML tag names (VOUCHERCOMPONENTLIST.LIST, BATCHALLOCATIONS.LIST, PARENTITEM) that an agent never constructs — the input schema already encodes that nesting via items[].components. Key operational facts (orderNumber and dueDate required, voucher-type-active prerequisite) appear late, trailing the reverse-engineering detail. Informative but noticeably padded.
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 high-complexity creation tool with no output schema and uninformative annotations, the description covers the business context, the nested data model, a live creation confirmation, the prerequisite, and the sibling distinction — far more than typical create tools. The main gap is that it never states what a successful call returns or how errors surface; the blank-EXCEPTIONS/voucherNumber workaround lives only in the schema. Minor omission against an otherwise thorough definition.
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 description coverage is 100% and the schema already documents every parameter, including the items/components nesting, godown auto-fill behavior, batchName defaults, and the voucherNumber EXCEPTIONS:1 workaround. The description adds business framing (finished item vs customer-supplied components) and the rationale for required dueDate/orderNumber, but much of that is echoed in the schema, so incremental value is modest — matching the baseline for high schema coverage.
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 opening sentence names a specific verb (Create), a specific resource (Job Work In Order), and the governing business context (this company is the job worker processing customer-supplied raw materials into finished goods). It also explicitly names the sibling it is not (create_job_work_out_order), so an agent can tell them apart without opening either 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?
States the defining directional condition for selection: use when this company is the job worker receiving materials from a customer, and names create_job_work_out_order as the alternative for the opposite direction. It also cites the voucher-type-active prerequisite and the create_sales_order precedent for the required orderNumber/dueDate fields, leaving no ambiguity about when the tool applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=false, the description carries the burden of disclosing mutation behavior and exceeds it: it discloses a prior failure mode ('an earlier version of this tool was found to corrupt the closing balance to a nonsensical negative number'), the fix verification ('counting 95 of an item that had 100 correctly closed the item at 95'), a technical XML detail (DIFFACTUALQTY=Yes at voucher level), and a deliberate non-behavior (no ledger write-off). No contradiction with annotations — readOnlyHint=false aligns with the stated balance mutation.
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 purpose is front-loaded in sentence one and the create_voucher boundary is a clean closing sentence. However, the middle sentence is a ~55-word run-on mixing low-signal implementation minutiae (DIFFACTUALQTY, per-line flag, XML template) with the verification story, which could be split and trimmed. At roughly 95 words, it is informative but denser than necessary for an agent deciding whether to invoke.
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 write tool with readOnlyHint=false and no output schema, the description covers the essential operational facts: what it mutates, the verified behavior, the scope boundary (no monetary posting), and the known failure path is covered in the schema's voucherNumber guidance. The only gaps are the lack of explicit return-value expectations and the missing update_physical_stock contrast — minor given the rich schema carrying the godown and retry edge cases.
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 description coverage is 100%, so the baseline is 3. The schema already documents date format (DD-MM-YYYY), godown auto-fill conditional behavior and failure mode ('the call fails naming the available godowns'), batchName default, and voucherNumber retry logic. The description adds tool-level context but no per-parameter meaning beyond what the schema provides, so it neither needs to compensate nor does it elevate.
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 names a specific verb ('Create') and resource ('Physical Stock voucher in TallyPrime') and defines the core behavior: 'records a physical count and updates the stock item's book quantity to match it (that's the point of the voucher)'. It explicitly distinguishes itself from create_voucher by stating what it does NOT do ('does not post any monetary/ledger write-off'), making sibling differentiation concrete.
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 gives an explicit alternative and condition: 'do that separately with create_voucher if needed' for the shortage/excess write-off. The schema adds a concrete retry path via get_vouchers when creation fails with 'EXCEPTIONS:1' and voucherNumber guidance. However, it never contrasts with the natural sibling update_physical_stock, so when to create vs. update is left to name inference rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses several behavioral aspects: it creates a voucher (write operation), warns about the 'EXTRAPOLATED caveat' and godown requirement, and details a specific failure mode for voucherNumber with a workaround. Given the minimal annotations, this carries the burden well, though it doesn't cover all possible side effects.
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?
The description is concise at ~3 sentences, starts with the core purpose, and efficiently packs the mirror reference, caveat, and error handling without unnecessary fluff. It's well-structured and front-loaded.
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?
Given the complexity (4 top-level params, nested items), the description covers the purpose, typical use cases, and two key error scenarios (date period and voucher numbering). It doesn't mention preconditions like requiring a set company, but that's implied given the TallyPrime context and sibling tools.
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?
The input schema has 100% description coverage, so the baseline is 3. The tool description itself adds no extra parameter semantics beyond what's already in the schema; all parameter details are provided in the schema descriptions.
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 clearly states 'Create a Rejections Out voucher', specifies it records goods being rejected and returned outward, and gives concrete examples (supplier, job worker). The mention of being a 'Mirror of create_rejections_in' helps distinguish it from the sibling tool.
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?
It explains when to use it (rejecting goods going out) and includes specific error handling instructions (calling set_period on date errors). However, it doesn't explicitly contrast with create_rejections_in or other create tools beyond the mirror reference, so it's clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds concrete behavioral detail beyond the annotations: it explicitly says the tool replaces item lines, component lists, party, order number, and narration, which aligns with destructiveHint=true. It references matching/collision caveats from another tool but does not describe them, so it stops short of fully disclosing edge-case behaviors.
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?
The description is two sentences with no filler: the first sentence states the action and its effect, the second sentence points to related tool definitions. It is front-loaded and every word earns its place.
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?
The tool has a complex nested schema but the schema fully documents all parameters, and annotations cover safety. The description handles purpose and replacement behavior well, but it defers 'matching/collision caveats' to update_job_work_in_order rather than explaining them, so an agent must consult another tool definition for a complete picture.
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 description coverage is 100%, and every parameter already has a detailed description in the input schema. The description only notes that voucherNumber is the added field compared to create_job_work_out_order, which does not add substantive meaning beyond the schema.
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 states a specific verb ('Update') and resource ('existing Job Work Out Order'), and details exactly what is replaced: item lines, component lists, party, order number, and narration. It also distinguishes itself from create_job_work_out_order by noting the addition of voucherNumber, making the tool's scope immediately clear.
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 names create_job_work_out_order as the creation counterpart and update_job_work_in_order as the analogous update for in-orders, which helps an agent route between these similar tools. However, it does not explicitly state 'use this when you need to update an existing out-order and not when creating one,' so the guidance is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is known. The description adds meaningful context on top by stating the tool replaces existing item lines and narration, and it references matching/collision caveats from update_material_in. This is valuable beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence front-loads the action and effect, the second efficiently points to related tool definitions. Every word earns its place.
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 mutation tool with full schema coverage and annotations covering safety, the description is nearly sufficient. The only gap is that the matching/collision caveats are not self-contained and rely on the agent consulting update_material_in for full details, but these are referenced explicitly.
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 100%, so all parameters are already documented in the schema. The description adds only a cross-reference to create_material_out and the fact that voucherNumber is included, but no deeper semantic nuance. Baseline 3 is appropriate.
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 states a specific verb ('Update') and resource ('existing Material Out voucher') and explains the exact effect (replacing item lines and narration). It also distinguishes itself from create_material_out by noting it adds voucherNumber, and cross-references update_material_in for matching/collision behavior, so an agent can clearly separate it from siblings.
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 clearly implies when to use this tool: when an existing Material Out voucher must be modified, as opposed to create_material_out for new vouchers. It also mentions 'same matching/collision caveats as update_material_in', which points the agent to relevant alternative behavior, though it doesn't explicitly spell out when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations: it explicitly says 'replacing its item lines and narration', which clarifies destructive action beyond the annotations' destructiveHint. It further mentions matching/collision caveats, pointing to further potential quirks. These directly complement the structured data (readOnlyHint=false, destructiveHint=true) without contradictions.
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?
The description is two compact sentences with no filler. The main purpose is front-loaded, and the subsequent sentence includes two cross-references to related sibling definitions that append useful constraints without redundant detail. Every sentence earns its place.
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?
Given that the tool is part of a large, well-defined sibling family and that the description relies on two existing siblings for field lists and caveats, the description is complete enough for an agent to locate the missing information. The lack of an output schema is offset by the tool's purpose and the explicit statements about what fields are used. There is no mention of authorization or error conditions, but those are generally not necessary for a complete description.
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 100%, so all parameters are described in the input JSON schema. The description adds that the item field replaces all existing lines and that voucherNumber identifies the existing voucher, matching the schema's own description. It references create_rejections_in for field set, but does not add unique parameter-level insight beyond what the schema already provides.
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 clearly states the action as 'Update an existing Rejections In voucher', specifies the resource (TallyPrime voucher) and the effects (replacing item lines and narration). It differentiates from siblings by noting the addition of voucherNumber versus create_rejections_in and by the resource being Rejections In, not Rejections Out or Material In.
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 implies usage: use this tool when updating an existing Rejections In voucher, not when creating one (since it references create_rejections_in). It does not explicitly provide when-not conditions or rule out alternatives, but the distinction is clear. The reference to 'same matching/collision caveats as update_material_in' partially communicates the use context and recourses, but the caveats themselves are not clarified in this description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, and the description adds the crucial specificity of WHAT is destroyed: 'replacing its item lines and narration' — meaning existing lines are not merged but overwritten. The matching/collision caveat reference further flags non-obvious behavior, though the details are deferred rather than disclosed. No contradiction with annotations; idempotentHint=true is consistent with a replace-to-state operation.
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 sentences, zero filler: purpose is front-loaded first, field deltas second, caveat routing third. The 'Same fields as... plus...' and 'Same caveats as...' constructions compactly inherit documentation from sibling tools without repeating it. Every sentence earns its place.
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 4-parameter, fully schema-covered update tool with annotations covering the destructive/idempotent profile, the description is largely sufficient. The main gap is that the matching/collision caveats are only referenced via update_material_in, so an agent lacking access to that sibling's description would miss critical behavior; return/response shape is also unaddressed, though there is no output schema to anchor it.
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 description coverage is 100%, so all four parameters (date, items, narration, voucherNumber) are already documented in the schema. The description adds modest value by clarifying that voucherNumber is the update key ('plus voucherNumber') and echoing the replace semantics that the schema's items description also states. This is the baseline-3 case where schema does the heavy lifting.
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 opening sentence states a specific verb, resource, and scope: 'Update an existing Rejections Out voucher in TallyPrime, replacing its item lines and narration.' It explicitly differentiates from the create twin by noting 'Same fields as create_rejections_out, plus voucherNumber,' so an agent can tell update from create without opening 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?
The qualifier 'existing' clearly implies this is for already-created vouchers, and the reference to create_rejections_out as the field baseline names the natural alternative. The pointer 'Same matching/collision caveats as update_material_in' routes the agent to relevant caveats, though it defers the actual exclusion conditions (e.g., what happens on mismatch) instead of stating them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
All four annotations are false, so the description carries the behavioral burden — and it delivers: it discloses the Order-class voucher classification, the voucher-type-active prerequisite (confirmed live), the live failure mode for missing dueDate, and Auto Retain numbering behavior. The main gap is that some details are cross-referenced ('same reasoning as create_sales_order') rather than self-contained, so the agent must look to sibling definitions for full specifics.
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?
Four sentences, roughly 115 words, with zero filler: definition, sibling differentiation, follow-up workflow, then prerequisites and required fields. It is front-loaded with the most important positioning. The final sentence is slightly dense with stacked cross-references, but every clause earns its place.
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 complex write tool (6 top-level params, 9 item sub-fields) with no output schema and all-false annotations, the description covers the essentials: what the voucher is, where it sits in the workflow, prerequisites, and required fields. What remains unspecified is the success envelope (there is no output schema) and the exact meaning of the referenced Auto Retain numbering behavior, though the schema's voucherNumber note partially compensates.
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 100%, with richly detailed parameter descriptions (godown auto-fill logic, batchName default, the EXCEPTIONS:1 recovery hint on voucherNumber, and dueDate's exact Tally error message). The description re-emphasizes that orderNumber and dueDate are REQUIRED and explains their provenance, which is useful reinforcement but not additive semantic content beyond the schema. Baseline 3 is appropriate.
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 opening sentence defines the tool precisely: 'Create a Purchase Order in TallyPrime — a future commitment to buy, before any goods move or invoicing happens.' It names the verb, resource, and the business moment in the purchase lifecycle, and immediately distinguishes it from siblings by calling out that create_purchase_invoice/create_receipt_note are different 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly routes the agent: same item-line shape as create_purchase_invoice/create_receipt_note but with VCHTYPE 'Purchase Order', plus a sequenced follow-up instruction — 'Follow up with create_receipt_note (goods in) and/or create_purchase_invoice (billing)' once goods arrive. It even cross-references the voucher-type-active prerequisite from create_delivery_note, giving the agent concrete when-to-use and operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is safe. The description adds behavioral context by specifying 'currently open company info', implying session-dependent results, which is useful beyond what annotations provide.
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?
The description is a single sentence of 8 words, perfectly front-loaded with the action and resource. Every word earns its place, with no unnecessary detail.
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?
Given the tool has no parameters, no output schema, and annotations cover safety, the description provides all necessary context for an agent to decide to use it. It clearly communicates the tool's purpose and scope.
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?
The tool has no parameters, so schema coverage is 100% by default. The description adds value by implying the tool returns company information without needing any input, which is appropriate for a parameterless tool.
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 clearly states the verb 'Get' and the resource 'currently open company info', which distinguishes it from sibling getters like get_ledgers or get_stock_items. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when company info is needed, but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like set_company for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the readOnlyHint annotation, disclosing how ledgers are classified (input/output/rcm/other), how matches are detected (structural vs name_pattern), that both signals are used together, that no parent group filter is applied, how netTotal is computed, and the special no-match behavior returning an explicit note instead of zero. This is exceptionally transparent about the tool's behavior and limitations.
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 description is front-loaded with the core purpose and contains genuinely useful behavioral detail, but it is verbose and delivered as one long run-on paragraph. Points like the live-confirmed recall issue and the real-company group scattering are repeated across multiple clauses, which could be consolidated. No structure such as bullets or separate sentences for output shape versus matching behavior is used.
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?
Despite having no output schema, the description explains what each row represents, how rows are classified and tagged, how netTotal is computed, what happens when no ledgers are found, and why this is not Tally's canned VAT report. For a read-only two-parameter report tool, this fully equips an agent to select and invoke the tool correctly.
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?
The input schema fully documents both parameters (from and to) with date format descriptions, so schema coverage is 100%. The description adds 'for a date range' and confirms the period-based query, but it does not add significant new semantic detail beyond what the schema already provides. Since the schema carries the parameter documentation burden, a baseline of 3 is appropriate.
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 specific verb and resource: 'Get a UAE VAT liability summary for a date range.' It clearly identifies the output as reconstructed ledger-based VAT liability, not Tally's canned report, and distinguishes the report type from sibling tools like get_gst_liability_summary through the explicit UAE VAT framing.
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 intended use is clear: call this when a UAE VAT liability summary for a date range is needed. It also provides useful when-not context by ruling out Tally's canned VAT return report and noting that the report is reconstructed from ledger balances like get_profit_and_loss. However, it does not explicitly name alternatives such as get_gst_liability_summary or state conditions for choosing one over another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and idempotentHint=true, and the description builds on them substantially: it discloses that ledger entries and narration are overwritten, that matching is by type + date + number and must be exact, and — most valuably — that the tool refuses on type collisions because Tally's Alter lookup ignores voucher type and can 'silently corrupt the wrong one'. That live-confirmed corruption warning is exactly the kind of behavior an agent cannot infer from annotations or schema. No contradiction with annotations.
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?
Four sentences with zero filler, ordered by importance: core action first, then matching criteria and perequisite, then the two input modes, then the failure mode and remediation. For an 18-parameter destructive tool, every sentence carries distinct operational value.
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 complex, destructive tool, the description covers the critical operational facts: what gets replaced, how the target voucher is identified, the uniqueness requirement, the existence-check prerequisite, both input modes, and the collision refusal with its remedy. The main gap is that it does not route agents among the many update_* siblings (e.g., when to prefer update_sales_invoice over this generic updater), and with no output schema it says nothing about return behavior — a minor gap against an otherwise rich coverage.
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%, so the baseline is 3; the description adds real value on top by explaining the mode split the schema only hints at: debitLedger/creditLedger/amount for simple 2-leg vouchers versus entries for 3+ lines, with mutual exclusivity made explicit. It also elevates the three required parameters (voucherType, voucherNumber, date) into a matching-key constraint, giving them meaning beyond their individual field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — 'Update an existing voucher in TallyPrime' — and specifies the scope of the operation ('replacing its ledger entries and narration'), which clearly separates it from create_voucher and delete_voucher. However, it never explicitly differentiates itself from the many specialized update_* siblings (update_sales_invoice, update_credit_note, etc.), so an agent must infer that this is the generic updater from the voucherType parameter.
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 gives actionable usage context: confirm the voucher exists first via get_ledger_vouchers or get_vouchers, and if the tool refuses on a number collision, resolve it in Tally before retrying. It does not, however, state when not to use this tool in favor of a specialized sibling like update_sales_invoice, so exclusions are left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations provide little behavioral signal because all hints are false, so the description carries the burden. It does this exceptionally well by disclosing a confirmed live side effect: using the same party ledger or stock item in both Sales and Purchase item-invoices can make vouchers undeletable via the API. It also gives a concrete remediation path and clarifies the issue is not permanent.
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?
The description is front-loaded with purpose, then moves to a clearly marked warning section. Every sentence earns its place, especially the warning, which provides confirmed live testing context and a workaround. There is no filler or repetition.
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?
Given the complex 17-parameter surface, the description plus the exhaustive schema cover the tool well and highlight the most critical behavioral caveat. However, with no output schema, the description does not state what a successful call returns or how the agent should confirm the voucher was created, which leaves a small but real completeness gap.
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 description coverage is 100%, and each parameter already has a rich, field-level explanation. The tool description adds useful high-level context about item lines and ledger posting, but it does not add meaning to individual parameters beyond the schema. This matches the baseline for fully covered schemas.
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 clearly states the action and resource: 'Create an item-invoice Purchase voucher in TallyPrime'. It also distinguishes itself from the closely related sibling by labeling it the buying-side mirror of create_sales_invoice, and it adds concrete structural detail about item lines, Purchase ledgers, and a VAT/tax line.
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 provides clear context: this is the tool for purchase-side item-invoices, positioned as the counterpart to create_sales_invoice. However, it does not explicitly state when not to use it or name alternatives like generic create_voucher for other voucher types, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false and carry almost no information, so the description bears the full burden — and delivers. It discloses the voucher-type-activation prerequisite, the visibility quirk ('won't show up in get_vouchers/delete_voucher until it is' active; get_ledger_vouchers will 'never show it, by design'), and two confirmed error-recovery paths (LINEERROR 'Voucher date is missing' → call set_period and retry; blank EXCEPTIONS:1 → set voucherNumber from get_vouchers). This is precisely the behavioral color an agent cannot infer from annotations or schema.
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?
Roughly 170 words, but no sentence is filler: purpose is front-loaded, sibling differentiation takes one clause, and the remainder is operationally necessary caveat (activation prerequisite, ledger-visibility design, date-period recovery, numbering recovery). Slightly dense and could be tightened, but the length is justified for a complex write tool with documented gotchas.
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 13-parameter write tool with no output schema and uninformative annotations, the description covers every realistic failure mode and prerequisite: voucher-type activation, date-period errors, auto-numbering failures, and the get_ledger_vouchers exclusion. The only omission is the success-return shape, which is a minor gap given no output schema and sibling consistency.
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 100%, so the baseline is 3: every parameter already has a substantive schema description (godown's auto-fill vs required behavior, batchName's default, voucherNumber's numbering caveat). The tool description adds voucher-level framing (item-line shape, ISINVOICE=No, no VAT/tax line) but not per-parameter detail, which is appropriate — it does not exceed the schema-driven baseline.
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+resource ('Create a Receipt Note in TallyPrime') and the operational semantics: an 'item-line inventory voucher recording goods received from a supplier before or without a full Purchase invoice'. Explicitly differentiates from siblings — 'Same item-line shape as create_purchase_invoice... but ISINVOICE is set to No and there's no VAT/tax line' — and positions it as the buying-side mirror of create_delivery_note. An agent can distinguish this from every other create_* sibling without opening 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 clear context for when to use it: goods received before or without a full Purchase invoice, e.g. against a Purchase Order. The comparison to create_purchase_invoice (ISINVOICE=No, no VAT line) and the create_delivery_note mirror effectively establish selection criteria, though it stops short of explicitly listing when NOT to use it in favor of other voucher types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the minimal annotation set by disclosing operational caveats: godown behavior, extrapolated XML shape, the LINEERROR date-period failure and its set_period workaround, and voucher-numbering edge cases. It also honestly flags uncertainty about the exact voucher format.
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 longer than average, but every sentence carries operational value: purpose, scope, caveats, and troubleshooting. It is front-loaded with the core definition and then adds necessary behavioral detail.
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 complex write tool with no output schema and sparse annotations, the description covers the key risks an agent needs to know: required godowns, active-period date failures, auto-numbering pitfalls, and the need to verify results. It is sufficiently complete for reliable invocation and error recovery.
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 100%, so the schema already documents the parameters well. The description adds useful context around godown auto-filling and voucherNumber retry behavior, but most parameter semantics are already present in the input schema.
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 clearly states the specific action: creating a Rejections In voucher in TallyPrime. It explains the business scenario (goods rejected and returned by a customer or job worker) and distinguishes it from sales/purchase vouchers by noting it is inventory-movement-only with no party ledger.
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 gives clear context on when to use this tool: when goods are being returned to the company as rejected. It does not explicitly name alternatives like create_rejections_out, but the scenario is specific enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint: false, and the description aligns by stating 'Create a new Stock Group'. It adds context about the relationship to stock items, but does not detail side effects like idempotency or error behavior; annotations already cover the read-only aspect, so the bar is met.
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?
The description is concise—three sentences—and well-structured: it states the purpose, distinguishes from a sibling, and gives a prerequisite. No unnecessary information is included.
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?
The description includes the prerequisite relationship (required before creating a stock item) and clarifies the distinction from account groups. It does not mention the return type or error handling, but given the absence of an output schema, the context is sufficiently complete for an agent to decide when to invoke it.
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?
The input schema provides descriptions for both parameters (name and parent), achieving 100% coverage. The tool description does not add extra semantics beyond what the schema already states, so the baseline score of 3 is appropriate.
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 clearly states the purpose: to create a new Stock Group in TallyPrime. It also distinguishes it from the sibling create_group (account groups) and specifies its role as the category for stock items, making the tool's intent unambiguous.
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?
The description explicitly provides usage conditions: it is required before creating a stock item under a new category, and it contrasts with create_group, giving clear guidance on when to select this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=true, so the description carries the behavioral burden. It discloses classification logic, the structural vs name_pattern tagging, why both signals are used, deliberate exclusions of non-liability ledgers, netTotal sign convention, reconstruction approach, and the explicit no-match note. This is far more than annotations alone provide.
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 almost every sentence adds necessary behavior or rationale for a nuanced accounting tool. It is front-loaded with the core purpose and then builds detail logically. Slightly verbose, but the detail earns its place for correct agent invocation.
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?
There is no output schema, so the description must explain return semantics on its own. It covers row composition, classification tags, exclusions, sign convention, reconstruction approach, and the no-match behavior. For a tool with this complexity, the description is unusually complete.
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 description coverage is 100%, with both from and to documented as start/end dates in DD-MM-YYYY. The description adds that the tool operates over a date range but does not add material semantics beyond the schema. Baseline 3 is appropriate since the schema already fully documents the parameters.
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 an India GST liability summary for a date range.' It goes beyond a generic statement by detailing what rows are returned and how they are classified, making it easy to distinguish from the VAT sibling and other reporting tools.
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 gives strong context for when to use this tool by referencing get_vat_liability_summary as the same design pattern and clarifying that this is rebuilt from ledger balances rather than a canned GSTR export. It does not explicitly state 'use X instead when Y', but the India GST scope and exclusions make the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only 'get' operation, consistent with the readOnlyHint annotation. It adds that the output is a month-by-month summary, providing some behavioral detail beyond the annotation, though it does not mention potential side effects (which are none for a get).
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?
The description is a single sentence that efficiently conveys the tool's purpose, output format, and design reference. It is well-structured and contains no extraneous information.
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 read-only retrieval tool with two parameters, the description is complete: it explains what it returns (month-by-month summary) and the date range context. It does not specify the exact response schema, but that is not necessary given the simplicity and the explicit mention of similarity to get_sales_register.
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?
The input schema fully documents 'from' and 'to' as date strings with explicitly stated format. The description reinforces that these form a date range for the register, enhancing understanding of how the parameters are used beyond the schema's basic descriptions.
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 clearly states the tool retrieves the Journal Register from TallyPrime for a date range, with a month-by-month summary of Journal voucher activity. It distinguishes itself from other register tools by naming the specific voucher type and referencing the similar get_sales_register design.
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 implies when to use this tool (for journal voucher activity) and references a sibling tool for design context, but it does not explicitly contrast with alternatives like get_purchase_register. However, the purpose is clear enough that an agent can select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description's 'Get' wording aligns with that. The description adds useful behavioral context by specifying the return shape ('month-by-month summary') and noting the report's design mirrors get_sales_register. It does not detail exact output fields, but this is acceptable given the simple read-only nature and no output schema.
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?
Two sentences, both essential. The core purpose is front-loaded, and the second sentence provides a focused routing caveat with supporting evidence. No filler or redundant restatement.
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 simple, read-only, two-parameter tool, the description covers what the report is, its shape, and how it relates to nearby siblings. It does not fully enumerate return fields or edge cases, but the reference to get_sales_register's design and the schema's complete parameter docs make this sufficient for correct selection and invocation.
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 100%: both from and to are described as DD-MM-YYYY strings. The description adds only that these form a date range for the report, which is consistent but does not materially enrich parameter understanding beyond the schema.
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 ('Get'), resource ('Payment Register from TallyPrime'), and scope ('for a date range', 'month-by-month summary of Payment voucher activity'). It also distinguishes itself from get_sales_register and get_receipts_and_payments, making its purpose unmistakable.
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 tells the agent when to use an alternative: 'For Receipt vouchers specifically, use get_receipts_and_payments instead.' It also explains why, citing a live confirmation that no standalone Receipt Register is reachable this way. This removes ambiguity about sibling tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so no contradiction exists. The description adds useful behavioral context beyond that: the report is Tally's canned combination view, and the attempt to use the native Cash Book/Bank Book reports fails live with 'Could not find Report.' It stops short of describing response shape or pagination, but for a read-only report this is a solid disclosure.
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 first sentence is front-loaded and clear. The subsequent sentence is long and contains nested caveats, including a quoted error message, but it earns its place by preventing wasted calls to unreachable reports. It could be tightened, but the structure is still reasonably efficient.
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?
The tool has only two required date parameters, the schema fully documents them, and the read-only annotation covers safety. The description explains what the report contains, why it is the closest reachable equivalent to a Cash/Bank Book, and which sibling to use for a single ledger's history. No output schema exists, but the report's nature is sufficiently described for correct selection and invocation.
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 description coverage is 100%, with both required parameters (from, to) documented as DD-MM-YYYY dates. The description adds only that the tool works 'for a date range,' which is already implied by the schema. It provides no additional semantic detail, so the baseline of 3 is appropriate.
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 specific verb and resource: 'Get the Receipts and Payments report from TallyPrime for a date range.' It clearly defines the report as a cash/bank-ledger-wise view of Receipt and Payment activity, and distinguishes it from get_ledger_vouchers and the unreachable Cash/Bank Book reports. An agent can readily tell what this tool does and how it differs from nearby siblings.
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?
The description explicitly names an alternative for single-ledger history: 'for a single cash or bank ledger's own transaction history instead, use get_ledger_vouchers with that ledger's name.' It also warns that Tally's actual Cash Book/Bank Book menu reports are not reachable via a plain Export Data request, so the agent knows when this report is the best available substitute.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations only carrying generic flags (write, not idempotent, not destructive), the description takes on the behavioral burden and delivers substantive details: Tally classifies Sales Quotation as an Order-class voucher ('PARENT Sales Order'), and Tally 'rejects it the same way' without orderNumber and per-item dueDate. It also discloses the voucher-type-active prerequisite. It stops short of describing success-path behavior, but the disclosed failure modes are the operative risks for this tool.
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?
Three sentences, front-loaded with the core purpose and scoped against the sibling. The middle sentence is dense but packs the substantiated requirements and the confirmed-live rationale. Minor redundancy across 'Same ... same way ... Same' is a small cost for the behavioral precision it buys.
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 6-parameter create tool with 100% schema coverage and no output schema, the description covers workflow position, prerequisites, and rejection behavior, while the schema fully documents every parameter. Success-return behavior is not described, but with no output schema and the failure mode disclosed, nothing critical is missing for this tool's complexity.
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%, so the baseline is 3. The description adds meaning beyond the schema by explaining why orderNumber and per-item dueDate are non-negotiable — grounded in Tally's Order-class voucher classification — rather than merely restating that they are required. The cross-reference to create_sales_order's 'same item-line shape' also lets the agent transfer known parameter semantics from a sibling.
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 uses a specific verb ('Create') and resource ('Sales Quotation in TallyPrime') and immediately distinguishes the tool from its closest sibling: 'one step before create_sales_order.' Combined with the follow-up note, an agent can unambiguously separate this tool from create_sales_order, create_sales_invoice, and update_sales_quotation.
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?
The description explicitly positions the tool in the sales workflow — 'one step before create_sales_order' — and names the exact follow-up action: 'Follow up with create_sales_order once the customer accepts.' It also anchors a prerequisite to a named sibling ('Same voucher-type-active prerequisite as create_delivery_note'), giving concrete when-to-call and when-to-stop guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries the burden; it does disclose real behavioral traits: Tally's numbering series can silently restart (with a concrete example), the entries path is pre-validated so double-entry mismatch fails with a clear error before reaching Tally, and buyerTrn/buyerState/buyerCountry behave differently for Sales-class vs Purchase-class vouchers. It stops short of describing the full response shape or other failure modes, which is why it is a 4 rather than a 5.
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 longer than the average tool description, but nearly every clause earns its place: it compresses the 2-leg vs multi-line distinction, the numbering failure workaround, and a cross-tool pointer into roughly three dense sentences. It front-loads the core action and the mode choice before the edge-case voucherNumber caveat. It could be tightened slightly, but it is structured and information-dense rather than redundant.
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 22-parameter mutation tool with no output schema, the description does an unusually complete job: it explains when to use entries, when to override numbering, what the double-entry constraint is, how reference relates to bill-wise settlement, and which Sales-class caveats apply to buyerTrn/buyerState/buyerCountry. What is missing is mostly what an agent would learn from the output schema or from trying the tool (e.g. exact response format, whether the call fails synchronously), so the gap is not a description failure.
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 description coverage is 100%, so the baseline is 3; the description earns the extra point several ways. It clarifies the mutual exclusivity between entries and debitLedger/creditLedger/amount, explains that entries replaces the simple mode entirely, adds the real-world voucherNumber auto-numbering caveat, distinguishes reference (voucher-level REFERENCE) from per-leg bill references (debitBillName/creditBillName), and gives a working example for reference. These go well beyond restating the property names.
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 specific verb phrase 'Create a new voucher ... in TallyPrime', enumerates concrete voucher types (Payment, Receipt, Sales, Purchase, Journal), and immediately differentiates the two supported modes (simple 2-leg vs multi-line entries). This clearly distinguishes it from create_sales_invoice, create_purchase_invoice, update_voucher, and the other sibling create_* tools.
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?
The description gives explicit when-to-use guidance: use debitLedger/creditLedger/amount for a simple 2-leg voucher, use 'entries' for 3+ lines, and pass voucherNumber only when Tally's auto-numbering misbehaves, with a concrete live example. It also directs the agent to check get_vouchers for the correct next number first, and points to create_purchase_invoice's separate buyerTrn/supplierTrn when the purchase-class caveat applies. This proactively routes to alternatives and even warns against misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true), the description discloses two confirmed behavioral caveats: the race condition when deleting a master and its voucher in the same batch, and the permanent 'Cannot be deleted!' scenario that requires a Company Data rewrite in Tally. These are rich, operationally critical details that annotations alone do not capture.
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?
The description is two sentences and front-loaded with the primary purpose, then followed by a high-value operational warning. There is no filler or unnecessary repetition, and the additional clauses all contribute useful context.
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 destructive, multi-type deletion tool without an output schema, the description covers the essential use case: general usage, sequencing with vouchers, known race condition, a specific permanent error, and the Tally-side fix. It provides enough operational context to use the tool safely and to understand what can go wrong.
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?
The input schema describes both parameters in detail, including the collection of XML tag names and the exact names array; schema coverage is 100%. The description restates examples of master types but adds no new information about parameter formats, constraints, or behavior beyond the schema.
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 explicitly states the action: 'Delete one or more masters (ledger, group, stock item, voucher type, unit, godown, cost centre, etc.) by name.' It names both the verb and the resource scope, and it distinguishes this generic deletion tool from sibling tools like delete_stock_item and delete_voucher which are type-specific.
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 provides concrete usage guidance: delete a voucher first and confirm success before deleting the related master, and avoid parallel batch execution to prevent a race. It also explicitly states that a certain permanent deletion failure should be handled with a Tally rewrite, not retry or sequencing. However, it does not explicitly say 'use delete_stock_item instead for stock items' or otherwise contrast with the sibling delete tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior, but the description adds substantial context: failure conditions, race-condition warning, and a specific error with a resolution (Company Data → Rewrite). This goes far beyond annotations, revealing realistic edge cases and constraints.
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?
The description is concise yet information-dense. It opens with the core action, then lists failure conditions, sequencing advice, and a known workaround—all within four sentences. Every sentence provides actionable value without redundancy.
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?
Despite having no output schema, the description covers all critical aspects: success/failure conditions, concurrency concerns, and a known permanent failure with a manual fix. Given the tool's destructive nature and potential for confusion, the description is fully complete for an agent to use it correctly.
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?
The input schema fully documents the single parameter 'name' with its description 'Exact name of the stock item to delete' (100% coverage). The description does not add additional parameter detail, but it does imply the need for exactness by stating deletion behavior. This meets the baseline for high schema coverage.
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?
Description clearly states the action: 'Delete a stock item from TallyPrime' with a specific verb and resource. It distinguishes itself from sibling tools like delete_voucher and delete_master by explicitly targeting stock items, making its purpose unambiguous.
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?
Provides explicit conditions for use, such as failing when transactions exist, and sequencing advice to delete vouchers first to avoid races. It also mentions a known failure scenario and suggests a manual fix. While it doesn't explicitly name alternative tools for other resource types, the context is sufficient for proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds valuable behavioral context by noting it is a canned Tally report reachable via a plain Export Data request and that the output is a month-by-month summary. This exceeds what annotations alone provide.
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?
The description is two sentences with no filler. The core purpose is front-loaded, and the differentiation from sibling tools is concise and actionable.
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 simple read-only report tool with two fully documented parameters, the description provides the report type, its monthly-summary nature, and clear pointers to alternatives. Nothing essential is missing for an agent to select and invoke this tool correctly.
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?
Both parameters are fully documented in the schema with date format DD-MM-YYYY, so schema coverage is 100%. The description mentions a date range but adds no new meaning beyond the schema; the baseline of 3 is appropriate.
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 clearly identifies the tool as retrieving TallyPrime's Sales Register, specifies the date-range scope, and clarifies that it returns a month-by-month summary of Sales voucher activity. It also explicitly distinguishes itself from get_vouchers and get_ledger_vouchers, which provide individual voucher line detail.
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?
The description states when to use this tool (for the monthly Sales Register summary) and explicitly directs users to get_vouchers or get_ledger_vouchers when individual voucher line detail is needed. This is strong routing guidance that prevents misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries the behavioral burden and it delivers: 'Confirmed live: creates cleanly with no exceptions' is genuine operational insight, and the voucher-type-active prerequisite warns of a realistic failure mode. The voucherNumber parameter description also discloses the known auto-numbering outage and the get_vouchers retry strategy. No contradiction with annotations — readOnlyHint=false is consistent with a create operation. Minor gap: no statement about what the response returns on success beyond 'no exceptions.'
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?
Dense but purposeful — every sentence earns its place (scenario, mirror relationship, direction convention, live confirmation, prerequisites, required fields). Slightly redundant in explaining the accounting direction twice ('flipped' and 'inward expected receipt rather than outward delivery'), but the front-loading of core purpose before structural details is well ordered.
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 complex nested creation tool with no output schema and minimal annotations, the description covers every decision-relevant aspect: when to use it, how it relates to siblings, the nested item/component structure, prerequisites, required fields, and a confirmed-live status. Even the schema's nested-object complexity (which the context signal under-reports) is explicitly explained in the description, so nothing an agent needs to invoke 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%, so the baseline is 3 and the schema already documents every parameter well. The description adds value above the schema by framing the conceptual mapping: each item line is the finished item expected back, while the nested components list is the raw materials to send out. This clarifies the semantics of the whole items array in business terms that the flat schema properties alone don't convey.
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 ('Create a Job Work Out Order in TallyPrime') with a precise business scenario: this company is the principal sending raw materials to a job worker and expecting finished items back. Explicitly differentiates from its near-twin sibling create_job_work_in_order by calling it the mirror image with the accounting direction flipped, so an agent can distinguish them without opening either 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 when-to-use guidance: 'used when this company is the principal, sending raw materials out to a job worker (subcontractor) and expecting a finished item back.' Names the alternative (create_job_work_in_order) and the direction relationship via the existing create_sales_order vs create_purchase_order sign convention, which lets an agent generalize from sibling pairs it may already understand. Also states the voucher-type-active prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations: it reveals that this is a memorandum posting without real accounting impact, that it uses Tally's 'Multi Consumption Voucher View' shape, that the template is extrapolated and unverified, and that users should verify carefully. It also documents a known failure mode (LINEERROR 'Voucher date is missing') and the exact remedy (set_period + retry). This is rich behavioral disclosure beyond the readOnly/destructive hints.
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?
Every sentence earns its place: the first defines the tool, the next gives the job-work context and caveat, then the godown warning, then a concrete troubleshooting path. It is long but information-dense, front-loaded with the core purpose and structured so the warnings and error handling are easy to locate.
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?
No output schema exists, and the description doesn't describe the success response, but it does cover the most important operational context: prerequisites (party ledger, items, date), conditional requirements (godown), and failure recovery (set_period, voucherNumber fallback). For a creation tool, error modes are as important as success output, and those are thoroughly covered; only a brief note on expected success behavior is absent.
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%, so each parameter already has a description. The tool description adds value on top by advising to 'pass godown on every item' when godown/batch tracking is enabled, and by explaining the voucherNumber auto-numbering caveat and the EXCEPTIONS:1 retry strategy. This supplements the schema rather than repeating it.
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 specific verb and resource: 'Create a Material In voucher in TallyPrime' and immediately defines its exact purpose: recording stock received back from a job worker or party holding material, with the key distinction that it is job-work memorandum tracking, not a purchase. This differentiates it clearly from purchase vouchers and other sibling tools like create_material_out or create_rejections_in.
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 gives strong contextual guidance: it explains when this voucher type is appropriate (job-work returns, non-purchase tracking) and explicitly flags when to be cautious (godown/batch companies, active-period issues). It does not name specific alternative tools for explicit when-not-to-use, but the 'not a purchase' statement and the job-worker framing provide enough direction for an agent to select it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false and destructiveHint=false, which is thin; the description carries the full burden and delivers exceptional value. It discloses a confirmed-live behavioral hazard — vouchers becoming undeletable via API when shared party/stock items are used across Sales and Purchase invoices — plus the exact recovery path (Company Data → Rewrite) and the confirmation that it is not a permanent lock.
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 sentences, zero filler, and the core purpose is front-loaded before the sibling distinction and the warning. The warning is long but every word earns its place — it conveys a live-confirmed failure mode and its workaround, which is exactly the kind of content that must not be trimmed.
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 16-parameter mutation tool with no output schema, the description covers core function, sibling differentiation, and the critical lock hazard; the schema covers every parameter exhaustively. The only gap is that no explicit success-return shape is stated, though the schema's CREATED:0/EXCEPTIONS:1 hints let an agent infer the Tally gateway response pattern.
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 description coverage is 100%, so the schema already documents all 16 parameters in rich detail (including failure modes like the godown silent fail), putting this at the baseline 3. The tool description adds mild structural meaning — per-line salesLedger vs. one VAT line on the total — but does not meaningfully compensate beyond what the schema already provides.
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 ('Create an item-invoice Sales voucher in TallyPrime') with concrete detail about what it produces: stock item lines with quantity/rate, each posted to its own Sales ledger, plus an optional VAT/tax line. It explicitly names the confusable sibling and its limitation ('Distinct from create_voucher, which only supports plain ledger-to-ledger entries with no stock items'), so an agent can tell it apart without opening schemas.
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 an explicit when/hen-not: use this for item-invoices with stock item lines, and names create_voucher as the alternative for plain ledger-to-ledger entries. The live warning about the same party/stock item appearing in BOTH a Sales and Purchase item-invoice also implicitly guides when NOT to combine this tool with create_purchase_invoice on the same masters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the minimal annotations, the description discloses detailed behavior: the dual create/rename mode, the effect of numberingMethod, the real-world issue of blank voucher numbers if not set, the relationship of useAsManufacturingJournal to Stock Journal, and the escape hatch of extraFields. This is far more transparent than typical tool descriptions.
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 and wraps many caveats into a single flowing paragraph, which can be a bit dense. However, every sentence delivers important operational knowledge, and the main purpose is stated upfront. It is appropriately detailed for the complexity of the operation, though slightly more structured formatting would improve readability.
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?
The description thoroughly covers the operation's semantics, edge cases, and relationships to other tools (e.g., create_stock_journal). It does not mention the return value or error behavior, but for a create/rename tool with no output schema, the focus on input-side behavior is arguably sufficient. A brief note on what it returns would make it fully complete.
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?
Every parameter has a schema description, and the narrative adds critical nuance for many of them: numberingMethod values and consequences, oldName for renaming, parent needing to exist, extraFields as an unvalidated escape hatch, and useAsManufacturingJournal's actual impact. This exceeds what the raw schema provides.
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 clearly states the tool's primary action ('Create a new custom Voucher Type') and extends to renaming/reconfiguring existing ones, which is a distinct scope. It differentiates from sibling tools by focusing on the Voucher Type master object and references the need to check get_voucher_types for valid parents.
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 provides explicit usage guidance: it tells the agent to check existing voucher types via get_voucher_types, explains when to pass oldName to rename vs. create, and warns about numberingMethod pitfalls. It stops short of an explicit 'use this instead of X' comparison with sibling tools, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true and openWorldHint=false; the description adds substantial behavior beyond that: the tool filters the raw Tally report down to only reorder-configured rows, with concrete live evidence (a 10,770-item company producing a ~1.4MB all-null dump). It also discloses the empty-rows-with-note return convention, which is exactly the kind of edge-case behavior an agent needs to know.
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?
Purpose is front-loaded in the first sentence, and the sibling routing comes last, which is a sensible order. The middle sentence is long, and the live anecdote adds credibility but could be trimmed; still, every sentence contributes new information, so it earns a 4 rather than a 3.
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 2-parameter read-only tool with no output schema, the description compensates thoroughly: it lists the row fields, explains the filtering behavior, defines empty-result semantics, and routes to the appropriate alternative. Nothing an agent needs to call the tool correctly is missing.
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 description coverage is 100% with both from and to documented as DD-MM-YYYY dates, so the baseline of 3 applies. The description only adds that the report spans 'a date range,' which mildly reinforces parameter intent but provides no format or constraint detail beyond what the schema already gives.
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 ('Get'), a specific resource ('Reorder Status report from TallyPrime'), and the exact scope ('stock items with a reorder level configured, and where their current quantity stands against it'). It also enumerates the per-row fields returned, so an agent knows precisely what this tool produces.
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 tells the agent when this tool is the right choice versus a sibling: 'use get_stock_summary for a plain quantity view of every item regardless of reorder setup.' It also defines when an empty result is a legitimate outcome ('no items have a reorder level configured at all'), preventing the agent from misreading a valid empty response as an error.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true and openWorldHint=false, yet the description discloses far more non-obvious behavior: 15-minute expiry, single-use semantics, safety checks running at preview time so refusals are already reflected, and per-preview-type side effects (create_* makes no gateway call; update_*/delete_* only makes a read-only collision-check query). It also clarifies the read-only-mode interaction — preview_write still works while confirm_write is blocked — all consistent with the readOnlyHint.
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 (~200 words) but front-loaded with the critical scoping fact ('nothing is touched') and nearly every sentence earns its place — return contract, use case, safety-check timing, expiry, read-only behavior. It could be slightly tightened (e.g., 'or just don't confirm it if it's wrong' is mildly redundant after the expiry/single-use statement), yet the density is high for a tool with this much behavioral nuance.
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 carries the burden of explaining return values and does so explicitly (previewId, plain-English description, raw XML). It covers the full lifecycle — preview, human review, confirm via confirm_write, or let expire — along with validation behavior at preview time and the read-only-mode exception. Nothing an agent needs to call this meta-tool correctly is missing.
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?
Both parameters are already fully documented in the schema (100% coverage): toolName lists accepted tools with examples and explicit exclusions, and args says 'the exact same arguments you'd pass to that tool directly.' The description adds that args undergo safety checks at preview time but offers no new value-level semantics, so the high-coverage baseline of 3 applies.
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 — 'Build the exact XML for any write tool WITHOUT sending it to Tally — nothing is touched' — and immediately distinguishes itself from both the direct create_*/update_*/delete_* tools and confirm_write by positioning itself as a preview-only step. The stated return contract (previewId, plain-English description, raw XML) makes the function's role unambiguous.
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 instructs 'Use this instead of calling a create_*/update_*/delete_* tool directly whenever you want a human to review a batch of changes first,' backed by a concrete costly-error scenario (drafting vouchers from client documents). It also names confirm_write as the required follow-up to post and notes that not confirming is a valid outcome, giving the agent a complete decision path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the readOnlyHint annotation: it warns the cache is session-scoped and disappears when the session ends, reports that sync tables are only populated by explicit sync calls, and discloses that set_company empties every SQL table when the active company changes. This prevents an agent from silently querying stale or cross-company rows. The readOnlyHint=true annotation is consistent with the read-only SELECT description.
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 dense but front-loaded with the most important behavior: read-only, in-memory cache. Each clause about table population and lifecycle earns its place, though the long table-schema listing and the trailing set_company detail make it longer than strictly minimal. It is informative without being padded.
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 query tool with one parameter and no output schema, the description covers the full lifecycle: what is in the cache, how each table gets populated, which data can be derived without a separate report tool, and what invalidates the data. The agent has enough context to decide when to call it, what to run, and what to expect after session/company changes.
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?
The input schema already fully documents the single 'sql' parameter as 'A single SELECT statement' (100% schema description coverage). The description adds useful table context but does not add much parameter-level semantic detail such as syntax restrictions, limits, or examples. Baseline 3 is appropriate because the schema carries the parameter-documentation burden.
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 crisp specific action — 'Run a read-only SQL SELECT query against this session's in-memory cache' — and immediately distinguishes it from the report getter siblings. Listing the exact tables and how they are populated removes ambiguity about what this tool can query.
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?
The description explicitly explains when to use query_sql vs the domain get_* report tools: after a report call, a follow-up question can query the refreshed table here instead of re-fetching from Tally. It also tells the agent when NOT to rely on it — the five report tables only hold the most recent call's data, and re-calling the report tool is needed for a different period. This is strong routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true and idempotentHint=true, but the description goes further: it states this tool 'does not affect stock or post anything by itself', clarifies that scaling is NOT auto-computed, and warns about being extrapolated from an XML template, advising verification. This adds significant behavioral detail beyond 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?
The description is longer than minimal but every sentence earns its place: purpose, mechanism, limitation, and caveat are all covered. There is no fluff, though it could be slightly tightened without losing essential information.
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 mutation tool with destructive hints and no output schema, the description thoroughly covers what the tool does, its side effects (or lack thereof), the required companion call, and a verification warning. An agent has enough context to use it correctly and safely.
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%, so the schema documents all parameters. The description adds meaning by explaining that components should be scaled by the ratio to basicQty (and you must do this yourself), and flags caution about natureOfItem's accepted values. This goes beyond schema definitions.
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 states a specific verb and resource ('Attach a Bill of Materials to an existing finished-goods stock item') and clearly distinguishes it from create_stock_journal by calling it a convenience layer. The purpose is unambiguous and not a tautology.
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?
It explicitly explains when this tool is used (to set up a fixed-ratio recipe) and that you 'still call create_stock_journal to actually record a production run', which guides the agent toward the correct companion tool. It doesn't list exclusion criteria (e.g., when not to use), but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation (which aligns), the description discloses critical behavioral details: qty/amount are unsigned, requiring is_deemed_positive and voucher_type for direction; non-stock vouchers yield zero rows; chunked/additive model with timeout caution; and cache does not track company origin. These are non-obvious traits an agent must know, adding substantial value over 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?
The description is long but front-loaded: it opens with the core action and fields, then progressively adds usage, data semantics, edge cases, and caveats. Every sentence adds value; the length is justified by the tool's complexity. It could be slightly tightened, but the structure is logical and no filler exists.
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?
Given there is no output schema, the description compensates by specifying the row structure (one row per item per batch allocation, fields: stock item, qty, rate, amount, godown, batch), the is_deemed_positive/voucher_type nuance, zero-row behavior, and company-switch caveat. It also ties into the broader sync/query workflow. Nothing an agent needs to call it correctly is missing.
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 100% with both from and to documented as 'Start/End date in DD-MM-YYYY format'. The description merely refers to 'date range' without adding format or semantic details beyond the schema. It does not elaborate on edge cases like inclusive/exclusive boundaries. Per the baseline for high coverage, a 3 is appropriate; no extra meaning is added.
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 clearly states the tool pulls voucher inventory line items (with specific fields listed) into the SQL cache for a date range. It distinguishes itself from sync_vouchers_to_sql and query_sql by explaining it is the raw data source for movement/godown/batch analysis, which are not available as report tools. The verb 'pull' and resource are explicit.
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?
The description explicitly states when to use this tool: 'so query_sql can compute movement analysis, godown-wise stock, or batch detail directly.' It also explains what not to use it for (replicating unavailable reports) and gives concrete advice on chunking ('quarterly/monthly chunks for a busy company') and company switching ('sync again'). It even references the sibling sync_vouchers_to_sql for the same model.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly explains the read-only nature (pulling data), the in-memory session cache behavior, and the implications of session scope and company changes. It adds context beyond the readOnlyHint annotation, such as cache lifecycle and timeout handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively verbose and repetitive, with multiple warnings and instructions (e.g., 'call this once per chunk', 'pick a chunk size that won't time out', repeated mentions of session/company scope). It could be significantly condensed while retaining essential information.
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?
Despite verbosity, the description is very complete: it explains the tool's purpose, usage patterns, alternatives, constraints, and interaction with session state. It covers all key aspects needed for correct usage, including edge cases like company switches and timeout management.
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?
The input schema already covers 100% of parameters (from and to) with format descriptions. The description adds context about chunking and timeouts based on date range, which is useful for effective parameter selection.
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 explicitly states it pulls voucher headers for a date range into a SQL cache for querying, distinguishing it from sibling tools like get_vouchers and sync_voucher_items_to_sql. The verb 'pull' and resource 'voucher headers' are clear and specific.
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?
The description provides explicit usage guidance: when to use it for aggregation/reporting, how to chunk data to avoid timeouts, when to re-sync after a company change, and how it differs from alternatives like get_ledger_vouchers and sync_voucher_items_to_sql. It also states the safe re-run behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the annotations: the date + voucher number matching semantics, the refusal-on-collision safety mechanism, and a live-confirmed failure mode ('Tally's Alter lookup ignores voucher type and can silently corrupt the wrong one'). This is exactly the kind of hard-won behavioral context a destructiveHint annotation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place: action and scope, field parity with the sibling, matching plus prerequisite lookup, and failure mode plus recovery. The most important fact is front-loaded, and the longest sentence carries a genuinely critical caveat rather than filler.
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 update with six parameters and a nested items/components structure, the description covers replacement scope, identity matching, prerequisite verification, collision refusal, and recovery. With no output schema, the only gap is that the success/return behavior is never described.
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%, so the schema already documents all six parameters thoroughly. The description still adds value by identifying date + voucherNumber as the identity key used for matching — a semantic the schema does not state — and by cross-referencing the create variant's field set for agents that already know it.
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 ('Update an existing Job Work In Order in TallyPrime') and precisely scopes what gets replaced: item lines, component lists, party, order number, and narration. The field-parity note ('Same fields as create_job_work_in_order, plus voucherNumber') explicitly differentiates it from the create sibling.
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?
Provides explicit routing guidance: run get_ledger_vouchers or get_vouchers first to confirm the voucher exists and is unique, and resolve collisions in Tally before retrying. The create-vs-update distinction is strongly implied (the word 'existing' plus the reference to create_job_work_in_order) but never stated as an explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description discloses real behavioral risk: 'Tally's Alter lookup ignores voucher type and can silently corrupt the wrong one' and that the tool 'Refuses if another voucher type shares the same number on that date.' This is exactly the kind of non-obvious, high-stakes behavior an agent needs to know before invoking a destructive update.
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 dense sentences with no filler. The primary action is front-loaded, followed by the key distinction from create_stock_journal, then the critical look-up precondition and failure mode. Every sentence earns its place and the most important safety information comes at the end without being buried.
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?
The description covers the matching strategy, required preconditions, and a dangerous collision scenario, which is substantial for a complex update tool. However, since there is no output schema, a brief note about what the tool returns (e.g., success confirmation or updated voucher details) would make it fully complete. Minor gap only.
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 description coverage is 100%, so the baseline is 3. The description adds value by explaining the composite matching key: 'Matched by date + voucher number,' which gives semantic meaning to date and voucherNumber beyond their individual schema descriptions. It also reinforces that voucherType must match the original type for the lookup to succeed, which is useful parameter relationship guidance.
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 specific verb and resource: 'Update an existing Stock Journal voucher in TallyPrime', and specifies the exact scope: 'replacing its source/destination lines and narration.' It also differentiates from the likely sibling create_stock_journal by stating 'Same fields as create_stock_journal, plus voucherNumber,' so an agent can immediately distinguish update from create.
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?
It gives explicit preconditions: 'use get_ledger_vouchers or get_vouchers first to confirm it exists and is unique.' It also tells the agent what to do on collision: 'resolve the collision in Tally first.' It does not explicitly state when-not-to-use this tool or name alternative update tools like update_voucher, but the context is clear enough for correct routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries the full burden of behavioral disclosure, and it delivers excellently. It reveals two confirmed live gotchas: the voucher type must be active or the API falsely reports CREATED:1, and auto-numbering can silently fail with a blank EXCEPTIONS:1. It also explains the workaround (pass voucherNumber explicitly), and that get_ledger_vouchers deliberately excludes inventory-classified vouchers. This is high-value behavioral information far beyond 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?
The description is long but front-loaded: purpose first, sibling distinctions second, then critical warnings. Each sentence carries evidence-backed context, though there is minor redundancy — the voucherNumber guidance appears both in the tool description and in the schema's voucherNumber property. The structure is logical and the density is justified for a tool with multiple live-confirmed failure modes.
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 12-parameter creation tool with no output schema and all-false annotations, this description is unusually complete. It covers prerequisites (voucher type active), failure modes (auto-numbering), exclusions (get_ledger_vouchers), and workarounds. The only gap is that it doesn't fully describe the success response shape beyond mentioning CREATED:1 and EXCEPTIONS:1 status markers. That minor omission keeps it from a 5.
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?
With 100% schema description coverage, the baseline is 3. The tool description adds meaningful context beyond the schema: it explains the item-line shape shared with create_sales_invoice (including godown auto-fill behavior), and details the voucherNumber parameter's role in recovering from silent auto-numbering failure. It also notes buyer details fields map to the same block as Sales/Credit Note. These enrich the schema without repeating it.
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 precise definition: 'Create a Delivery Note in TallyPrime — an item-line inventory voucher recording goods dispatched to a customer before or without a full Sales invoice.' It names the verb, resource, and the exact scenario, then distinguishes it from create_sales_invoice and create_rejections_out. An agent can determine exactly what this tool does and how it differs from siblings.
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?
It explicitly states when to use this tool: for dispatching goods before/without a full sales invoice, with ISINVOICE set to No and no VAT/tax line. It also names alternatives: 'Distinct from create_rejections_out, which has no party/ledger amount at all,' and warns that get_ledger_vouchers will never show this voucher by design. This is clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotations being false, the description carries the full behavioral burden and does it superbly. It discloses the confirmed live pattern for compound units, the client-side whitespace validation that Tally rejects ('Master name contains invalid characters'), and the fact that decimalPlaces is ignored for compound units. This goes well beyond 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?
The description is a single long paragraph, but every sentence adds necessary information about simple vs. compound units, prerequisites, validation, or failure modes. The key usage requirement is front-loaded. It is dense rather than bloated, but it could benefit from clearer separation of the compound-unit-specific rules.
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 6-parameter tool with a complex compound-unit semantics, the description is complete: it explains the creation process, dependency chain, validation constraints, and when the tool is required. The absence of an output schema is acceptable for a creation tool, and the description provides everything an agent needs to invoke 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?
Even with 100% schema coverage, the description adds critical semantic meaning: it explains how baseUnit/additionalUnit/conversion work together only for compound units, that conversion is required when baseUnit is set, that decimalPlaces defaults to 0, and where whitespace is allowed (symbol vs. display name). This would not be obvious from the schema alone.
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 clearly states the tool creates a 'Unit of Measure in TallyPrime' and distinguishes simple units (e.g., 'Kg') from compound units (e.g., 'Box of 12 Nos'). This specific verb-resource pair sets it apart from sibling tools like create_stock_item or create_group without needing to inspect schemas.
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 says when to use it: 'Required before creating or invoicing a stock item in a unit that doesn't exist yet' and describes the failure mode otherwise. It also gives a sequencing pattern (create simple units first, then compound), but it never explicitly names an alternative tool because none exists for this operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses retention behavior (90-day deletion checked once per startup), best-effort company tagging, that all read and write calls are logged, and outcome categories. This is substantial behavior context the annotations do not provide.
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?
The description is front-loaded with the core purpose, followed immediately by the critical retention caveat and typical use cases. Every sentence adds needed context and none are redundant or ornamental.
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 seven parameters and no output schema, the description still tells an agent what entries contain, how outcome and company are represented, what the retention limits are, and when to use the summary format. No critical call-time decision is left unexplained.
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 description coverage is 100%, so the schema already documents every parameter. The description contributes marginal context such as the purpose of writesOnly and best-effort company tagging semantics, but the baseline of 3 is appropriate since the schema carries the main parameter burden.
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 states a specific verb and resource: read the connector's append-only audit log. It enumerates the content of entries (timestamp, arguments, outcome, company tag), making the tool's purpose concrete and distinct from all sibling getters and mutation tools.
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?
The description explicitly says when to use this tool: to review what an agent actually did against the Tally company, before trusting a session's claimed results, or to hand a reviewer a record of writes. It also gives a when-not by warning this is not a full historical record beyond 90 days.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already convey read-only safety, so the description's extra context—what the health check covers and that it reflects the current live state—adds real value beyond the structured fields. It clearly describes the diagnostic nature without contradicting readOnlyHint. It stops short of explaining failure modes or output shape, but the essentials are covered.
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?
Two compact sentences, with the core purpose front-loaded and the usage guidance following. Every clause adds distinct value: what the tool checks, when to call it, and what mistake it prevents. No 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?
For a zero-parameter health check, the description fully covers what the agent needs: the nature of the check, the exact information it reveals, and the circumstances in which it should be used. There is no output schema, but the listed health attributes give enough clarity about what to expect.
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?
The tool has zero parameters, and the schema coverage is trivially 100%. The baseline for a 0-parameter tool is 4, and the description appropriately explains what the tool returns information about, so there is no missing parameter guidance.
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 uses a specific verb and resource: 'Check whether this connector is actually safe and working right now.' It enumerates concrete aspects (gateway reachability, open company, TALLY_URL, read-only mode, disabled tools), immediately distinguishing it from all sibling tools, which mostly retrieve accounting data or perform mutations.
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?
It explicitly tells an agent when to invoke this tool: 'Use this before trusting a session, or when something feels off.' It also warns against the alternative of inferring connector state from a single tool call's success/failure, which is actionable guidance for choosing this over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, idempotentHint=true), the description adds precisely what gets destroyed ('replacing its item lines and narration'), the matching key ('Matched by date + voucher number'), and a critical failure mode: 'Refuses if another voucher type shares the same number on that date (confirmed live: Tally's Alter lookup ignores voucher type and can silently corrupt the wrong one).' The collision-refusal behavior and remediation guidance ('resolve the collision in Tally first') are exactly the high-value context the rubric rewards.
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?
Four sentences, each earning its place: purpose and scope first, then schema-reuse note, then matching/precondition guidance, then the critical warning with evidence. The structure is logical and front-loaded, with zero filler; even the longest sentence carries essential safety information.
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?
Despite having no output schema, the description gives an agent everything needed to call correctly: what the operation does and replaces, the identity key, the prerequisite lookup steps, and the collision failure mode with remediation. With annotations already covering the destructive/idempotent safety profile, nothing material is missing for a mutation tool.
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%, so the baseline is 3. The description adds value beyond the schema by explaining that date and voucherNumber form the identity key ('Matched by date + voucher number') and by flagging voucherNumber as the parameter that carries collision risk. It also avoids duplicating per-field docs by pointing to create_material_in for shared field semantics.
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 precise verb+resource+scope: 'Update an existing Material In voucher in TallyPrime, replacing its item lines and narration.' It clearly differentiates from create_material_in (create vs. update), update_material_out (different voucher type), and update_voucher (generic updater) without needing to open 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit preconditions: 'use get_ledger_vouchers or get_vouchers first to confirm it exists and is unique,' and references create_material_in by noting 'Same fields as create_material_in, plus voucherNumber.' It does not explicitly name when-not-to-use alternatives such as update_material_out or update_voucher, and it doesn't state 'use create_material_in if the voucher doesn't exist,' so it falls just short of exhaustive routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description reveals exactly what gets replaced, how the voucher is matched, and a serious failure mode: Tally's Alter lookup can silently corrupt the wrong voucher when another type shares the same number. It also states the tool refuses to run under collision, giving the agent accurate expectations about destructive risk and prerequisites.
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?
The description uses three dense sentences, each earning its place: the action and scope, the parameter-relationship and matching prerequisite, and the collision warning with a remediation step. The most important information is front-loaded, and there is no filler or repetition of schema content.
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 destructive 17-parameter update tool with no output schema, the description is remarkably complete: it specifies the matching identity, preconditions, what is replaced, and a known failure mode with the correct response. It leverages the schema for parameter detail and the create_purchase_invoice sibling for field semantics, leaving no critical gap for an agent to invoke it correctly.
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 description coverage is high (88%), so the baseline is 3. The description adds meaning by clarifying that the parameter set is identical to create_purchase_invoice plus voucherNumber, and by identifying date + voucherNumber as the matching key. This is valuable semantic context beyond the individual field descriptions, though much of the parameter detail is already in the schema.
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 specific verb ('Update'), a specific resource ('existing item-invoice Purchase voucher in TallyPrime'), and the exact scope of the update ('replacing its item lines, party, and narration'). It also distinguishes itself from the likely alternative create_purchase_invoice by noting 'Same fields as create_purchase_invoice, plus voucherNumber', and from the generic update_voucher sibling by specifying item-invoice Purchase vouchers.
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 gives clear usage context: it is for updating an existing item-invoice Purchase voucher, and it instructs the agent to confirm existence and uniqueness via get_ledger_vouchers or get_vouchers first. It also explains the matching logic (date + voucher number) and what to do on collision. However, it does not explicitly state when not to use this tool versus alternatives such as create_purchase_invoice or update_voucher, though that is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description discloses a live-confirmed behavioral gotcha: pass the parent's plain name, not a dotted path, with a concrete invalid/valid example. It also reveals the downstream failure mode if creation is skipped, giving the agent operational knowledge that the schema and annotations do not provide.
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 sentences, each earning its place: what the tool does, when it is needed, and the critical path-format rule. The core purpose is front-loaded and no content is wasted.
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 two-parameter create tool with no output schema and no nested objects, the description covers purpose, prerequisite timing, failure symptoms, and the parameter format pitfall. Nothing essential for selecting and correctly invoking the tool is missing.
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%, the description adds critical meaning to the 'parent' parameter by explaining plain-name versus dotted-path usage and giving a concrete example: 'MAIN LOCATION' as parent + 'DUBAI' as name. This substantially reduces the risk of misformatted invocations.
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 'Create a new Godown/Location in TallyPrime', naming a specific verb and resource, and clarifies optional nesting. This clearly distinguishes it from sibling create_* tools like create_ledger, create_group, and create_stock_item, as well as the get_* read tools.
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?
It provides a clear trigger: use before referencing a godown that doesn't yet exist on an invoice/voucher line, otherwise the call fails with 'Godown does not exist!'. It does not explicitly name alternative tools or state when-not-to-use conditions, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
All four annotations are neutral/false, so the description carries the full behavioral burden and over-delivers: Tally silently reassigns voucher numbers regardless of an explicit voucherNumber (Auto Retain numbering), and it rejects Order-class vouchers with exact missing-field messages ('Order No. is missing in Item Allocations', 'Due Date of Order is missing in Item Allocations'). It also reveals the reverse-engineered XML mapping — voucher-level REFERENCE tag and item-nested BATCHALLOCATIONS.LIST — which is exactly the non-obvious behavior an agent cannot infer from schema or annotations. No contradiction with the annotations (write operation matches readOnlyHint=false).
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 ~230-word description is dense but nearly every block earns its place — prerequisites, fatal error messages, field-to-XML mapping, and post-create verification are all load-bearing for correct invocation. It could be tightened (the 'confirmed live' caveat appears twice and the required-field error text is partly restated in the schema), and the single-paragraph wall of text would benefit from light structuring, but there is no fluff.
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 write tool with high quirk quotient and no output schema, nothing essential is missing: it covers the prerequisite, exact failure messages, the XML nesting that dictates how items must be shaped, and the post-condition instruction to verify the assigned voucher number via get_vouchers. The only nominal gap, the success response format, is practically compensated by the explicit follow-up verification step.
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%, so the baseline is 3, but the description adds genuine meaning beyond the schema: orderNumber is 'the order reference shown as Order no. in Tally's UI' backed by the REFERENCE tag and independent of voucherNumber (real example: voucherNumber '1' vs Order no. '12345'), and it clarifies that per-item Order No./dueDate live inside BATCHALLOCATIONS.LIST rather than as direct ALLINVENTORYENTRIES fields. Not every parameter gets enrichment (date, partyLedger, narration rest on the schema), which keeps this at 4.
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 Sales Order in TallyPrime — a future commitment to sell' — which immediately scopes the operation as pre-dispatch and pre-invoicing. It then distinguishes the tool from create_sales_invoice and create_delivery_note by voucher class ('Order-class voucher, structurally different from Delivery Note's inventory-class'), so an agent can pick it correctly among dozens of create_* siblings without opening schemas.
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?
The description gives explicit workflow sequencing: create the order first, then 'follow up with create_delivery_note (dispatch) and/or create_sales_invoice (billing) ... once goods actually move' — which both states when this tool applies and implicitly when the siblings replace it. It also names the voucher-type-active prerequisite shared with create_delivery_note and a concrete retry rule for voucherNumber (blank EXCEPTIONS:1 → check get_vouchers and pass the next number).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=true and openWorldHint=false, so the description carries the behavioral burden and delivers: the cache is in-memory and session-scoped, is gone when the session ends, and is replaced on company switch/re-sync so nothing lingers between companies. It also discloses the scope boundary (no vouchers). The readOnlyHint is consistent — Tally itself is never modified.
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?
Two sentences, front-loaded with the action verb and resource, followed by dense but relevant qualifiers (session lifetime, company-switch invalidation). The exclusion-and-alternative sentence earns its place by preventing a likely misuse. No filler and no repetition of schema or annotation content.
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 0-param tool with no output schema, the description covers the essentials: scope of data, cache semantics, lifetime, invalidation on company switch, and sibling routing. The only gap is no statement of what the tool returns or how the agent detects a successful sync, which a brief note would close.
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?
The input schema is empty with 0 parameters, so the baseline is 4 and there is nothing to document. The description compensates by clarifying what the operation covers (ledgers, groups, stock items) and its exclusions, effectively serving as the parameter contract for a parameterless tool.
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 specific verb and resource ('Pull ledgers, groups, and stock items from TallyPrime into this session's SQL cache'), stating exactly what the tool does and where the data goes. It explicitly differentiates from the sibling sync_vouchers_to_sql by naming what it does NOT cover, so an agent can disambiguate without opening schemas.
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?
It states the motivating use case ('so query_sql can run fast arbitrary queries without hitting Tally each time'), telling the agent when this tool is valuable. It gives an explicit when-not: 'Does NOT sync vouchers — use sync_vouchers_to_sql for those, one date range at a time,' naming the alternative and a usage qualifier. This is explicit when/when-not/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description discloses that item lines are replaced, matching is by date + voucher number, and the tool refuses on voucher-type collisions to prevent silent corruption. It also names the confirmed unsafe behavior of Tally's Alter lookup, which is valuable safety context.
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?
The description is compact but information-dense, front-loading the core purpose and replacement behavior before preconditions and failure modes. Every sentence earns its place, with no filler or redundant restatement of the schema.
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 complex 17-parameter destructive update with no output schema, the description covers purpose, matching, preconditions, and collision handling well. It could be slightly more explicit about what happens to optional fields not supplied in the update, but the schema and 'same fields as create_debit_note' reference mitigate this gap.
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%, so the baseline is 3, but the description adds meaning beyond the schema by explaining the matching key (date + voucherNumber), the collision-related refusal, and the relationship to create_debit_note's fields. The schema itself already documents formats, defaults, and dependencies, so the description need not repeat them.
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 states a specific verb ('Update'), resource ('existing item-invoice Debit Note in TallyPrime'), and exact scope ('replacing its item lines, party, and narration'). It also distinguishes itself from create_debit_note by noting the added voucherNumber field, so an agent can immediately tell update from create.
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?
It explicitly instructs to call get_ledger_vouchers or get_vouchers first to confirm the voucher exists and is unique. It also tells the agent what to do when a collision is detected: resolve in Tally first. This is concrete, actionable guidance for when and how to use the tool safely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (destructiveHint=true, idempotentHint=true, readOnlyHint=false) by disclosing the matching semantics (date + voucher number), the refusal behavior, and the underlying risk: 'Tally's Alter lookup ignores voucher type and can silently corrupt the wrong one — confirmed live.' This is exactly the hard-won behavioral context an agent needs to avoid a costly mistake, and it does not contradict 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, each carrying load-bearing information: the mutation scope, the identity key plus prerequisite lookup, and the refusal/collision warning. The critical safety warning about silent corruption is front-loaded in the final sentence rather than buried, and there is no filler or repetition of schema fields.
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 16-parameter write tool with no output schema, this description covers the essential operational context: what gets replaced, how the target is identified, the prerequisite verification step, and the collision failure mode. The only meaningful gap is return-value behavior (nothing says what happens on success or when the voucher is not found), which the absent output schema leaves unstated.
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?
With 88% schema description coverage, the schema carries most parameter meaning, so baseline is 3. The description adds genuine value on top: it reveals that date and voucherNumber form a composite lookup key (the schema only labels them individually), and it cross-references create_sales_invoice so an agent can reuse its parameter knowledge. This lifts it above baseline, though it doesn't comment on every parameter.
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: 'Update an existing item-invoice Sales voucher in TallyPrime, replacing its item lines, party, and narration.' The scope of modification is explicit, and the sentence 'Same fields as create_sales_invoice, plus voucherNumber' positions it as the update counterpart to a named sibling, so an agent can distinguish it from create_sales_invoice and the other update_* tools without opening 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit preconditions and workflow: 'use get_ledger_vouchers or get_vouchers first to confirm it exists and is unique.' It also states a specific refusal condition — another voucher type sharing the same number on that date — and prescribes the remedy ('resolve the collision in Tally first'). The relationship to create_sales_invoice (same fields plus voucherNumber) implicitly routes new-voucher creation to the create sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-idempotent behavior, but the description adds valuable detail: the exact XML is sent unchanged, and a previewId can only be confirmed once, with reuse failing rather than silently reposting. This meaningfully exceeds annotation-only information and matches the destructive hint.
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 focused sentences with no filler. The core purpose and exclusive write behavior are front-loaded, followed by the parameter source and the one-time-use constraint.
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 single-parameter confirmation tool with annotations covering safety, the description covers the workflow, source of the ID, exclusivity of the write, and failure behavior on reuse. Nothing critical is missing for an agent to call it correctly.
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?
The schema already documents previewId as returned by preview_write, so the baseline is 3. The description adds context that this ID ties to a previously-built preview and that the exact XML is transmitted unchanged, reinforcing the parameter's significance beyond a simple string 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 action (post a preview), a resource (Tally), and the exact workflow stage (after preview_write). It explicitly distinguishes itself as the only tool that actually writes for previewed batches, so an agent can clearly separate it from preview_write and the many create/update siblings.
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 an explicit when-to-use rule: after preview_write, using the returned previewId. It also names preview_write as the required precursor and notes that reuse of confirmed/expired IDs fails, marking the boundary of the operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing that deletion removes the voucher 'with no trace,' that it has no undo, and that it refuses when another voucher type shares the same number due to Tally's lookup ignoring voucher type. These are non-obvious behavioral traits that materially affect invocation and expected outcomes.
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?
The description is three sentences with no filler. It front-loads the core action and irreversibility warning, then explains the matching criteria and a critical collision caveat. Every sentence earns its place and no important context is buried.
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?
Despite no output schema, the description provides everything needed to use the tool correctly: prerequisites (verify existence), matching rules, irreversibility, and the specific failure mode around number collisions. For a destructive operation with Tally quirks, this is exceptionally complete.
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%, so the baseline is 3. The description adds meaningful context by explaining that the three parameters form a composite match key, must be unique, and must exactly match an existing voucher—information that helps the agent correctly construct the parameters beyond simple type definitions.
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 states a specific verb ('permanently delete') and resource ('existing voucher from TallyPrime'), and explicitly distinguishes it from cancelling, which is a different outcome. It clearly separates this tool from read-only sibling tools and other delete tools like delete_master or delete_stock_item.
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?
The description explicitly tells the agent when to use this tool (when permanent deletion with no trace is intended), and contrasts it with the alternative of cancelling. It also instructs the agent to first confirm the voucher exists using get_ledger_vouchers or get_vouchers, and warns that the tool refuses on number collisions—so the agent knows to resolve the collision beforehand.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations signal readOnly=false and destructiveHint=true, and the description adds substantial context beyond that: the update replaces all existing item lines, matching is by date + voucher number, the tool refuses on voucher-type collisions, and Tally's Alter lookup can silently corrupt the wrong voucher. This is exactly the kind of behavioral disclosure an agent needs.
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?
Four sentences, each with a distinct operational purpose: what the tool does, how its field set relates to create_credit_note, how to locate the target voucher, and what happens on collision. There is no filler, and the most decision-critical information is front-loaded.
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 16-parameter mutating tool with no output schema, the description covers the essential operational context: existence check, uniqueness matching, collision failure mode, recovery step, and replacement semantics. Combined with full schema descriptions on every parameter, an agent has everything needed to invoke it correctly.
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 description coverage is 100%, so most parameter meaning already lives in the schema. The main description still adds value by explaining the composite matching key ('Matched by date + voucher number') and by framing the parameter set as create_credit_note's fields plus voucherNumber, which helps the agent construct valid and complete arguments.
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 ('Update'), resource ('item-invoice Credit Note in TallyPrime'), and concrete scope: replacing item lines, party, and narration. It also distinguishes the tool from create_credit_note by noting 'Same fields as create_credit_note, plus voucherNumber', so an agent can pick it apart from sibling update/create tools without opening 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit preconditions: the credit note must exist and be uniquely matched by date + voucher number. It directly instructs the agent to call get_ledger_vouchers or get_vouchers first, and tells it what to do when a collision blocks the update — resolve in Tally first. This is clear when-to-use and how-to-proceed guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description discloses critical matching logic ('Matched by date + voucher number') and a subtle safety behavior: it refuses when a voucher-type collision exists, warning that Tally's Alter lookup can 'silently corrupt the wrong one.' This is valuable context not captured in annotations.
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?
The description is dense but every sentence serves a purpose: purpose, matching, collision warning, and resolution. It front-loads the action and then details necessary prerequisites and failure modes without redundancy. Concise and well-structured.
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?
Given the tool's complexity (12 params, update semantics, matching criteria, collision risk, no output schema), the description covers the essential knowledge: how it matches, what it replaces, what to do first, and how it handles ambiguity. Nothing critical is missing for correct invocation.
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?
The schema has 100% coverage with detailed per-parameter descriptions, so baseline is 3. The description adds meaning by clarifying that the tool 'replacing its item lines, party, and narration' (which is only partially explicit in the schema) and noting that voucherNumber is the update key. This adds a little beyond the schema, justifying a 4.
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 precise action ('Update an existing Delivery Note in TallyPrime') and explicitly lists what gets replaced (item lines, party, narration). It distinguishes itself from create_delivery_note by mentioning the additional voucherNumber field, making its purpose unambiguous.
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?
The description gives explicit pre-conditions: 'use get_ledger_vouchers or get_vouchers first to confirm it exists and is unique.' It also provides actionable guidance on the collision failure ('resolve the collision in Tally first if that happens'), and implies when to use the create counterpart by referencing its shared fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool replaces existing line items (destructive behavior) and explicitly mentions it refuses on collision scenarios. The annotations (readOnlyHint=false, destructiveHint=true) are consistent with the described behavior, and the description adds clarity by explaining the collision risk from Tally's Alter lookup behavior.
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?
The description is concise, containing two sentences that deliver the core purpose, preconditions, and failure mode without extraneous detail. It is well-structured, front-loading the main action and then addressing prerequisites and exceptions efficiently.
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?
The description covers essential context: the update operation, replacement semantics, preconfirmation steps, and collision handling. However, it does not mention what the tool returns on success or failure beyond the refusal case, which might be expected for a write operation. This minor gap prevents a perfect score, but given the tool's nature, it is still sufficiently complete for an agent to use effectively.
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?
The schema covers all parameters with descriptions, and the description adds meaningful context beyond the schema, such as the default for batchName ('Primary Batch') and the auto-fill behavior for godown when only one exists. This enriches understanding of parameter usage and edge cases.
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 clearly states it updates an existing Physical Stock voucher in TallyPrime, specifying the action of replacing line items and narration. It uses the verb 'Update' and distinguishes it from create_physical_stock and other update tools in the sibling list. The resource and scope are explicit, leaving no ambiguity about the tool's purpose.
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?
The description provides explicit guidance on when to use this tool: it instructs to first confirm existence and uniqueness via get_ledger_vouchers or get_vouchers. It also states the refusal condition when another voucher type shares the same number, making the usage conditions clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: inventory-only (no ledger entries), auto-fill logic for godowns, auto-numbering pitfalls, and how additional costs are allocated. This transparency is especially valuable given the write nature of the operation.
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?
The description is detailed but well-organized, with the main paragraph providing an overview and parameter-level details following. No fluff; every sentence carries relevant operational information.
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?
Covers all relevant operational contexts: creation behavior, multi-godown requirements, auto-numbering pitfalls, and cost allocation. Even without an output schema, it addresses potential error scenarios, making it sufficiently complete for an agent to use 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?
Every parameter is explained beyond the schema, such as 'consumed' vs 'produced' for sources/destinations, defaults for batchName, allocationType for costs, and the distinction between voucherType and voucherNumber. This adds significant meaning beyond the JSON schema.
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 clearly states the tool creates a Stock Journal voucher for inventory transfers or manufacturing conversions, explicitly distinguishing it from other inventory voucher types and noting it is inventory-only with no ledger entries.
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?
Provides explicit guidance on when to use (transfer or manufacturing), how to use the voucherType for manufacturing journals, and detailed notes on auto-numbering and godown handling, including failure scenarios and retry advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations: it discloses the date + voucher-number matching rule, the refusal behavior on shared voucher numbers, the risk of silently corrupting the wrong voucher, and the Auto Retain numbering limitation. It even cites confirmed live behavior, which is strong transparency for a destructive operation.
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?
The description is dense but every sentence earns its place: purpose, prerequisites, collision behavior, and numbering caveat. It does not repeat field-level schema details and front-loads the core update action before caveats.
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 mutating tool with no output schema, the description supplies all essential operational context: how to locate the voucher, how to handle ambiguity, possible refusal, and a key limitation. The schema already covers field-level details, so nothing critical is missing.
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?
The description adds critical meaning beyond the schema: orderNumber and each item's dueDate remain required, voucherNumber is the locating key, matching is by date and voucher number, and voucherNumber may not actually be changeable. This materially improves the agent's ability to construct a correct invocation.
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?
Description opens with a specific verb plus resource: 'Update an existing Sales Order in TallyPrime', and enumerates exactly what gets replaced: item lines, party, order number, and narration. This clearly distinguishes it from create_sales_order and the other create/update voucher siblings.
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 instructs the agent to call get_ledger_vouchers or get_vouchers first to confirm existence and uniqueness, and tells it what to do if a collision occurs: resolve it in Tally first. It also clarifies how this tool relates to create_sales_order by referencing the same fields plus voucherNumber.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

PNPC-MCP-Tally-Prime MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![PNPC-MCP-Tally-Prime MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/lokesh-sparrow/PNPC-MCP-Tally-Prime/badges/card.svg)](https://glama.ai/mcp/servers/lokesh-sparrow/PNPC-MCP-Tally-Prime)

Score Badge

Copy to your README.md:

[![PNPC-MCP-Tally-Prime MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/lokesh-sparrow/PNPC-MCP-Tally-Prime/badges/score.svg)](https://glama.ai/mcp/servers/lokesh-sparrow/PNPC-MCP-Tally-Prime)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![PNPC-MCP-Tally-Prime MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2Flokesh-sparrow%2FPNPC-MCP-Tally-Prime%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/lokesh-sparrow/PNPC-MCP-Tally-Prime)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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