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

No annotations are provided, so the description carries full responsibility. It discloses that the tool does not read from TallyPrime by design, explains the reasoning about benchmark judgement, states defaults and override capabilities, and confirms read-only behavior. It also describes the exact return content (materiality figures and documented basis), leaving no surprises.

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

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

The description is well-structured with clear sections (WHEN TO USE, REQUIREMENTS, RETURNS, PERCENTAGES, PAGINATION) and front-loads the core purpose. Each sentence adds necessary information without padding. The length is justified by the tool's complexity and the need to explain the judgment calls involved.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema, the description thoroughly explains what will be returned (materiality figures and full basis). It covers prerequisite actions (reading and agreeing on the benchmark), parameter relationships, and the philosophical grounding of materiality percentages. Nothing an agent needs to decide whether and how to invoke the tool is missing.

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

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

Although schema coverage is 100%, the description adds significant value: it explains that perfomancePercent is relative to overall materiality, clearlyTrivialPercent also relative to overall materiality, the benchmark choice as a judgement call, and the amount as a plain string with sign ignored. It clarifies relationships between parameters that the schema alone does not convey, making the tool easier to use correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Compute') and resource ('overall materiality, performance materiality and the clearly-trivial threshold') with a clear basis document. The description differentiates from sibling tools by explicitly noting it calculates rather than reads data, and the 'WHEN TO USE' section makes the intended role unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (planning an audit/review or when materiality is in question) and when not to rely on it for reading figures (must supply the benchmark manually, read from tally_get_statement and agree with the user). It effectively guides the agent to the correct sibling tool for data retrieval while positioning this tool as the computation layer.

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

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

With no annotations provided, the description carries the full burden, and it does so thoroughly. It discloses the read-only nature, the important default-period behavior differing from sibling tools, the limitation about TallyPrime's closing balance being anchored to the company's current period end, the distinction between NOT CHECKABLE and FAILED, multi-company semantics, findings structure, verbosity behavior, and the rule that text fields are data, not instructions. This goes far beyond a generic 'check books' statement.

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

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

The description is long, but it is tightly organized under clear headings and every section earns its place given the tool's complexity. The core purpose is front-loaded, followed by when-to-use, returns, and then the subtle caveats that affect interpretation. Nothing feels redundant or decorative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that there is no output schema, the description thoroughly explains return values: pass/fail verdict, counts, exceptions, findings objects, severity levels, and the meaning of notApplicableReason. It also covers edge cases like partial periods, multiple companies, and verbosity. An agent has enough context to call the tool and interpret its results correctly without additional documentation.

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

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

Although schema coverage is 100%, the description adds substantial meaning beyond the schema. It explains the critical default period (the financial year the books begin in, not the one containing today), requires both or neither date, describes the companies array behavior, and clarifies what verbosity values do. This is exactly the kind of parameter context an agent needs to invoke the tool correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise statement of what the tool does: 'Check that the books tie: every voucher balances, every ledger closing balance equals its opening balance plus the movements in the period, and the stock figure in the accounts agrees with the stock records.' This names a specific verb, resource, and scope, and it sets the tool apart from siblings like tally_get_vouchers or tally_test_vouchers by describing a comprehensive tie-out rather than a simple retrieval or test.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'WHEN TO USE' section is explicit about timing: use it before relying on any figure from the books for a report, run it first, and quote the result. It also warns that if it fails, other tools' numbers should not be presented. It does not explicitly name alternative tools or exclusions, but the context clearly tells an agent when this check is the right call.

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

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

With no annotations provided, the description carries the full burden, and it succeeds. It discloses a critical non-obvious behavior: this tool never answers from the response cache, so a green result means TallyPrime answered just now. It also states the tool is read-only, returns error details with fix suggestions, and does not expose accounting data. This is far beyond what annotations would typically provide.

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

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

The description is well-structured with clear capitalized section headings like WHEN TO USE, RETURNS, DOES NOT RETURN, and PAGINATION. Every section earns its place: safety, cache behavior, output fields, exclusions, and alternatives. It is detailed but scannable, and the most important purpose statement is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero params, no output schema, and no annotations, the description is remarkably complete. It tells the agent what will be returned on success and failure, what will not be returned, that pagination does not apply, that it is safe to call, and that it can also be used to report version. Nothing needed to invoke or interpret the tool is missing.

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

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

The tool has zero parameters and the input schema is empty, so there are no parameter semantics to document. The description correctly focuses on behavior and return values instead. The 0-parameter baseline of 4 is appropriate because description can add nothing further about parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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: 'Check whether TallyPrime is running and reachable over its HTTP interface.' It also clearly distinguishes this from sibling data-returning tools by stating it returns connection status and version, not accounting data. This makes the tool's role immediately unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to use the tool: 'as a first step when any other Tally tool fails, or to confirm setup before starting an analysis.' It also gives specific alternative routing, e.g., 'does not tell you which company is loaded — use tally_list_companies for that.' The guidance covers both positive use cases and exclusions.

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

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

