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

Annotations already declare readOnly, idempotent, and non-destructive, so safety is covered. The description adds the useful caveat that no native GL-by-account endpoint exists, but omits pagination, ordering, or volume expectations for what could be a large line set.

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?

A single dense sentence that front-loads the resource definition and appends the rationale in a parenthetical. Efficient with no filler, though the density slightly taxes readability.

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 an output schema and annotations present, the description needn't explain returns or safety, and the no-native-endpoint note adds valuable framing. But the two date parameters remain entirely unexplained, which is a real gap for a filtering 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 coverage is 0%, so the description must carry parameter meaning. It clarifies that 'account' is a chart-of-accounts key, adding real value beyond the bare 'string' schema, but from_date and to_date receive no explanation at all, leaving half the parameters 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 states a specific resource (structured Lines[] entries for a given Account) and scopes it as the closest available per-account general ledger view. This distinguishes it from siblings like ledger_transactions and general_ledger_summary, though it lacks an explicit verb.

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 its role as the substitute for a missing native GL-by-account endpoint, which implies when to reach for it. However, it names no sibling alternative and gives no explicit when-not or comparison against ledger_transactions/general_ledger_summary.

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/openWorldHint/idempotentHint, and the description reinforces read-only while adding a genuinely non-obvious behavior: the tool rejects the from_date/to_date inputs it appears to accept. It still says nothing about result scope or limits, but with annotations covering the safety profile this is solid added context.

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?

Three short sentences, front-loaded with the core scope, then the exclusions, then the alternative. Every clause carries distinct information with no repetition.

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?

Output schema exists, so return values need not be explained. Combined with annotations and the explicit parameter-rejection note, an agent has everything needed to call this correctly and to choose it over reconstructed_aged_payables.

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 both parameters are undocumented in the schema, but the description compensates by telling the agent that from_date/to_date are rejected outright — precisely the information needed to avoid misusing them. It does not explain accepted formats simply because none are accepted.

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 the specific resource (CURRENT supplier balances) and explicitly disclaims what the name would imply (not an aged report), then names the sibling reconstructed_aged_payables as the alternative. An agent can distinguish it from the rest of the ledger/report family without opening any schema.

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

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

Gives explicit exclusions ('not as at any past date; rejects from_date/to_date') and routes the agent to the correct alternative for the as-at case. Both when-to-use and when-not-to-use are covered with the sibling named.

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, idempotentHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds a non-obvious behavioral fact the annotations do not carry: that the tool rejects from_date/to_date despite those parameters existing in the schema.

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

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

Three short clauses, front-loaded with the primary scope statement, followed by the negative constraint and the alternative. Every clause carries distinct information with no repetition of the name or title.

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?

An output schema exists, so return-value explanation is unnecessary, and annotations cover the safety profile. Combined with a clear scope, an explicit exclusion, and a routing alternative, the definition gives an agent 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 0%, so the description must carry the burden, and it does the crucial part: it declares that from_date/to_date are rejected, telling the agent these two parameters must be omitted. It does not explain accepted value formats, but since both parameters are unusable that gap is moot.

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 the exact resource and scope: 'CURRENT customer balances only (read-only)'. It pre-empts the natural misreading of the name 'aged_receivables' by explicitly disclaiming that it is not aged, and names the sibling tool that is.

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-not guidance ('Not an aged report and not as at any past date') and routes the agent to the correct alternative ('For a labelled as-at reconstruction use reconstructed_aged_receivables'). Nothing about tool selection 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 declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that: the data is raw rows with no account column, which tells the agent the shape of the result. It still says nothing about pagination, truncation, or how date filters affect output.

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?

Two dense, front-loaded sentences with no filler, and the disambiguation is placed where it matters. It is arguably too terse for the parameter burden it leaves unaddressed, but nothing 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?

Output schema exists, so return values need not be explained, and annotations cover safety. However, with undocumented date parameters and an unclear notion of what 'raw rows' contain, a calling agent lacks enough context to use the tool confidently.

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?

Two parameters (from_date, to_date) exist with 0% schema description coverage, so the description carries the full burden — yet it never mentions dates, filtering semantics, or accepted formats. This is a clear gap where the description should have compensated.

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?

