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

Annotations declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds substantial context beyond annotations: it explains the gate mechanism (balance_sheet_gate), refusal reasons, the unclassified ledger limit, stock item behavior, logging of receipt lines, and that nothing is written to Tally. This is exemplary transparency far 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 extremely dense and long, essentially a specification document embedded in the tool description. While information-rich, it is not front-loaded or concise; it reads as a single sprawling paragraph covering derivation, states, gates, and logging, making it hard for an agent to quickly extract the essential call 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?

Given the complexity of the tool and no output schema, the description is largely complete: it explains return structure (lines, amount with sum/present_count/empty_count, result.profit_and_loss, state), refusal conditions, and data sources. It is thorough, though its density and lack of structure slightly reduce usability.

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 0%, so the description must compensate. It explains the semantics of `to` as the closing-balance date and `from`/`to` as a date range window, and explains that company_guid bounds the read to one company. While the schema provides patterns and types, the description adds conceptual meaning (date boundaries, currency constraints) that the schema lacks.

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 and resource ('Return the Balance Sheet'), names the data source (Tally's native Trial Balance), and enumerates the exact primary groups returned. This clearly distinguishes it from siblings like trial_balance and profit_and_loss, which it references by name.

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?

Usage is implied through preconditions (observed INR currency, single company/mode book, supported date boundaries) and references to sibling concepts (Trial Balance, P&L A/c), but there is no explicit when-to-use-this-vs-alternatives guidance. The description explains the derivation rather than choosing between tools.

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?

Annotations declare readOnlyHint=true and destructiveHint=false, indicating no side effects. The description states 'Each call appends metadata-only receipt lines ... to ComplyEaze Bridge's local log on this computer,' which is a write-side effect and directly contradicts the readOnlyHint annotation.

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 dense and includes critical security context, but it front-loads warnings rather than the tool's purpose, and it repeats the local log concept. It is adequately sized but could be better structured for quick tool selection.

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?

With no output schema and one parameter, the description does describe the returned fields (tool, time, company, counts, fingerprints) and privacy limitations. However, it omits any explanation of the 'limit' parameter and contains an annotation contradiction, leaving gaps for correct invocation.

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?

There is one parameter, 'limit', with 0% schema description coverage. The description only says results are 'bounded to the most recent receipts' but never mentions the 'limit' parameter or how to control the number of receipts returned, leaving the parameter semantically undocumented.

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 states that the tool shows receipts of ComplyEaze Bridge's own tool calls, read from a local log, with specific fields listed. It distinguishes itself from Tally data tools by being an audit/egress log rather than a Tally query. However, the actual purpose is buried after two warning sentences, slightly reducing clarity.

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 explains what the tool shows and includes a communication warning ('Never tell the user that no data has left their computer'), but it never states when to call this tool versus alternatives, nor does it name any sibling tool for comparison. Usage context is implied at best.

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?

Annotations already declare read-only/non-destructive, but the description goes far beyond them: it enumerates every refusal cause, the count-then-read strategy for large books, the 400,000 mark refusal, currency handling, snapshot staleness ('up to 10 minutes old'), and states explicitly that it writes nothing to Tally and only appends metadata-only receipt lines locally. Nothing here contradicts 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.

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

The purpose is front-loaded in sentence one, which is good, but the body is a very long, densely nested wall of text mixing paging, counting, currency, GST and refusal semantics. Much of it is genuinely informative, yet the sheer size makes it hard to scan and pushes it past what a tool description should reasonably hold.

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 8 parameters, no output schema and 0% schema coverage, the description is remarkably complete: it documents the response fields, refusal causes, snapshot semantics and scope flags an agent would otherwise have to discover by trial. An agent could call this correctly without further 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?

Schema description coverage is 0%, so the description carries the full burden and does so richly: `as_of` format and date semantics, `fields` basic/compliance differences, `group` filtering, the full immediate-vs-ancestry meaning of `group_scope`, `offset` first-page behavior, and `snapshot_id` propagation. Only `limit` and `company_guid` are left unaddressed, which is a minor omission against an otherwise exhaustive treatment.

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 gives a specific verb and resource ('Return a company's ledger masters') plus the exact scope (each ledger's opening balance as of the start of the books) and names the concrete output fields. Combined with the name `ledger_masters`, an agent can tell this apart from `masters`, `validate_masters` and `ledger_movement` without opening a schema.

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 clear operational context: when to pass `as_of` (e.g. a transaction's date) versus reading `compliance.gst_registrations`, when `as_of` is refused, when to reuse `snapshot_id`, and retry guidance for count mismatches. It never explicitly compares itself to sibling tools like `masters` or `validate_masters`, so it stops short of the top band.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial behavior beyond them: INR currency-master requirement (refuses multi/none/non-INR books), full-window read before pagination, source-limit failure mode, ledger-name matching semantics, and the fact that it appends metadata-only receipt lines to a local log while writing nothing to Tally. This is unusually rich 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?

Front-loaded with the deliverable, and nearly every clause carries operational information (currency precondition, date-window behavior, logging side effect). It is a single dense block that would read better as short sentences, but little of it is wasted.

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 read tool with no output schema, the description describes the return shape (opening, movement, closing, voucher count, ledger_match with match mode, similar_ledgers), preconditions, failure modes, and side effects. An agent has what it needs to 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 0%, so the description must carry parameter meaning. It explains the ledger name resolution rules and the from/to window behavior, but says nothing about limit, offset, or company_guid semantics, leaving half the parameters undocumented. It partially compensates but leaves clear gaps.

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-and-resource: returns literal-window ledger opening, debit/credit movement, closing, and touched-voucher count. It is clearly a ledger-movement read, distinguishable from sibling list/aggregate tools like trial_balance or vouchers, though the phrasing is dense enough that the core purpose is buried in the first clause.

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?

Gives concrete usage guidance: reads the full voucher window before filtering or pagination, so 'use narrow dates', and warns dense windows can fail source limits. It does not name alternative sibling tools for related queries, so it stops short of explicit routing.

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?

Annotations already cover the safety profile (readOnly, non-destructive, not open-world), and the description adds non-obvious behavior: every call appends metadata-only receipt lines (tool, company, counts, fingerprints) to a local log, and it writes nothing to Tally. This is exactly the extra context annotations 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.

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

Front-loaded with 'Start here' and organized around the routing decision, so the important guidance comes first. It is dense and the trailing logging sentence adds length, but each sentence carries load-bearing information rather than 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?

With no parameters and no output schema, the description must carry both selection logic and return-content expectations, and it does so, including the company_guid contract and ambiguity flags. 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.

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

The tool takes zero parameters, so there is nothing to disambiguate and the baseline is 4. The description instead front-loads what the call returns (tuples with company_guid and ambiguity flags), which is useful but belongs to return semantics rather than 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?

States a precise verb+resource ('Return observed company tuples') and explains the payload's role by naming the exact field other tools need (company_guid). 'Start here' explicitly positions it as the entry point, distinguishing it from the many sibling read tools that require a company.

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?

Gives explicit decision rules: single open company with no named client -> use it; named client matching one open company -> use it; otherwise ask and offer the list. It also states an exclusion ('never guess a company'), leaving nothing to inference.

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

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

Goes well beyond the annotations: it discloses that unreadable folders are reported as partial evidence rather than empty, that no_dispatch_never_verified is not proof of absence, that the journal/imports folder must never be suggested for deletion, and that each call appends metadata-only receipt lines locally (consistent with idempotentHint=false). It also states explicitly that nothing is written to Tally.

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 purpose is front-loaded in the opening clause and every sentence carries substantive constraints. The single dense paragraph with stacked caveats is heavier than it needs to be, but little is genuinely wasteful.

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?

With no output schema, the description compensates by naming the fields an agent will encounter (incomplete_reason, folders_that_could_not_be_listed, no_dispatch_never_verified) and by delimiting what is and is not covered. Complete enough to call and interpret 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?

There are zero parameters, so the baseline is 4. The description usefully notes that it reads fixed local folders and names no file path, which is the only parameter-adjacent information an agent needs.

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 and resource — reporting what the local data store holds, by class, with counts, sizes, oldest-file age and import-journal state. It is clearly distinguished from siblings like tally_status and verify_import, which concern Tally-side posting rather than local storage.

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 defines scope boundaries (what folders are covered vs not) and warns how to interpret no_dispatch_never_verified, which is real usage guidance. But it never states when to reach for this tool instead of verify_import, read_evidence or tally_status, so the alternative-selection guidance is only implied.

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?

Far exceeds the annotations: it discloses the double-read consistency model, the 16 MB pre-read size refusal with concrete master_alter_id limits per kind, the row-count/AlterID/size premise checks, mask_parties masking behavior, snapshot reuse/refusal semantics, and metadata-only local receipt logging. None of this is derivable from readOnlyHint/destructiveHint/idempotentHint.

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?

Every sentence carries real information, but it is delivered as one dense, unstructured block with no headings or bullets, and several caveats (unmeasured NUMVOUCHERTYPES comparison, 10-minute staleness) are buried mid-paragraph. Front-loading the purpose is good; the rest is hard to parse for an agent that needs the key operational rules quickly.

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?

With no output schema, the description carries the full burden of describing return shapes per kind, the snapshot object, and error causes, and it does so thoroughly. For a tool this complex and this side-effect-sensitive, nothing an agent needs to call it correctly appears to be 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?

With 0% schema description coverage, the description compensates fully: it defines the kind enum values, explains that offset 0 takes a fresh read while offset > 0 is served from the in-memory snapshot, and specifies how snapshot_id must be passed and what happens when it is stale or absent. company_guid's scoping ('read inside one company, mode and book-extent bracket') is also clarified.

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?

Opens with a specific verb+resource ('List a company's masters of one kind') and enumerates exactly which kinds are available, including the row shape each kind returns. It also explicitly names the sibling it is not (ledgers -> ledger_masters), so an agent can distinguish it without opening a schema.

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?

Gives clear routing guidance ('ledgers (use ledger_masters)') and states exclusion conditions (whole reads only, education mode refused, one kind per call, one company). It does not, however, contrast with other master-related siblings such as validate_masters or voucher_schema, so the when-not guidance is incomplete.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, but the description adds substantial behavioral context beyond them: it states nothing is written to Tally, metadata-only receipt lines are logged locally, partial-read semantics and refusal codes are enumerated, and cost/limit behavior is described. There is no contradiction with 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.

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

The description is an enormous, dense wall of text with nested asides and repeated explanations of partial-read behavior. While the first sentence front-loads purpose, the bulk is far too long for a tool description and contains redundancies that could be trimmed or structured into sections.

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 10 parameters, no output schema, and complex partial/refusal behavior, the description is extremely complete. It covers return fields, paging, partial states, refusal conditions, cost limits, and detail semantics, so an agent has enough to call the tool correctly without an output schema.

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 0%, so the description must carry the full burden for 10 parameters. It explains as_of's default and return behavior, top ranking parties only, limit/offset paging, detail's enum values and required party, reference narrowing, direction sign rules, and party-name resolution rules. Only company_guid is left unexplained, which is self-evident as a required identifier.

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 states a specific verb and resource: answering what is outstanding via receivable and payable totals, ageing, top parties, and open bills from Tally's paired bills reports. It implicitly distinguishes itself from sibling financial reports like balance_sheet and trial_balance by anchoring the operation in Tally's bills reports.

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 extensive conditional guidance within the tool: when as_of is optional, when detail is required for party detail, when to name a reference, and how to page with offset/limit. However, it never names an alternative sibling tool or states when not to use this tool versus balance_sheet, trial_balance, or ledger_movement.

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?

Far exceeds the annotation baseline of readOnlyHint/destructiveHint. It discloses currency preconditions (multi-currency books refused), stock refusal, the full gate/`state`/`reason` taxonomy, the exception for the `Cost of Sales :` heading, measurement coverage limits, and that it writes metadata-only receipts locally while writing nothing to Tally.

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 purpose is front-loaded, but the remainder is a dense multi-hundred-word run-on packing refusal reasons, gate details, and edge cases into single sprawling sentences. Much of this belongs in structured fields (e.g., an output schema or error enum) rather than prose, hurting scanability.

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?

With no output schema, the description carries the full burden and does so thoroughly: it documents line shape, gross_result/net_result, state, reason values, unclassified handling, tie_out outcomes, and failure modes. An agent can anticipate nearly every return condition.

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 0% and none of the three parameters (company_guid, from, to) are named or documented in the description. It adds contextual constraints (single company/mode/book-extent, INR-only, supported date boundaries, multi-year windows unmeasured), but the caller still gets no per-parameter meaning, format, or example from the description.

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 gives a specific verb (Return), resource (Profit and Loss), and scope (date range), then immediately clarifies the derivation source (Tally's native Trial Balance) and the exact line structure. This distinguishes it cleanly from siblings like trial_balance and balance_sheet.

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?

Usage is implied through the derivation chain and refusal conditions, but the description never explicitly says when to choose this tool over balance_sheet or trial_balance, nor what a caller should do on `not_established`. The conditions for a successful read are detailed, yet the routing guidance is left 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?

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), yet the description adds substantial behavioral detail beyond them: refusal codes (`register_master_mark_unavailable`, `ledger_snapshot_drifted`, `voucher_window_changed_during_read`, `window_not_honoured`), the fact that each page re-reads masters so rows can shift, the `state` qualification rule, and the metadata-only local log write. This is exactly the extra context annotations cannot express.

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 an unusually long, single-block wall of text — roughly 600+ words with heavy repetition ('compliance read's refusals', 'never summed', 'not measured' stated more than once) and it front-loads an exhaustive negation list instead of the purpose. Much of the content is genuinely useful, but it is not appropriately sized and the key purpose statement is not 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?

There is no output schema, so the description must convey the return shape — and it does: per-row fields, the `status` precedence chain, the `state`/`reason` rule, every side list, refusal behavior, and known non-measured cases. Despite its verbosity, an agent has essentially everything needed to call the tool and interpret the response 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 0%, so the description must carry parameter meaning. It clarifies that `from`/`to` are a date window and that `offset`/`limit` page the rows 'like `vouchers`', and it warns that the full window is read before pagination. However it never explains `company_guid` and adds no semantics (format, bounds) for the paging parameters beyond what the schema pattern already implies. Partial compensation for the coverage gap merits a 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 description states a specific verb and resource: 'Return the Purchase and Debit Note vouchers of a date window that touch a ledger under Duties & Taxes,' and explicitly frames itself against siblings (not a GST return, see `ledger_masters`/`vouchers`). That is enough to distinguish it from `sales_register` and `vouchers`. It falls short of 5 because the positive purpose is buried mid-paragraph behind a long list of negatives, so the agent must parse several hundred words before learning what the tool actually returns.

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 clear context and numerous exclusions (does not decide input tax credit eligibility, does not match GSTR-2B, does not check GSTIN, does not sum tax) and advises 'use narrow dates' because the full window is re-read. It routes the agent to `ledger_masters` and `vouchers` and defers the return-classification choice to the CA. It lacks a crisp single 'use this when / not when' statement and never names a directly competing sibling as the alternative, keeping it at 4.

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?

Annotations declare readOnlyHint=true, yet the description states 'Each call appends metadata-only receipt lines ... to ComplyEaze Bridge's local log on this computer' — a side-effecting write to the local environment, which contradicts a read-only hint (and is consistent with idempotentHint=false). The description is otherwise unusually rich (egress disclosure, masking limits, in-memory bounding), but the stated write side effect directly conflicts with 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.

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

The content is dense and every sentence is relevant, but it is not front-loaded: the opening sentence is a privacy caveat rather than the tool's purpose, and the actual 'Shows ... recent reads' statement is buried mid-paragraph. For a one-parameter tool the ~120 words could be ordered far better.

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?

With one optional param, no output schema, and annotations present, the description covers what is returned (fingerprints, byte counts, state, no figures/book content), the memory-bounded window, and side effects. The main omissions are the default limit value and the readOnlyHint conflict, but an agent has enough 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 description coverage is 0%, so the description must carry the parameter. It does explain the sole parameter: the result is 'bounded: the newest `limit` records,' clarifying that limit selects the newest N records. It omits the default (20) and any upper bound, but the core semantic is supplied.

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: it 'Shows ComplyEaze Bridge's own recent reads since it started,' including 'request and response fingerprints, byte counts and state.' That is a concrete, distinguishable purpose. However, it never explicitly names the siblings it differs from (e.g. egress_log, local_data_report), so it stops short of full sibling differentiation.

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 no explicit when-to-use/when-not guidance. The only directive ('Never tell the user that no data has left their computer') is a behavioral prohibition, not a usage rule, and there is no indication of when an agent should call this instead of egress_log or local_data_report. Usage must be inferred from the content of what it returns.

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?

Despite annotations already covering readOnly/destructive/idempotent/openWorld, the description adds substantial context: enumerated refusal codes (register_master_mark_unavailable, ledger_snapshot_drifted, window_not_honoured), the fact that pages re-read masters so rows can shift, sign conventions (negative = debit, Credit Note signs not flipped), the measured/not_measured_live marking scheme, and that it writes nothing to Tally but appends metadata-only receipt lines locally. This is unusually rich 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 an enormous wall of text in which the core purpose appears roughly mid-way, after a long list of things the tool does not do. Content is dense and much of it is genuinely relevant for a complex tool, but the structure is poorly front-loaded and heavily redundant, so it fails the conciseness bar.

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?

With no output schema and a highly complex, stateful read, the description compensates by enumerating every returned row group (tax_in_books, duties_taxes_entries_without_gst_head, taxable_entries, side lists, status/state rules), the state machine (complete/partial), and edge cases. An agent has essentially everything needed to interpret the result.

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 0% across 5 params, so the description must carry the load. It does convey that from/to define the date window, that offset/limit page like vouchers, and it references company context, but it never specifies the date string format, the meaning of company_guid, or limit/offset defaults. Partial compensation, so a 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 description ultimately states a specific verb+resource: 'Return the Sales and Credit Note vouchers of a date window that touch a ledger under Duties & Taxes,' and sharply distinguishes itself from purchase_register and vouchers. However the actual purpose is buried under a long preamble of exclusions, and the opening sentence ('a register of what the books record, not a GST return') is more negation than definition. Clear once found, but not front-loaded.

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 real usage context – 'use narrow dates', routes other voucher types to other_voucher_types_touching_duties_taxes, and notes cost varies by book. But it never explicitly frames when to pick this over purchase_register or vouchers; selection guidance is implied rather than stated, and the bulk is behavioral caveat rather than when/when-not.

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?

Far exceeds the annotations: it discloses refusals and their causes, snapshot/paging semantics with a 10-minute staleness window, masking behavior under mask_parties, size limits (~874 master mark, 16MB premise), the read-twice consistency rule, and the metadata-only local receipt log. The annotations only declare readOnly/openWorld/idempotent/destructive hints, so the description carries real additional behavioral value.

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 purpose and the three `state` values are front-loaded, which is good, but the body is an exceptionally dense wall of text that mixes state semantics, refusals, paging, masking, limits and provenance. Given the tool's complexity much of it is load-bearing, but it is not economical and is hard to parse on first read.

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 this is remarkably complete: it enumerates every `state`, every refusal cause, per-field `checks` semantics, the `inventory` flags, tie-out behavior, and paging. An agent has essentially everything needed to call and interpret the tool, with the sole caveat of unmeasured release/date coverage being explicitly acknowledged.

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?

With 0% schema coverage the description must compensate, and it does: it explains `as_of` accepted formats and the 31 March / book-start / today constraints, that `items` is 1–50 GUIDs filtering the held read, and that `snapshot_id` is the first page's id to force `listing_snapshot_changed`. `limit` and `offset` are only implied through the paging narrative (offset 0 = first page), leaving a small gap.

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 verb and resource ('Return the stock summary: the closing stock value per stock item as of a date') and further scopes it against Tally's own Stock Summary. It clearly distinguishes itself from sibling reporting tools like trial_balance and balance_sheet, which are referenced only for sign convention.

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 strong conditional guidance: when results are 'for investigation only', when a read is refused (Education mode, inventory off, oversized book), and the constraints on `as_of` (must be 31 March). However, it never explicitly routes the agent between this tool and sibling alternatives such as trial_balance or balance_sheet, so it stops short of a full 5.

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?

Goes well beyond the annotations: single-request-at-a-time concurrency across all Bridge processes, a ~10 second bounded per-call wait, the tally_endpoint_busy and tally_endpoint_lock_unavailable failure modes, the retry_after_s field, and the metadata-only local receipt log with an explicit 'writes nothing to Tally' guarantee. This is exactly the behavioral context annotations cannot carry.

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?

Front-loads purpose well, but the body is a dense run-on spanning error codes, retry rules, and a `today` explanation that mostly concerns outstandings and ledger_masters rather than this tool. The date discussion is scope creep on a zero-parameter status probe and dilutes the core message.

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 no-param read-only probe with no output schema, the description covers failure modes, retry policy, and side effects (local receipt log, no Tally writes) adequately. It never describes the shape of the returned status/identity tuple, which is the one remaining gap.

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?

Zero parameters, so the baseline is 4; the description instead documents the derived `today` value (this computer's calendar date, YYYYMMDD) that other tools consume. That is useful context but is not parameter semantics for this tool itself, so it stays at baseline rather than exceeding it.

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 and resource: 'Return loopback endpoint status and observed loaded-company identity tuples.' An agent can tell this is a health/status probe distinct from the data-reading siblings, though the phrasing is jargon-heavy and no sibling is named as an alternative.

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?

Explains the contention model clearly and when refusals occur (another ComplyEaze Bridge process holding the port), plus what to do: retry after retry_after_s for reads, and for post_import only when attempt_recorded is false, otherwise follow verify_import. It does not explicitly frame which situations should trigger calling this tool first, so it stops short of full when/when-not 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?

Far exceeds the annotation baseline: it discloses currency-scoping behavior, that totals are not expected to balance, empty-amount preservation, snapshot caching mechanics with concrete staleness bounds, refusal codes, and metadata-only receipt logging with an explicit 'writes nothing to Tally'. This is unusually rich 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?

Front-loads purpose well, but the body is a dense wall of parenthetical detail (field names, protocol section references, staleness anecdotes) that is hard to scan. Most sentences carry real behavior, but the volume works against quick selection.

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?

With no output schema, the description compensates by naming the returned structures (ledgers_scope, foreign_currency_ledgers_excluded, base_currency_ledgers_mixed_excluded, totals_scope, snapshot). An agent has enough to interpret the response without opening anything else.

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 0%, so the description must carry the load, and it does for most: from/to as a date range, offset semantics (offset 0 vs offset > 0), snapshot_id pass-through, and 'pagination limits output only' for limit. company_guid is never explained, leaving one gap.

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?

Specific verb and resource: 'Return native ledger-wise Trial Balance for a date range, using Tally's TBAL fields without scanning vouchers.' The 'without scanning vouchers' clause implicitly separates it from voucher-reading siblings, but no sibling (balance_sheet, profit_and_loss) is named to make the choice explicit.

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?

Prerequisites are stated (INR base currency, supported date boundaries) and the snapshot_id usage pattern is spelled out. However, when to choose this over sibling reports like balance_sheet or profit_and_loss is never addressed, leaving the core selection question 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?

Annotations only cover the safety profile (readOnly, non-destructive, non-idempotent), leaving the description to disclose the real behavior – it does so richly: match_state semantics, that near-misses are never resolved, candidate bounds (25 names / 8192 bytes), the lower-bound count flag, truncation reporting, and metadata-only receipt logging. The append-per-call logging is consistent with idempotentHint=false, so 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.

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

The purpose is front-loaded, but the body is an extremely dense run of jargon-heavy clauses (near_miss, candidate_count_is_lower_bound, fingerprints) crammed into few sentences with poor scannability. Every sentence carries content, but structure could be far cleaner.

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 complex, non-trivial tool with no output schema, the description covers return behavior (match states, candidate lists, truncation, lower-bound counts) thoroughly. The only meaningful omission is any explanation of the required company_guid parameter.

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?

With 0% schema description coverage, the description must compensate; it partially does by specifying ledgers constraints (1–100 entries, nonblank, max 1024 chars each). But company_guid – a required parameter – is never explained anywhere, leaving a real gap.

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 verb (bind/validate) and resource (ledger names against the live catalogue) are stated specifically, and the description carves out clear scope by noting only `exact` results are admitted by build_import_xml and that nothing is written to Tally. An agent can distinguish this from sibling tools like masters or ledger_masters without opening a schema.

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?

Usage context is clear: it is a pre-import validation step, and only `exact` results pass downstream to build_import_xml. However, it never explicitly names an alternative sibling tool or states when NOT to use this one, so the routing guidance is implied rather than spelled out.

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 annotations present, the description adds substantial depth beyond them: it explains local proof-file writes, status-record creation, possible baseline and masters-check saves, paging via persisted proofs, specific refusal conditions, and that Tally is never written to. This is rich behavioral context that goes well beyond readOnlyHint=false and destructiveHint=true.

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 a dense, run-on block with nested parentheticals and semicolon-chained clauses. The first sentence front-loads the purpose well, but the remainder is very difficult to parse and is far longer than necessary for an agent to select and invoke 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?

Given the tool's complexity, absent output schema, and the available annotations, the description is complete enough: it covers return fields, paging, truncated/next_offset, error refusals, proof persistence, and local file writes. An agent has what it needs to call 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 0%, so the description must compensate for four parameters. It explains offset and proof_sha256 clearly, and gives context for batch through 'the batch's date window' and 'batch's saved proof files,' but company_guid is never mentioned. Partial compensation justifies a mid-range score.

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 names a specific verb and resource: 'Read back a manually imported local batch and write Proof-of-Post files.' It also distinguishes itself from an import-dispatch tool by stating it 'never dispatches import XML to Tally.' The purpose is unambiguous and not a restatement of the tool name.

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 explains how to page an existing proof using proof_sha256 and offset, which is useful procedural guidance. However, it does not say when to choose this tool over sibling verification or reporting tools, nor does it name alternatives or exclusions beyond the 'never dispatches import XML' limitation.

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?

Beyond the readOnly/destructive annotations, it discloses side effects (appends metadata-only receipt lines to a local log, writes nothing to Tally), resource risk (reads the full window, dense windows can fail source limits), and error conditions (supplying only one narration identity component is an error). It also explains limitations of the marker scheme and that correcting a voucher creates duplicates.

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 purpose is front-loaded in the first sentence, but the remainder is one very long, densely parenthetical paragraph with run-on clauses. Much of the detail earns its place given the tool's complexity, yet the packing reduces scannability and could be structured better.

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 complex comparison tool with no output schema and 0% schema coverage, the description is thorough: it defines the presence values, the complete/partial window semantics, the decision basis, error cases, and side effects. It is nearly complete, though pagination behavior and the company_guid parameter remain unaddressed.

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 0%, so the description carries the burden and largely succeeds: it explains numbering_method values (manual/automatic/unknown), how voucher_number and the batch_id/bridge_txn_id pair form the decision basis, and that date/party/amount only produce candidates. However, it never clarifies the limit/offset pagination parameters or company_guid, leaving part of the schema undocumented.

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 precise verb and resource: answer which of 1-500 proposed vouchers already exist in the book. It differentiates itself from siblings by explicitly naming verify_import as the tool for natively posted batches, which this tool cannot identify.

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 routes the agent explicitly: use verify_import for natively posted batches, and it explains the conditions that yield complete vs partial and present/possibly_present/absent. It also states exclusions (native posts, older-scheme writes, client remote identifiers), which is exactly the when-not guidance 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?

Far exceeds the annotation bar: it discloses snapshot reuse and the up-to-ten-minute staleness window, why later pages can shift rows, the exact refusal causes (listing_snapshot_changed, voucher_window_part_not_admitted, voucher_type_ambiguous, unknown_voucher_type, voucher_type_guid_foreign), withheld foreign-currency vouchers, and the absent-means-not-observed convention. This is exceptional behavioral disclosure for a read tool whose only annotations are readOnlyHint/destructiveHint/idempotentHint.

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?

It is a single enormous run-on paragraph of well over a thousand words with no headings or bullet structure, mixing snapshot internals, selector rules, edge cases and logging into one block. Some length is warranted by the complexity, but the total is far past what an agent can parse efficiently and the lead is not cleanly 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 having no output schema, it explains return shape (items, total, state/reason, coverage, snapshot, earlier_snapshot, withheld_vouchers, voucher_types, ledger_match) and enumerates failure modes and edge cases thoroughly. For a 10-parameter, high-complexity read tool this leaves almost nothing an agent needs to infer.

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?

With 0% schema coverage across 10 parameters, the description carries the full burden and largely does: it defines limit/offset semantics (limit does not reduce Tally work), the snapshot_id contract, ledger spelling rules with ledger_match, the three mutually-exclusive type selectors, and date equivalence. company_guid is left unexplained, but the rest is richly specified well beyond the bare schema types.

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 states a specific action (return voucher evidence for a date window) and the body distinguishes this tool from the sibling voucher_presence by noting neither filters post-dated/optional/cancelled vouchers. However, the lead phrase 'literal-window voucher evidence' is jargon-heavy and the core purpose is buried under snapshot mechanics rather than stated cleanly up front.

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 strong parameter-level routing guidance (prefer voucher_class or voucher_type_guid over voucher_type, use narrow dates, dense windows are unqualified) and mentions voucher_presence, but never frames when to choose this tool over the many sibling listing tools (sales_register, purchase_register, ledger_movement) that overlap in scope.

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?

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false. The description adds valuable context beyond annotations by detailing that each call appends metadata-only receipt lines to a local log, specifies what data is logged, and confirms no writes to Tally. It does not violate any annotations.

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 two sentences, front-loads the purpose, and includes relevant behavioral details without unnecessary verbosity. It is appropriately sized for a zero-parameter 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?

Given the tool's simplicity, no parameters, and no output schema, the description provides sufficient information about what it returns and its side effects. There is no output schema, so the description covers the essential return behavior.

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?

With zero parameters, the baseline is 4. The description does not need to explain any parameters, and it appropriately focuses on the tool's behavior rather than parameter 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 clearly states the tool returns a fail-closed local voucher-file schema and explicitly says no Tally request is sent. It distinguishes itself from siblings like vouchers or voucher_presence by emphasizing the local schema-return behavior, though it does not name any specific sibling.

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 no explicit guidance on when to use this tool versus alternatives. It implies usage by stating it returns a schema and writes a local receipt, but provides no conditions, prerequisites, or exclusions.

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