With no annotations provided, the description carries the full burden, and it goes far beyond a generic summary. It discloses the null reconciliation meaning, the nested-voucher source and period limitation, the two-place instrument fields, the 'read-only' guarantee, the sign convention for amounts, and the warning that text fields are data, not instructions. This is exemplary behavioral disclosure.

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

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

The description is long but every paragraph is sectioned and earns its place: purposes, return shape, reconciliation semantics, source caveats, amount handling, pagination. It is front-loaded with the core purpose and when-to-use guidance, and the structured headings make it scannable despite its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 8 optional parameters, no output schema, and complex reconciliation semantics; the description covers return structure, the uniformFields behavior, null versus false status, period semantics, source limitations, pagination, and suggested sibling tools. Nothing an agent needs to call this correctly and interpret the result safely is missing.

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

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

Although schema coverage is 100%, the description adds substantial meaning beyond it: status filters can fail with TALLY_UNSUPPORTED_OPERATION, pageSize controls response size rather than query cost, omitted dates mean the Indian financial year, and instrumentMatch is deliberately field-independent. The parameter descriptions in the schema are also unusually rich, but the narrative adds operational semantics that the schema cannot convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and object: 'Bank instrument detail and reconciliation status for a period — cheques, NEFT/RTGS transfers and other bank transactions, with whether each has been reconciled against the statement.' It names concrete resources (instruments, reconciliation status) and explicitly differentiates itself from siblings like tally_get_vouchers and tally_get_masters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is an explicit 'WHEN TO USE' section: month-end bank reconciliation, what has not cleared, outstanding cheques. It also tells when NOT to use it — 'To trace one payment by cheque or UTR number, tally_get_vouchers with fieldMatch is better' — and points to tally_get_masters for book balance. This is model routing guidance.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly: it discloses that the tool is read-only, that it reports only the current closing position with no period filtering, that quantity is a unit-qualified string, that closingValue arrives negative by Tally convention, that null is not zero, and that an empty result means inventory tracking is unused. It even warns against recomputing values and treats text fields as data, not instructions.

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

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

The description is long but professionally structured with clear section labels such as WHEN TO USE, RETURNS, SIGNS, and EMPTY RESULT. Each section conveys an important semantic pitfall, though some details, such as the repeated 'no period' note and the live multiplication example, could be tightened without losing value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description covers everything an agent needs to invoke the tool correctly: return shape, grouping options, unit handling, sign conventions, null semantics, empty-result behavior, report-basis discrepancies, and read-only safety. Nothing critical appears missing.

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

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