Names a specific resource (raw /balance-sheet-transactions rows) and immediately disambiguates it from Manager's Balance Sheet and from reconstructed_trial_balance. The lack of an explicit verb is minor since 'rows (read-only)' implies retrieval. An agent can distinguish it from siblings, though 'raw rows' is somewhat abstract.

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 explicit negative guidance ('NOT Manager's Balance Sheet') and routes to the alternative ('see reconstructed_trial_balance') for the account-per-row case. There is no positive statement of when this tool is the right choice, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds genuine provenance context (results are assembled from ReceivedIn receipts, PaidFrom payments, and transfers, with no standalone bank-transaction entity), which is useful beyond the annotations, but it says nothing about ordering, pagination, or volume limits for a potentially large ledger-derived read.

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?

Two sentences, no filler, with the core purpose front-loaded before the explanatory note about data assembly. Every clause earns its place.

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?

Because an output schema exists, return-value detail is not required, and the provenance note covers the conceptual model well. However, with 0% schema coverage on three parameters and no routing guidance versus siblings, an agent still lacks enough to invoke this confidently in ambiguous cases.

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 three parameters, so the description must compensate and largely does not. It never mentions bank_account_key or its expected form/key type, and never explains from_date/to_date semantics (inclusive? defaults? format), leaving the date-window parameters undocumented in both places.

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/resource: money-in/out for a single bank or cash account, and even discloses how the data is assembled (receipts, payments, transfers). It is clear what the tool returns, though it does not explicitly differentiate itself from close siblings such as bank_balances, account_ledger, or 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?

There is no when-to-use guidance and no named alternative, despite several plausible siblings (bank_balances, account_ledger, ledger_transactions). The second sentence clarifies why no direct transaction entity exists, which explains the tool's design but does not tell the agent when to choose this over those 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine behavioral value beyond them by warning that date arguments are rejected and that only current balances (not historical) are returned. It does not mention auth requirements or rate limits, which keeps it from a 5.

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

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

Two sentences, zero filler, with the scope constraint and read-only nature front-loaded before the routing guidance. Every clause earns its place.

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?

An output schema already exists, so return values need no explanation. Combined with the read-only annotation and the explicit sibling routing, the definition gives an agent everything needed to select and invoke this tool correctly.

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

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

Schema coverage is 0% and the two date parameters have no descriptions in the schema. The description partially compensates by warning that dates are rejected, which is important disambiguation, but it never explains the expected format or behavior of from_date/to_date, leaving the presence of those params in the schema unexplained.

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 resource (current bank/cash balances) with an explicit scope qualifier ('CURRENT ... only') and marks it read-only. It is immediately distinguishable from balance_sheet, trial_balance, and bank_activity without opening any schema.

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

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

Explicitly names the alternative path for drill-down ('use list_records/get_record on bank_accounts') and states the exclusion ('rejects dates'). An agent knows both when to call this tool and when to route elsewhere.

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 readOnly, idempotent, non-destructive, openWorld behavior, so the safety profile is covered. The description contributes beyond that by disclosing the detection methodology (structured Key references only, never free-text descriptions), which materially affects result interpretation and is not derivable from 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?

Front-loaded with the detection target, then a clarifying example and a scope caveat. Dense but every sentence carries information; the em-dash construction is slightly harder to parse than it needs to be.

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?

An output schema exists so return values needn't be explained, and annotations cover safety. However, for a query tool with a required, undocumented 'resource' parameter and no date-filter guidance, the definition leaves the agent guessing on invocation, which is a real 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?

Schema description coverage is 0% and the description says nothing about any of the three parameters. In particular the required 'resource' parameter is entirely opaque - no hint whether it is an entity type, a resource name, or a scope selector - and from_date/to_date semantics are unexplained.

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 precise detection target: payments/receipts whose structured AR/AP invoice-Key line reference fails to resolve to a current invoice. It adds the framing 'the general form of a missing invoice' with a concrete supplier-payment example, which distinguishes it from sibling finders like find_unallocated_transactions and verify_invoice_balance.

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 rather than stated: the tool is for hunting dangling invoice references, and the closing sentence ('Never uses the transaction's free-text description') implies a scope boundary, but no sibling is named and no explicit when-to-use/when-not guidance is given.

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, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely useful behavior beyond that: the strict all-fields-must-match rule and the 'unresolved' bucket for partial matches, which an agent would otherwise not know.

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?

Two tight sentences, front-loaded with the matching key and followed by the failure-mode caveat. 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?

An output schema exists, so return values need not be described. But with a required 'resource' parameter carrying no definition at 0% schema coverage, the definition leaves a real gap an agent must guess at before invoking.

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% and the three parameters (resource, from_date, to_date) are undocumented in both schema and description. 'Date' appears in the matching key, hinting from/to_date scope a transaction set, but the required 'resource' parameter — its accepted values or meaning — is left entirely unexplained.

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?

Names a specific verb+resource ('duplicate detector') and defines the exact matching key: Customer/Supplier + Reference + Date + total + line signature. This is far more specific than sibling list/find tools and immediately distinguishes it from find_records and find_broken_invoice_references.

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 clarifies the boundary condition that partial matches are returned as 'unresolved' and never flagged as duplicates, which implies usage. However, it never explicitly states when to choose this over find_records or what preconditions (e.g., data already imported) apply.

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 read-only, idempotent, non-destructive, and open-world profile. The description adds useful behavioral detail beyond annotations: the filter is client-side, every field must match exactly, and fuzzy/partial/amount-only matching is not supported. It does not contradict the annotations.

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

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

The description is front-loaded and compact, covering purpose, mechanism, filter shape, and matching restriction in a few sentences. There is slight redundancy between 'every field must match exactly' and 'Never does fuzzy/partial/amount-only matching,' but nothing 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?

The description adequately covers the critical exact-match semantics and client-side nature. With an output schema present and rich annotations, return values and safety behavior need not be repeated, though resource and max_pages remain weakly explained.

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. It explains the filters object format well, but resource and max_pages receive no semantic explanation, leaving two of three parameters 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 this tool performs an exact-match structured filter over a collection, including the filters shape and the client-side mechanism. It distinguishes itself from fuzzy or partial matching but does not explicitly differentiate itself from sibling tools like list_records or get_record.

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 context for when the tool applies (exact field-value matching) and an explicit exclusion (never fuzzy, partial, or amount-only matching). However, it does not name an alternative tool to use when fuzzy matching or other query types are 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?

Annotations already cover the read-only, idempotent, non-destructive profile, and the description adds meaningful limits beyond them: matching is based on the structured Name field and never on any transaction's free-text description, and results are never treated as the suspense account automatically. This is useful behavioral context about false positives and confidence level.

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?

Two compact sentences with no filler; the matching heuristic is front-loaded and the caveats follow immediately. Every clause carries information the agent needs.

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?

An output schema exists, so return-value documentation is not needed, and with zero parameters the description has no schema gaps to fill. The definition covers purpose, matching rule, and the confidence caveat, which is everything an agent needs to invoke it correctly.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies a no-argument, full-chart scan, which is consistent with the empty 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?

States a specific verb (find) and resource (chart-of-accounts rows), plus the exact matching criterion (structured Name matching placeholder-account naming like suspense, uncategorised, clearing). This distinguishes it clearly from the find_unallocated_transactions and find_broken_invoice_references 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?

Frames the output as candidates for human confirmation only, which tells the agent this is an advisory step in a workflow rather than an authoritative lookup. It does not name alternative tools or state explicit when-not conditions, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds the semantic meaning of 'unallocated' but nothing about result size, pagination, or how date bounds affect output. With annotations carrying the behavioral load, this is weak but not contradictory.

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 short and front-loaded, but it is a noun fragment rather than a complete statement, so its brevity reflects under-specification rather than efficient conciseness. It conveys one fact and omits everything else an agent needs.

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?

An output schema exists, so return values need not be explained. However, for a parameterized find tool with one required and two optional parameters, the description supplies no invocation context, no date-range semantics, and no routing to alternatives.

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% and the description never mentions from_date, to_date, or resource. The required 'resource' parameter is particularly ambiguous and is undocumented in both places, so the description does nothing to compensate.

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 fragment identifies a specific resource and condition: receipts/payments lacking AR/AP invoice allocation on any line. That scope clearly separates it from siblings like find_duplicate_transactions or find_broken_invoice_references. It stops short of a verb ('List/Find'), so it reads as a definition rather than an action.

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 when-to-use guidance, no prerequisites, and no mention of alternative sibling tools such as find_records or ledger_transactions. The reconciliation use case must be inferred entirely from the tool name.

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, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely useful behavioral context: it is a single-pass check, it aggregates across all transaction types, and it discloses what the two named outputs are meant to signal — exactly the kind of value-add expected when annotations carry the safety profile.

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

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

Two dense sentences with zero waste. The core operation is front-loaded, and the second sentence immediately explains how to read the two key outputs without preamble.

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?

An output schema exists, so return-value explanation is not owed, and the description does cover the aggregation logic and output interpretation. The gap is the date-range parameters, which are undocumented in both schema and description, leaving the agent to guess how to scope the check.

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% and the description never mentions to_date or from_date at all — no format, no inclusivity, no default behavior. For a date-range tool where both parameters are the only knobs, the description fails to compensate for the documentation gap 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?

States a specific verb+resource — a single-pass general-ledger consistency check that sums Lines[] Amount (or Debit-Credit) grouped by Account across all transaction types. This is clearly distinct from siblings like trial_balance or account_ledger, though the description never names an alternative to sharpen the contrast.

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 interpretation guidance — 'overall_net should be ~0 in a balanced ledger' and 'per_account_net surfaces accounts worth investigating' tell the agent what results mean, but there is no explicit statement of when to reach for this tool versus trial_balance or account_ledger, and no 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the parenthetical '(read-only)' merely repeats structured data. The only added signal is that exactly one item is returned, with no mention of not-found behavior, permissions, or rate limits.

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?

A single short sentence, front-loaded with the verb and resource, with no filler. It is arguably too terse to be maximally useful, but nothing in 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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. For a one-parameter getter, however, the total absence of key format guidance and usage context leaves the definition at minimum-viable rather than complete.

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% for the single fixed_asset_key parameter, but 'by key' does communicate that the argument is an identifier rather than a name or filter. No format, source, or example of the key is given, so the description only partially compensates.

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 (fetch) and resource (Fixed Asset form) scoped to a single item by key. It is clearly a single-record getter, distinguishable from list_resources/list_records, though it never names a sibling explicitly.

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 when-to-use guidance, no statement of when this is preferable to find_records or get_record, and no prerequisites. The agent must infer usage purely from the name.

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, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds useful context that retrieval goes through a Manager form endpoint and that certain resources lack a single form, but says nothing about failure behavior or what happens for unsupported resources.

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 the core action in the first clause and appends two short caveats; no filler. The sentence fragment at the end is terse but still informative.

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?

An output schema exists, so return values need no explanation. However, with 0% parameter coverage and no enum, the description leaves the accepted resource vocabulary and the error case for form-less resources underspecified for a lookup tool with many sibling resources.

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% with two bare, undescribed parameters, so the description carries the burden. It partially compensates by implying key is a GUID and by naming valid resource values (bank_accounts, bank_balances, chart_of_accounts), but it does not enumerate the full set of accepted resource strings.

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 ('Fetch one collection record by GUID via Manager form endpoint') and implicitly separates itself from the list_/find_ siblings by being the single-record fetch. The endpoint example clarifies the underlying mechanism, though it never contrasts itself explicitly with list_records or find_records.

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 real routing advice: chart_of_accounts has no single form, and bank/cash detail should go through resource=bank_accounts rather than bank_balances. That covers when-not-to-use for two cases, but gives no general condition for choosing get_record over find_records or list_records.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real value beyond them: it clarifies the response contains settings not calculated rows and that the key cannot be discovered through this tool — operational context annotations don't 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?

Three sentences, front-loaded with the read-only scope, then the parameter hints, then the constraint. No filler and nothing repeated from structured fields.

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 an output schema present, return values need no explanation. The description covers purpose, the non-obvious key-availability constraint, parameter formats, and the absence of write behavior — everything needed to invoke it correctly.

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

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

Schema coverage is 0%, so the description carries the burden and largely does: report_type is illustrated with 'aged-receivables' and 'trial-balance' and the '-form' suffix exclusion, and key is identified as the definition GUID. It stops short of full syntax detail but compensates well for a 0% 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?

States a specific verb and resource (GET of a stored report definition) plus a sharp scope boundary: settings only, never calculated rows. This cleanly separates it from siblings like aged_receivables or trial_balance that return computed data.

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 operative precondition — there is no list endpoint, so the key must already be known — and gives a report_type format hint. It doesn't explicitly name a sibling alternative to use instead, which keeps it short of a 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description still adds genuine behavioral value by stating there is no Manager API call, that results are local process introspection, and that restart detection hinges on pid/start-time rather than git_sha. It stops short of describing latency, caching, or failure modes, so a 4 rather than 5.

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 core purpose, then the enumerated output fields, then the usage rationale, so the important content comes first. The final sentence is long and parenthetical, packing three ideas at once, which slightly hurts scannability but each clause still carries 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?

An output schema exists, so return values need not be re-explained, yet the description still frames them usefully for the restart-confirmation use case. For a zero-parameter, read-only diagnostic tool, the definition gives an agent everything it needs to decide to call it and 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?

The tool takes zero parameters, so there is nothing to disambiguate and the baseline is 4. The description correctly implies a no-argument invocation with no options or filters available.

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 (identify) and resource (the manager-mcp process you're connected to), then enumerates exactly what is returned: version, source path, git commit, pid, start time, tool count, transport, scopes. The scope is narrow and self-differentiating from the ledger/report siblings, which an agent could never confuse with a process-introspection 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?

Explicitly states when to call it (after a source edit + reload, to confirm the new code is live) and why that moment matters, including the fallback signal (pid and process_started_at change on a real restart even when git_sha does not). This is a textbook when-and-why instruction rather than implied context.

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 read-only/idempotent/destructive status, and the description adds genuinely non-obvious behavior: Manager ignores dates on this endpoint so from_date/to_date are filtered client-side, the full ledger is fetched, and completeness is reported. The default/max pagination bounds (500/5000) are additional operational detail not in 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?

Dense but front-loaded: source/scope first, then date-filter caveat, then pagination, then exclusions. Every sentence carries information; it is packed but not padded.

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 an output schema present, return-value explanation is unnecessary, and the description covers fetch/completeness behavior and the client-side date filtering. The remaining gap is explicit mapping of the 11 filter parameters, which is partly implied by the field enumeration but not stated.

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 carries the burden. It adds date format (YYYY-MM-DD), and skip/limit defaults and max, plus names the ledger fields (account, counterparty, tax, reference, bank_account, transaction_type) that likely correspond to filters, but it never explicitly states that account/customer/supplier/tax_only/reference are filter parameters, leaving half the semantics to inference.

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/resource: historical transaction data from the /transactions ledger, GET only. The closing exclusions ('Not a finished report; not an as-at balance') carve out clear boundaries against the sibling reconstructed/report tools, and the row-field enumeration (account, type, counterparty, tax, debit/credit, signed amount) makes the content concrete.

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 context: GET-only, raw ledger rather than a report or as-at balance, with pagination defaults. It does not explicitly route the agent between this tool and the similarly-named sibling account_ledger or general_ledger_summary, 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: it reads only the local audit log and makes no Manager API call, plus the resume semantics of apply. No contradiction with annotations, though it does not describe pagination or staleness of the local log.

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 resource definition, then the return fields, then the resume and no-API notes. Slightly dense with parenthetical tool names, but every clause carries usable 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?

An output schema exists, so return-value details are not strictly required, yet the description usefully previews the payload (invoice key, repointed transactions, remaining). Complete enough to invoke and interpret safely; only minor operational details (log freshness, volume) are absent.

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, which is the baseline-4 case. Nothing is needed beyond confirming the call is argument-free, which the empty schema already implies.

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 resource: reconstruction attempts that started but did not complete. It even names the producing tools (propose_*_invoice_reconstruction / apply_*_invoice_reconstruction), so an agent can distinguish this from siblings like find_broken_invoice_references without opening any schema.

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

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

The line about calling apply again with the same proposal_token resuming from exactly this state makes the intended use case clear (inspect resumable work before re-applying). It stops short of explicit when-not-to-use guidance or a named alternative, so it is strong context rather than a full routing rule.

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, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds the meaningful domain scope and the open-ended 'writable domains when present in discovery' caveat, but says nothing about pagination limits, ordering guarantees, or result shape.

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?

Three tight fragments, front-loaded with the core capability, then the domain list, then the disambiguation hint. No padding, though the 'writable domains when present in discovery' clause is a bit elliptical.

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?

An output schema exists so return values need not be described, and annotations cover the safety profile. Still missing for a paged search endpoint: how skip/page_size interact, ordering behavior, and how results relate to the other find_* tools.

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 6 params, so the burden falls on the description. It does add real value by enumerating valid values for the required 'resource' parameter (which has no enum in the schema), but skip, page_size, term, sort_by and sort_by_desc are left entirely unexplained.

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 concrete verb+resource ('search/page a curated collection') and enumerates the actual collections covered (customers, suppliers, sales_invoices, etc.), which tells an agent exactly what is reachable. It also differentiates from one sibling by contrasting bank_accounts with bank_balances, though it does not distinguish itself from find_records or get_record.

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 only implied by the domain list plus one explicit routing hint ('use bank_balances for snapshot balances'). There is no guidance on when this tool beats find_records/get_record, nor on prerequisites, even though several sibling lookup tools overlap.

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, idempotent, non-destructive, closed-world), but the description adds non-obvious behavior: a default read-only set of 30 tools, task tools appearing only when write scopes match, and CRUD tools being deprecated unless raw scope is set. This scope-dependent registration behavior is real context beyond the annotations.

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

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

Three short sentences with no filler, and the core purpose is front-loaded ahead of the scope-dependent behavior details. Efficient, though the middle sentence is slightly compressed and could be clearer.

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 an output schema present, the description needn't explain return values, and it sensibly focuses on what the listing contains and how it varies by scope. Given a 0-param discovery tool, this is largely complete, with only the sibling-routing gap remaining.

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 no parameter semantics for the description to explain; the schema coverage is 100% and the description's role here is limited. Baseline for a 0-parameter tool is 4.

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 verb and resource ('List curated Manager.io capabilities'), but 'capabilities' vs the tool name 'list_resources' leaves ambiguity about what is actually being listed. It doesn't distinguish itself from the sibling get_server_info, which an agent would also treat as a discovery/meta 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?

The sentences describe the conditional contents of the returned list (write scopes, deprecated CRUD), not when an agent should call this tool versus alternatives like get_server_info or list_records. No explicit when-to-use or when-not-to-use guidance is given.

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 readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds real behavioral context beyond that: it is a catalogue with no parameters, it classifies legacy report tools by representation (current state vs raw feed vs reconstruction), and it scopes what categories the entries have. Return formatting itself is not described, but an output schema exists.

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?

Two sentences, front-loaded with 'Read-only catalogue of Manager report types:' followed by a colon-led enumeration, then a second sentence on legacy classification. No filler, though the first sentence packs four clauses into one dense run.

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 zero-parameter lookup tool with an output schema and full annotation coverage, the description supplies enough: what the catalogue contains, what dimensions it classifies, and that it maps report types to MCP tools. It stops just short of stating whether the catalogue is static or must be re-fetched, which is a minor 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 per the baseline rule a 4 is appropriate; there is nothing for the description to disambiguate. Schema coverage is nominal at 100% with an empty properties object.

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 resource (catalogue of Manager report types) and enumerates exactly what it covers: API representation type, date parameters, application-only views, and the MCP tool for each. An agent knows this is a meta/lookup index rather than a data-fetching tool. It does not explicitly contrast itself with a close sibling such as get_report_definition, so it falls short of a 5.

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 mention of 'which MCP tool covers each' strongly implies the routing use case (consult this before picking a report tool), but there is no explicit when-to-use instruction or when-not/exclusion guidance. Usage is inferable rather than stated.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered and the description's '(read-only)' is largely redundant. It does add one useful behavioral distinction — raw underlying rows versus a reconstructed/Manager report — but says nothing about return shape, filtering behavior, or volume.

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?

Two short clauses, front-loaded with what the tool returns, then the disambiguation. Every word earns its place; 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?

Output schema exists, so return values need not be explained, and annotations cover the safety profile. However, for a two-date-range report tool the description leaves the date-filter semantics entirely unspecified, which is a meaningful gap 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?

Two parameters (from_date, to_date) exist at 0% schema description coverage, and the description says nothing about them — no date format, no default/inclusive semantics, no mention that they are optional. With non-zero undocumented params the 0-param baseline of 4 does not apply, so the description fails to compensate for the 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?

Names the specific resource (raw /profit-and-loss-statement-transactions rows) with a verb-like scope marker ('Raw'), and explicitly distinguishes itself from the similarly named sibling reconstructed_profit_and_loss. An agent can tell these two apart without opening either schema.

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

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

Explicitly states when NOT to use it ('NOT Manager's Profit and Loss Statement') and routes the agent to the alternative (reconstructed_profit_and_loss). It does not give a positive condition for when raw rows are the right choice, but the negative routing is clear and actionable.

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 openWorldHint=true, meaning the tool may interact with an open world of external entities, yet the description emphatically states it is composed 'entirely from Manager's own transaction data (no external system is consulted)'. This directly conflicts with the annotation, constituting an annotation 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?

Three tightly packed sentences with the read-only, period, and data-source facts front-loaded. Dense but each clause carries signal; the em-dash caveat about non-fabricated totals is well placed and earns its space.

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?

An output schema exists so return values need not be described, and the description adds useful output-quality context (exception Manager Keys, raw feeds, explicit notices instead of fabricated totals). However, it omits any usage framing and leaves the date parameters unexplained, so it is only minimally complete for a report 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?

The two date parameters (from_date, to_date) are documented at 0% schema coverage, so the description must carry their meaning. 'PERIOD' weakly implies date-range filtering, but no format, semantics, or default behavior of the parameters is explained, leaving the schema and description jointly inadequate.

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+resource, the 'Read-only PERIOD reconciliation report,' and clarifies its data provenance (Manager's own transactions). An agent can tell it produces a period-scoped reconciliation, though it never names or distinguishes itself from close siblings like trial_balance or the reconstructed_* family.

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-to-use, or alternative-tool guidance. The word 'PERIOD' hints that a date range selects this tool, but nothing tells the agent why to prefer it over ledger_transactions, trial_balance, or the reconstructed reports.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a genuinely useful caveat ('authoritative: false'), but defers all other caveats to another tool's description rather than stating them, leaving the agent to fetch them separately.

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?

A single dense sentence with no filler, and the resource scope is front-loaded. The parenthetical caveats are compressed but readable, and nothing 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?

An output schema exists, so return values need not be explained, and the non-authoritative status is flagged. But the missing date format, the undocumented include_zero flag, and the deferred caveats leave gaps for a data-producing tool with zero schema description coverage.

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% for two parameters. The description's 'as at a date' loosely maps to as_at but gives no format syntax, and include_zero (default false) is not mentioned at all, so the description fails to compensate for the schema 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?

States a specific verb+resource (reconstructed aged payables), the source ledger (/transactions), and the as-at scope. It explicitly distinguishes itself from Manager's Aged Payables report and points to its sibling reconstructed_aged_receivables, so an agent can identify it without opening the schema.

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

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

The 'NOT Manager's Aged Payables report' note implicitly tells the agent when to prefer the authoritative sibling aged_payables, and the reference to reconstructed_aged_receivables implies shared applicability. However, there is no explicit when-to-use/when-not statement or prerequisite listing, so usage must be inferred.

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, idempotent, non-destructive), and the description adds real value beyond them: it is derived rather than authoritative, ages by transaction date with oldest-first allocation, and returns a control-account total with a party-sum reconciliation check. Only minor gaps remain (e.g., no rate/size behavior), which the output schema covers.

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?

Dense but front-loaded: the identity and the authoritative=false caveat come first, followed by the aging method and return shape. Every clause carries information, though the sentence is long and packs several distinct facts.

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 annotations and an output schema present, the description is not obligated to restate safety or return values, and it does cover trust level and methodology well. The unresolved gap is parameter meaning for as_at and include_zero at 0% schema coverage, which leaves the definition incomplete 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?

Schema description coverage is 0% for two parameters, and the description does not compensate: 'as at a date' loosely hints at as_at but gives no format, while include_zero is never mentioned at all. An agent must guess at both the date format and the default-inclusion 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?

States a specific verb+resource (reconstructed aged receivables), the source ledger (/transactions), and the aging method (transaction date, oldest-first allocation). It explicitly distinguishes itself from Manager's Aged Receivables report and, by naming the reconstructed variety, from sibling aged_receivables.

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?

Clearly signals when this tool is appropriate by contrasting it with the authoritative Manager's report and warning 'Never treat as official', which steers the agent to it only for ledger-based reconstruction. It does not, however, name the specific alternative (aged_receivables) the agent should call when it wants the official figure.

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 readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds substantive behavioral context they don't: the result is non-authoritative, derived from the /transactions ledger, and lacks the group layout of a formal 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?

A single dense sentence with no filler; the reconstructed/non-authoritative caveat is front-loaded so the agent sees the key distinction immediately.

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?

An output schema exists, so return values need not be explained, and the description covers scope, source, and the non-authoritative caveat. The only real gap is date-parameter semantics for the two required arguments.

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 both required parameters (from_date, to_date) are undocumented in the schema. The description only says 'for a period,' adding no format, inclusivity, or timezone semantics, so it fails to compensate for the coverage 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?

Names a specific operation (reconstructed P&L), the grouping dimension (by account), the time scope (a period), and the underlying data source (/transactions ledger). It explicitly distances itself from the sibling profit_and_loss ('not Manager's Profit and Loss Statement'), so an agent can route correctly.

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

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

The 'authoritative: false' flag plus 'not Manager's Profit and Loss Statement' gives clear context for when this tool is the right choice versus the authoritative sibling. It stops short of an explicit routing instruction ('use profit_and_loss when...') or exclusions, so it is clear but not fully prescriptive.

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 read-only/idempotent/non-destructive, but the description goes well beyond them: it discloses the underlying data source, that balance sheet accounts are cumulative while P&L accounts span period_start..as_at, that earlier P&L is collapsed into one prior-periods line, and that the output includes a debit=credit check. This is exactly the behavioral context a derived report 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?

Dense but front-loaded, leading with the tool's identity before the computation rules. The semicolon-chained clauses risk a run-on, but nearly every clause carries distinct, useful information rather than padding.

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?

An output schema exists, so return values need not be explained, and the description supplies the essential computation semantics, the non-authoritative caveat, and the debit/credit verification note. Minor omissions remain (accepted date format, whether as_at is inclusive), but the 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 coverage is 0%, so the description must carry the load, and it largely does: as_at defines the balance date, and period_start is described with its default (1 Jan of the as_at year, flagged as an assumption) plus how it scopes P&L accounts. It does not specify date string formats or inclusivity, leaving a modest 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?

Starts with a specific verb and resource ('RECONSTRUCTED trial balance from the /transactions ledger as at a date') and explicitly contrasts itself with the sibling trial_balance ('not Manager's Trial Balance'). An agent can distinguish it from both trial_balance and the other reconstructed_* tools without opening another 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?

The 'authoritative: false; not Manager's Trial Balance' clause gives clear context for when this tool is the right pick (a derived, non-authoritative view) and implicitly routes to the authoritative alternative. It lacks an explicit 'use this when / not when' statement, so it falls short of full 5-level 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 declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that these are 'raw' rows and not a VAT return, which is useful domain context, but it also asserts 'No date support' without clarifying it against the date parameters in the schema, leaving behavior ambiguous rather than fully disclosed.

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?

Two terse clauses, front-loaded with the resource identity and followed immediately by the exclusion and the alternative. Zero 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?

An output schema exists, so return-value explanation is not needed, and the description covers purpose plus the key alternative. However, the unresolved tension between 'No date support' and the from_date/to_date parameters is a real gap for a tool an agent must call 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 carries the full burden for from_date and to_date — yet it says 'No date support,' which directly conflicts with the presence of those two date-named parameters. Rather than explaining whether the dates are ignored, clamped, or unsupported, it leaves the agent with a contradiction it must guess about.

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 resource ('Raw /tax-summary-transactions rows') and immediately qualifies scope with '(read-only)'. It also explicitly names the sibling it is not for ('not a VAT return') and the sibling to use instead, so an agent can distinguish it from the ~30 other reporting tools 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 an explicit when-to-use alternative: 'for dated tax rows use ledger_transactions with tax_only=true.' That is a routing decision with the condition spelled out, which is exactly what this dimension rewards.

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, idempotentHint, and destructiveHint=false, so 'read-only' in the description is largely redundant. The genuinely additive disclosure is the row shape ('no account per row'), which tells the agent what the payload looks like — useful, but no mention of volume, pagination, or filtering 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?

Two short fragments, front-loaded with the resource and the key disambiguation. Efficient, though the '/trial-balance-transactions' notation and compressed phrasing make it slightly cryptic.

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?

An output schema exists, so return structure need not be explained, and the description usefully warns about the missing account column. However, with zero schema description coverage, the date-range parameters and their effect on results are left entirely 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% and the two date parameters (from_date, to_date) are nullable strings with no enum, format, or description. The description says nothing about how dates are supplied or whether they filter results, so it fails to compensate for the coverage 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?

States the specific resource (raw /trial-balance-transactions rows) and explicitly distinguishes itself from two neighbors: Manager's Trial Balance report and reconstructed_trial_balance. An agent can route between these without reading any other definition.

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 the negative case ('NOT Manager's Trial Balance report and no account per row') and names the alternative tool (reconstructed_trial_balance) for the account-per-row need. It does not state a positive when-to-use condition, but the contrast with siblings is unusually explicit.

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, idempotent, non-destructive, and open-world. The description adds valuable context: it self-computes from Lines and allocated receipt/payment lines and deliberately ignores any 'balance' field on the form. This reinforces independence and reliability, though it doesn't cover error handling or permissions.

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?

Two sentences, front-loaded with the core computation. The parenthetical '(its own Lines)' is slightly dense but earns its place by clarifying scope. No filler or repetition.

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 description explains the computation method and trust model, and output schema covers return values. However, with 0% parameter descriptions and no usage guidance, the agent lacks key invocation details. Given the rich annotations and simple two-param schema, it's adequate but leaves significant gaps.

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 the description never explains the 'resource' or 'key' parameters. An agent must infer that resource is likely 'invoice' and key is an invoice identifier, but no format or allowed values are given. The description fails to compensate for the empty 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?

States a specific computation: invoice total vs. allocated receipt/payment lines, and names the comparison basis. The agent knows it's a balance verification tool, not a generic record fetch. No sibling differentiation is provided, but its unique focus on invoice balance makes it distinguishable.

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?

No indication of when to use this tool versus alternatives like find_broken_invoice_references or get_record. The description explains what it computes but not the scenarios or prerequisites for invoking it. Implied use for verifying invoice balances is the only guidance.

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