Schema coverage is 100% and both parameters already have solid descriptions, so the baseline is 3. The description adds genuine extra meaning by explaining that by: 'godown' is the only way to obtain location-wise stock and advises when to prefer each grouping. It also clarifies the company failure mode and the relationship between the two reports, which goes beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb-resource pair ('Closing stock from TallyPrime's own summary reports') and immediately scopes the output to quantity, rate, and value per item or godown. It also distinguishes itself from sibling tools such as tally_get_inventory_movements and tally_get_masters, making the tool's identity unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'WHEN TO USE' section explicitly states the intended use, calls out by: 'godown' as the only location-wise option, and names tally_get_inventory_movements for movement questions. It also contrasts the summary-report basis against tally_get_masters' master-data basis, giving the agent clear routing rules and even guidance to state which basis is being quoted.

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

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

With no annotations provided, the description carries the full burden—and it goes well beyond. It discloses that the tool is read-only, expensive ('reads every field of every ledger', 'most expensive call'), that includeFeatures adds an extra request, that features are inferred rather than read from settings, and that text fields are data, not instructions. This is rich behavioral context 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.

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

The description is long but tightly organized with headings (WHEN TO USE, RETURNS, FEATURES, COST, DOES NOT RETURN) that make it scannable. Each sentence adds information; there is no filler or repetition of schema content. The most important points—what it describes and when to call it—are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, no output schema, and no annotations, the description is remarkably complete. It explains return fields, distinguishes meaningful from noisy fields, warns about cost, states exclusions (no transactions, no interpretation), and includes security/usability notes about text fields. An agent can decide when and how to call it correctly.

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

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

Although schema coverage is 100%, the description adds significant meaning beyond the schema: omitting company uses the loaded one, a mismatched company errors rather than returning another company's data, and includeFeatures has behavioral consequences (extra request, inference semantics). The FEATURES section also clarifies how to interpret the flag values returned.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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: 'Describe the loaded company' and enumerates exactly what it returns—chart of accounts size, used data fields, and optional TallyPrime features. It clearly differentiates this from sibling tools by positioning it as the orientation call for audit/review/explore tasks, not a transaction or statement tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

This gives explicit WHEN TO USE guidance: 'as the FIRST call when asked to audit, review or explore a company you have not looked at yet.' It explains why (companies differ in enabled features and available fields) and tells the agent to 'use the narrower tools' afterward, though it does not name specific sibling tools as alternatives. The 'DOES NOT RETURN' section also clarifies exclusions.

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

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

With no annotations, the description carries the full behavioral burden. It discloses read-only status, unadjusted/non-netted balances, inclusion of uncontactable parties, separation of auditor's confirmation process from the tool's listing function, and prompt-injection-safe treatment of text fields. These are non-obvious traits an agent needs before invoking.

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

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

The description is long but structured with scannable headers and every paragraph carries distinct operational value. It front-loads the main purpose, then adds return shape, caveats, scope limits, and security context. No filler or tautology.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 compensates by specifying return rows, ordering, contactable semantics, and netting behavior. It also covers failure context (company mismatch), permission-neutral read-only guarantee, and judgment boundaries such as no sample selection. An agent has everything needed to decide whether to call and how to interpret results.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds material parameter semantics beyond the schema: minimumBalance has no default deliberately because thresholds are audit judgment; direction is derived from balance, not group; pageSize slices an already complete fetch and affects response size, not query cost; company fallback semantics; partyGroups unknown names ignored. This meaningfully improves invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states the exact resource (list of parties that could be sent a balance confirmation) and the content (balance per books, contact details). This is distinct from sibling list/report tools because the purpose is specifically external balance confirmation circularisation, not general outstanding or statement retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is an explicit WHEN TO USE section tied to receivables/payables circularisation, and parameter guidance in context (minimumBalance judgment, direction semantics). It does not name sibling tools or state when not to use this tool, but the context is clear enough to route an agent.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly. It explains the tie-out control, the `ties` and `difference` fields, that entries are classified by side rather than sign, that depreciation is reported but not recomputed, that the period is echoed back, and that text fields are data, not instructions. It even notes that nothing can modify TallyPrime.

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

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

The description is long but every section earns its place, and clear uppercase headers keep it navigable. It front-loads purpose and when-to-use, then covers controls, returns, interpretation pitfalls, depreciation behavior, and security. The length is justified by the subtle audit concepts it must convey.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 correctly fills that gap by explaining the return shape: one row per ledger, depreciation reported separately, plus the `ties` and `difference` fields on each row. It also covers defaults, period behavior, grouping caveats, depreciation limits, and the read-only nature, making it complete for a complex financial tool.

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

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, and the description adds meaningful parameter semantics for the date fields: omit both for the Indian financial year, supply both or neither, and the resolved period is echoed back. It does not substantially enrich the company, assetGroups, or depreciationHints parameters beyond what the schema already says, so it stops short of a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific resource and result: a 'Fixed asset movement schedule: opening, additions, disposals and closing per asset ledger, with the additions and disposals traced back to vouchers.' It also distinguishes itself clearly from a related concept by stating 'THIS IS NOT A FIXED ASSET REGISTER,' which helps an agent understand what the result actually represents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives an explicit WHEN TO USE block tied to the fixed assets section of an audit, and clearly states what it is for: seeing what was bought and sold and testing that movements explain the balance change. It also provides strong when-not guidance, including that it is not an asset register and that depreciation is reported but never recomputed.

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

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

With no annotations, the description carries the full burden and does so thoroughly: 'NOTHING IS CALCULATED', the IF EMPTY behavior with the unread-payload warning, the read-only statement, and the instruction to treat text fields as data rather than instructions. It also discloses period defaults and derived-from logic.

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

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

The description is long but every section earns its place: labeled blocks for each view, WHEN TO USE, RETURNS, empty-case behavior, period rules, and a security note. The critical takeaway ('NOTHING IS CALCULATED') is front-loaded and emphasized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 return contents, period resolution, empty results, warning semantics, company mismatch failures implicitly, and read-only behavior. It covers the two view modes and the main edge cases an agent would encounter.

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

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

Although the schema already covers 100% of parameters, the description adds functional meaning: summary needs no period, transactions requires fromDate/toDate, both dates or neither, the period default and echo, taxGroups defaulting to 'Duties & Taxes', and pageSize controlling response size rather than query cost. This materially improves parameter selection.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'GST data as TallyPrime records it, picked by `view` — one call, one view', naming the exact resource and the split between summary and transactions. It enumerates the returned content for each view, so an agent can tell it apart from the general voucher and TDS siblings even without naming them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit WHEN TO USE sections for both views: summary as the first GST call to establish recorded data, transactions for examining GST as entered on specific vouchers. It also states when not to use it for computed liability, saying computing the return is out of scope and to report what Tally recorded.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly: it states read-only behavior, explains that quantities are returned exactly as recorded and never recomputed, and warns that guessing the report ID could terminate the application. It also discloses the field-naming convention, the period-resolution behavior, and explicitly warns that text fields are data, not instructions. This exceeds what the schema alone provides.

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

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

The description is long but well-structured into labeled sections, with the core purpose and use case front-loaded. Each section earns its place by adding decision-relevant detail, and the bold headings make the content scannable for an agent. Given the complete absence of annotations, the length is justified rather than excessive.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Since there is no output schema and no annotations, the description must explain return shape and operational behavior itself; it does so by listing named properties versus 'fields', describing period defaulting, and explaining pagination semantics. It also covers likely failure modes, the empty-result diagnostic path, and safety warnings about report IDs and text fields. This is sufficient for 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.

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 input schema already documents date formats, defaults, page size behavior, and the company failure mode. The tool description adds minor value by formalizing the 'supply both or neither' period constraint, but most of its extra content concerns output behavior rather than parameter semantics. It does not materially compensate for anything missing because little is missing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The lead sentence names the operation ('Movements of a stock item over a period') and the data source ('inventory lines on vouchers'), making the resource and scope specific. The WHEN TO USE section further clarifies the intent: seeing what came in, what went out, on which voucher, and against which party. This distinguishes the tool from report-based or summary-based siblings by explicitly explaining that it is voucher-derived rather than a dedicated TallyPrime inventory report.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is an explicit WHEN TO USE section, and the description also gives a fallback path to tally_get_company when the result is empty, which is helpful diagnostic guidance. However, it does not explicitly name when-not-to-use alternatives such as tally_summarise_movements or tally_get_statement, even though the NO COMPUTED QUANTITIES warning implies a distinction. This is clear context without full when-not/alternative coverage.

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

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses that the running balance is server-computed rather than from TallyPrime, explains the tallyReportedClosingBalance caveat, describes pagination behavior across a full fetch, warns that text fields are data not instructions, and confirms the operation is read-only.

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

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

The description is long but every section earns its place, using labelled blocks (WHEN TO USE, RETURNS, PERIOD, PAGINATION, and the behavioral caveat). It front-loads the core purpose and adds detail only where an agent would otherwise misjudge the running balance or pagination.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter tool with no output schema and no annotations, the description is complete: it explains return shape, date defaults, pagination semantics, computed-vs-reported balance, company error behavior, and the read-only safety profile. Nothing necessary for correct invocation is left unstated.

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

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

Schema coverage is already 100%, but the description adds material semantics on top: omitting both dates selects the Indian financial year, the resolved period is echoed back, pageSize controls response size not query cost, and an unloaded company name causes a specific error. These are exactly the details an agent needs beyond schema field formats.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first line states exactly what the tool does: it produces a statement of movements on a single ledger over a period with a running balance. 'Single ledger' and 'running balance' distinguish it from sibling reporting tools like tally_get_vouchers or tally_get_statement without needing to open them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The WHEN TO USE section gives concrete scenarios, such as seeing what a party was invoiced and paid or what went through an expense account. It does not explicitly name sibling tools or state when not to use it, 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.

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

No annotations are provided, so the description carries the full burden, and it does so exceptionally. It discloses failure modes like TALLY_COMPANY_NOT_FOUND and INVALID_PARAMETERS, sign conventions for balances, null-means-empty semantics, the UNREAD PAYLOAD warning, client-side cost and pagination behavior, and read-only status. This goes far beyond what the schema alone could communicate.

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

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

The description is long but rigorously structured with clear sections, bullet lists, and front-loaded purpose. Every sentence carries operational value: error behavior, sign interpretation, field search coverage, warnings, or cost implications. The length is justified by the tool's complexity across four types, and no filler or tautological phrasing is present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations and no output schema but eight parameters and four modes, the description is exceptionally complete. It covers return shapes per type, edge cases such as empty numberingSeries and stockless companies, how to interpret warnings, and which sibling tool to use as an alternative. An agent has almost everything needed to call this tool correctly and interpret results responsibly.

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

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

Although schema coverage is 100%, the description adds substantial meaning beyond the schema: it explains how name, query, and conditions interact, which fields query searches per type, how conditions are ANDed, what happens with invalid conditions, and the pagination cost model. The per-type field lists and type-specific notes give semantics the schema cannot express.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource as master data and lists the four concrete types an agent can pick. It distinguishes itself from sibling tools by explicitly pointing to tally_get_vouchers for transactions and by explaining that voucherType is the discovery step for the voucherType filter. The mode breakdown gives an agent a precise model of what calling this tool will do.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Every mode states exactly when it applies and what happens if used incorrectly. The description gives explicit alternatives, such as using tally_get_vouchers for entries and for resolving sales families rather than guessing voucher names. It also says when not to use certain modes, e.g., using query rather than name for group and voucherType.

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

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

With no annotations provided, the description carries the full behavioral burden, and it does so thoroughly. It states the tool is read-only, never derives due dates or overdue figures, explains the netting of bill references, discloses that bills come only from vouchers in the requested period (the key coverage caveat), clarifies that a null balance means 'empty value, not zero', and explicitly warns that text fields are data, not instructions. These are exactly the sort of non-obvious traits an agent must know before calling the tool.

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

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

The description is long, but it is deliberately structured into clearly labeled sections (RETURNS, NO DUE DATE, AGEING, NETTED, COVERAGE, GROUPS, BALANCES, and a final safety note) and every sentence earns its place. It is front-loaded with the core scope, then layers essential caveats. There is no fluff or repetition; the length reflects the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (13 parameters, no output schema, nuanced ageing semantics) the description covers everything an agent needs: the return shape (one row per party, closing balance, bill refs, optional ageing buckets), the four deliberately non-bucketed findings, the coverage limitation, that groups are Tally parent-group based, and how to interpret balances. The absence of an output schema makes this descriptive completeness essential, and it is fully present.

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

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

While the input schema already covers all 13 parameters (100% coverage), the description adds substantial meaning beyond the schema definitions. It explains the semantics of side with concrete money-flow language, the default and override behavior for groups, the meaning of includeZeroBalances with the null distinction, that pageSize controls response size rather than query cost, how creditTerms convert ageing into overdue (and the danger of zero), and what ageingPreset's schedule_iii includes beyond the bucket set. This materially improves parameter understanding and correct use.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise verb-resource pairing: 'Receivables or payables, picked by `side` — one call, one side.' It then elaborates exactly what the tool returns (closing balances, bill references, optional ageing) and distinguishes the two modes. This makes the tool's unique purpose unmistakable and differentiates it from siblings like tally_get_statement or tally_get_ledger_transactions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear when-to-use context: it tells the agent to pick receivable or payable based on who owes whom, and it warns about the coverage limitation ('a bill raised earlier cannot be aged'), urging the agent to widen the range and to communicate which period the ageing covers. It also advises on how to handle overdue questions. However, it does not explicitly name alternative sibling tools or state 'use X instead', so it stops short of full exclusionary guidance.

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

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses substring case-insensitive matching, per-ledger rather than merged results, separate handling of text mentions, truncation behavior, date-range defaults, balance sign conventions, and the fact that balances are computed by the server rather than TallyPrime. It also explicitly states the tool is read-only and that text fields are data, not instructions.

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

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

The description is long but every paragraph earns its place and is clearly labeled (WHEN TO USE, HOW MATCHING WORKS, OTHER MENTIONS, RETURNS, PERIOD, LIMITS, BALANCES). The most decision-relevant information is front-loaded. The structure makes the density navigable rather than overwhelming.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter tool with no annotations and no output schema, the description covers everything needed: result shape, period resolution, limits, balance semantics, and even a security-relevant warning about treating text as data. There are no material gaps that would prevent an agent from selecting and invoking the tool correctly.

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

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

Although schema coverage is already 100%, the description adds significant meaning beyond the schema: 'Sai' finds separate ledgers as a concrete illustration, 'Supply both or neither' clarifies date usage, and the limit parameters gain truncation semantics via the 'truncated' flag. This helps an agent choose and set parameters correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb-resource combination: retrieving everything one party was paid or booked against across every matching ledger in one call. It clearly distinguishes itself from tally_get_ledger_transactions and explains its cross-ledger aggregation purpose. Example questions ('how much did X draw as salary vs professional fees') make the tool's intent unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The WHEN TO USE section explicitly names the target scenarios and quotes natural-language questions. It also names tally_get_ledger_transactions as the better alternative for a single known ledger, giving an agent an explicit routing rule. The matching and mention sections further clarify when this tool is appropriate.

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

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

With no annotations provided, the description carries the full burden, and it delivers rich behavioral detail: the operation is explicitly read-only, the report list is closed for provenance reasons, empty results are real answers but ambiguous, row shapes are unverified for some reports, and column names are deliberately not remapped. It also explains pagination behavior, period resolution, and failure semantics for a wrong company.

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

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

The description is long, but every section earns its place: purpose is front-loaded, report semantics are grouped, and critical caveats are clearly flagged with headers and emphasis. The structure makes the length navigable rather than bloated, and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter tool with no output schema, the description covers everything an agent needs: what each report returns, warnings about unverified row shapes, ambiguity of empty results, period rules, pagination semantics, read-only safety, and routing to sibling tools. Nothing essential is missing for correct invocation and interpretation.

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

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

The schema already covers all six parameters at 100%, giving a baseline of 3. The description goes beyond the schema by expanding the closed enum into meaningful report-by-report guidance, explaining that pageSize slices an already-complete fetch rather than controlling query cost, and clarifying the period default and company-failure behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly defines the tool as reading TallyPrime's built-in report views from a verified closed list, and explicitly positions it as the tool for exception and register views that have no dedicated sibling. It separates itself from tally_get_statement by directing main statements there, so an agent can tell which tool to pick.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to use this tool ('exception and register views that have no dedicated tool') and names the alternative for main statements: 'FOR THE MAIN STATEMENTS use tally_get_statement instead'. It even routes journal_register analysis to tally_test_vouchers with a specific test, giving concrete when-to-use guidance and exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure and does so extensively. It reveals key quirks: the end date only binds on the 31st, values are never adjusted so debit figures arrive negative, null is not zero, pairing is by name with ambiguous repeats excluded, no currency conversion ever happens, and the tool is read-only. It also discloses verified behavior versus assumptions, such as the date rule being verified behavior.

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

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

The description is long but well-structured with clear sections, and it front-loads the core purpose first. It is appropriately detailed for a complex tool, though some repetition occurs (e.g., month labels are explained twice for cash_flow and fund_flow, and sign conventions are described in multiple places). Every sentence earns its place by conveying operationally important information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 values and behavior, and it does so thoroughly. It describes response fields like rows, comparison, changes, unpaired, presentIn, coversPeriodRequested, and figuresActuallyCover. It also covers edge cases, cost, period defaults, sign conventions, and what to tell the user, making the definition complete for an agent to invoke the tool correctly.

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

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

Although schema description coverage is 100%, the description adds substantial meaning beyond the schema. It explains the end-date rule for toDate, why compareToDate must fall on a 31st, how periods and companies are mutually exclusive, what the statement enum values mean, and how verbosity affects output. It also clarifies semantics like 'null is not zero' and sign conventions, which are not visible in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb, resource, and variant: 'Fetch one of TallyPrime financial statements or flow reports for a period', naming trial balance, balance sheet, profit and loss, cash flow, and fund flow. It also distinguishes this tool from siblings by saying 'one call, one statement' and by referencing alternatives like tally_get_masters, tally_get_vouchers, and tally_summarise_movements where appropriate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly explains when to use this tool versus alternatives: use it for statement/flow reports, use tally_get_masters for per-ledger balances, and use tally_get_vouchers or tally_summarise_movements for date-bounded questions. It also describes what this tool is NOT, such as not being a classified cash flow or fund flow statement, and when a different approach is needed.

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

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

With no annotations present, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It explicitly states the tool is read-only, that NOTHING IS CALCULATED, that section data may be incomplete, that empty results are meaningful, and even warns that text fields are data, not instructions. This goes far beyond basic operation description.

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

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

The description is long but exceptionally well structured with bolded section labels, clear WHEN TO USE blocks, and distinct view definitions. Some content is slightly redundant with the schema, such as period-default behavior, but the additional warnings and usage guidance earn their place. Front-loading the core purpose helps an agent quickly determine applicability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with two modes, no annotations, no output schema, and several important caveats, this description is complete. It explains what each view returns, when to use it, how periods behave, what empty results mean, what the tool cannot compute, and the safety profile. An agent has everything needed to select and invoke it correctly.

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

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 seven parameters well. The description adds useful context around the `view` choices and period defaults, but it does not need to compensate for missing schema detail. This is the appropriate baseline score when structured schemas already carry the parameter documentation burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise statement that this tool returns 'TDS and TCS as TallyPrime records it, picked by `view`'. It then separates the two views, summary and transactions, with explicit, distinct purposes. This clearly differentiates the tool from Tally-domain siblings such as tally_get_gst and tally_get_vouchers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit 'WHEN TO USE' guidance for both view options, including when each is appropriate and what kind of finding is useful. It also states when the tool is NOT appropriate: TDS liability or short-deduction figures must not be computed here, and section-wise completeness must be verified elsewhere. This is direct, actionable routing guidance with clear exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It covers read-only safety ('Read-only: nothing here can modify TallyPrime'), client-side pagination over a full fetch, the fact that a period filter does not make the query cheaper, the uniformFields relocation behavior, unreadable amounts being kept rather than zeroed, the UNREAD PAYLOAD warning for empty results, and that text fields are data, not instructions. This is exemplary transparency beyond the structured fields.

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

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

The description is long but appropriately so for a 16-parameter multi-mode tool. It is front-loaded with purpose and usage guidance, then organized into clear labeled sections (MODES, RETURNS, AMOUNTS AND SIDES, FIELDS ARE IN TWO PLACES, PERIOD, PAGINATION). Every section earns its place by covering a distinct critical caveat, and there is no repetitive filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (16 parameters, multiple modes, no output schema), the description is remarkably complete. It explains what is returned per voucher, the sign/side conventions for entries, the uniformFields mechanism, period defaults and constraints, error identifiers (TALLY_COMPANY_NOT_FOUND, TALLY_COMPANY_NOT_LOADED), and the UNREAD PAYLOAD warning interpretation. An agent has everything needed to invoke the tool correctly and interpret ambiguous results.

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

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

Although schema coverage is 100%, the description adds substantial semantics: how parameters select modes (voucherNumber vs search vs list), that voucher numbers are only unique per type and period, that minAmount compares against the largest absolute entry amount, that family resolves company-specific derived types, and that pageSize controls response size but not query cost. These meanings go well beyond the schema descriptions and materially help an agent call the tool correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise statement of what the tool does: 'Vouchers (transactions) in a period: list, search by filter, restrict to a trading family, or fetch by exact voucher number — one call, one mode, picked by which parameters are given.' It names the specific resource (vouchers) and the operations, and explicitly distinguishes itself from tally_summarise_movements as the alternative when the answer is a total or trend. This clearly separates 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The WHEN TO USE section is explicit: use this tool to examine individual transactions, and use tally_summarise_movements instead for totals/trends. The MODES section further guides parameter selection, e.g., 'Reach for "fieldMatch" when the field NAME differs between companies, and for "family" over "voucherType" wherever the company may have renamed a built-in type.' This gives concrete decision rules rather than leaving usage to inference.

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

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

With no annotations, the description carries the full burden, and it does so thoroughly: it states read-only behavior, defines what is and is not returned, notes pagination is not applicable, and warns that text fields are data, not instructions. This greatly exceeds minimal disclosure.

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

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

Well-sectioned and front-loaded: the core action is in the first sentence, followed by compact labeled sections. Every line adds distinct value, from when-to-use to the data-safety note, with no repetition or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless read-only listing tool with no output schema, this is complete: return shape, date format, scoping limitation, pagination behavior, and safety posture are all covered. Nothing an agent needs to call or trust it is missing.

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

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

The tool takes zero parameters, so there are no parameter semantics for the description to clarify. It uses the space to specify the two returned fields—company name and ISO start date—which is all an agent needs for a parameterless tool. Baseline 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names a specific verb and resource—'list the companies TallyPrime currently has loaded'—and adds the distinctive detail that each company's books-start date is included. This is precise enough to distinguish it from generic getters and sibling reporting tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides an explicit WHEN TO USE section with two concrete use cases: confirming source data before analysis and checking spelling for another tool. It also gives a clear exclusion: companies not open in TallyPrime will not appear and must be opened in Tally itself, not fetched via a different query.

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

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

No annotations are provided, so the description must carry the full burden, and it does. It discloses that the tool re-runs the procedure, fetches data from TallyPrime ('It does not accept figures and format them — it queries TallyPrime again'), that it does not write the conclusion unless supplied ('Never fill this parameter with your own inference'), and that it is read-only ('nothing here can modify TallyPrime'). These behavioral traits go well beyond what a typical description would include, fully meeting transparency requirements.

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

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

Despite being long, the description is tightly structured with clear sections: the two kinds of paper, when to use, re-running behavior, conclusion handling, and return value. Every sentence adds necessary operational or behavioral context not elsewhere available. It is front-loaded with the core purpose and uses bold headers for scannability, making it dense yet concise—appropriate for the complexity of the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 23 parameters, two modes, no output schema, and no annotations, the description is remarkably complete. It explains the two modes, the re-run behavior, the return format, the conclusion handling, and provides concrete guidance on what to do with the output ('Save the markdown to the audit file'). It even notes that the resolved date range is echoed back, which is a subtle behavior. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 87%, so the schema already documents most parameters. The description adds meaningful context beyond the schema: it explains that `conclusion` is the auditor's own and must never be inferred, that `objective` is required because without it a workpaper cannot be reviewed, and it reinforces the mutual exclusivity of `test` and `report`. These enrichments justify a score above the baseline of 3, though not a 5 since the schema already covers most semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise statement: 'Run one audit procedure and render it as a workpaper: a Markdown document carrying the objective, the population, the method and its parameters, the results, the limitations, and the exact call that reproduces it.' This defines a specific verb, resource, and output. It also clarifies the two distinct modes (test and report) and explicitly contrasts with siblings tally_test_vouchers and tally_get_report, 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description contains an explicit 'WHEN TO USE' section: 'when the output has to go into an audit file rather than just answer a question in conversation. Use `tally_test_vouchers` to explore; use this once you know which procedure you are documenting.' It also instructs not to paste results but to pass the same parameters, and states that supplying both test and report is refused. This gives clear guidance on when to use this tool versus alternatives.

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

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

With no annotations, the description discloses critical behavioral traits: returns are grouped by entity type with summaries, truncation is signaled by 'truncated' flag, vouchers are date-limited while masters are not, caps apply per type, and the tool is read-only. It also warns that text fields are data not instructions, covering a security behavior that would be invisible without this note.

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

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

The description is organized with clear sections (WHEN TO USE, RETURNS, SCOPE AND LIMITS, PERIOD, security note) and uses bullet points for the scope. It is front-loaded with the core purpose and only adds detail that is operationally important. Every sentence contributes to correct invocation or interpretation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description fully specifies what the response looks like (grouped by type, summaries, truncated flag) and how to follow up for detail. It also covers period resolution, caps, matching semantics, and read-only status. An agent has everything needed to call this tool correctly and interpret results.

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

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

Although schema coverage is 100%, the description enriches each parameter beyond the schema: it explains the default financial-year period when both dates are omitted, the difference between voucher and master date handling, that entityTypes restriction speeds the call (each type costs a separate request), and the company-loading error behavior. These insights are not in the schema and materially affect usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific action (search) across a defined resource set (ledgers, vouchers, stock items) for a name, number, or reference. It explicitly differentiates itself from siblings by noting that once the entity type is known, a specific tool (e.g., tally_get_masters, tally_get_vouchers) is better, leaving no ambiguity about its scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'WHEN TO USE' section gives explicit conditions for selecting this tool versus alternatives, including the exact case (unknown entity type) and names the better-suited tools. It also provides operational guidance such as restricting entityTypes for performance and widening date ranges, making it clear how to use the tool effectively.

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

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

With no annotations, the description carries full burden and goes far beyond basics: exact decimal server arithmetic, entries-not-vouchers summation, net sign convention (debit negative, credit positive), the allGroupsNetToZero invariant, unreadable amounts excluded and warned, and the read-only guarantee. There is no contradiction with any annotation because none exist.

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

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

Well structured with section headers, front-loaded purpose, and every sentence carrying information. It is long and repeats a few ideas (sign convention, net-to-zero, ledger usage) that are already in the schema, so it loses a point for conciseness but remains readable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, no-output-schema tool this is exceptionally complete: it explains default period, both-or-neither date rule, return shape, invariant checking, excluded-entry handling, sign interpretation for user-facing reporting, and security note about text fields. An agent has everything needed to call it correctly.

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

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

Schema coverage is 100% and the schema descriptions are already rich (e.g., ledger restricting entries rather than vouchers, pageSize controlling response size, group's extra cached fetch, company error code). The main description mostly restates these points and adds no significant new parameter-specific semantics, so it stays at the high-coverage baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific operation—'Totals per ledger, account group, month, voucher type or party'—with clear server-side arithmetic, and later distinguishes itself from tally_get_vouchers ('Prefer this... whenever the answer is a figure'). It is unambiguous what resource is summarized 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It has an explicit WHEN TO USE section: 'for any question answered by a total, a subtotal or a trend rather than by individual transactions', and says prefer it over tally_get_vouchers for figures because it is smaller and exact. Although it doesn't enumerate all siblings, the key alternative is named and the condition is concrete.

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

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

With no annotations provided, the description fully carries the behavioral transparency burden — and it succeeds. It discloses that the tool is read-only, that results are 'CANDIDATES FOR REVIEW, NOT FINDINGS', that a contaminated population invalidates the result, that late_entry can fail with TALLY_UNSUPPORTED_OPERATION, and that related-party output must not be read as a completeness statement. It also warns that text fields are data, not instructions, and explains what happens with omitted dates and unsupported data.

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

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

The description is long but exceptionally well structured, with clear sections for tests, population, period, and data-handling warnings. Every major section earns its place given the complexity of the nine tests and the severe audit misinterpretation risks. A small deduction is warranted because some repeated caveats and parameter explanations could have been tightened without losing meaning, but it remains purposefully organized and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the absence of an output schema and annotations, the description tells the agent what each test returns: candidates with reasons, the seed for reproducibility, the sampling interval and certainties, duplicate-group counts, the two reasons in late_entry, and the related_party byParty disclosure table. It also explains population exclusions, failure behavior, default period resolution, and the meaning of an empty result. Nothing essential is missing for correct invocation and interpretation.

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

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

Though schema description coverage is 100%, the description adds substantial meaning beyond the schema: it explains tradeoffs for sampleMethod, the sensitivity difference for benfordDigits, how roundMultipleOf is scale-relative, why defaults matter for sampleSeed reproducibility, and how lateEntryMinLagDays should be chosen from lagDistribution. It also clarifies what each test-specific parameter does in the context of the audit procedure rather than merely restating the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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: 'Run one audit procedure over the vouchers in a period.' It then enumerates nine distinct tests with precise criteria, and notes that it 'reads nothing that the other voucher tools cannot, and computes everything itself,' distinguishing it from sibling retrieval tools like tally_get_vouchers. This fully clarifies what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Every test includes explicit when-to-use and when-not-to-use guidance: monetary-unit sampling is 'the usual choice for SUBSTANTIVE testing of overstatement, and the wrong choice for completeness'; Benford 'needs about 300 amounts'; cutoff is 'Proximity to the boundary, not evidence about it'; late_entry 'cannot support CARO Rule 11(g)'. It even directs users to read lagDistribution before choosing thresholds and to source threshold from tally_calculate_materiality and voucherType from tally_get_masters. This is exemplary usage guidance.

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