NL Ledger

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

Annotations already establish the full safety profile: readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false. The description adds one useful behavioral detail — that it returns the 'full text' of a single record as opposed to a list or snippet — but says nothing about size limits, rate limits, or what happens when the id is stale or invalid.

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 sentence with no filler, front-loaded with the verb and carrying four distinct pieces of information: full text, one result, from search, by id. Nothing could be removed without losing content.

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 one-parameter, read-only, non-destructive fetch with no output schema, the description covers what the agent needs to select and invoke it. The only mild gap is that 'full text' and the shape of the returned payload are left unstated, which matters little given the annotations already establish the safe-read nature of the call.

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

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

There is a single parameter with 100% schema description coverage ('Id from search.'), so the schema already carries the parameter semantics and a baseline of 3 applies. The description restates the same constraint ('by id', 'from search') without adding format, validity, or sourcing detail beyond it.

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

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

The description gives a specific verb and resource: 'Fetch the full text of one result from search, by id.' That is far more informative than the bare name 'fetch'. However, it does not distinguish itself from similar-looking siblings such as get_body and get_record, which an agent could plausibly confuse for this same operation.

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 phrase 'one result from search' signals that this is the follow-up step after a search call, and the 'by id' phrasing implies the id must originate from that search. There is no explicit when-not guidance and no sibling (get_body, get_record, search) is named as an alternative, so the agent must infer the 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 establish this is a safe, idempotent, closed-world read operation. The description does add genuinely useful domain caveats beyond annotations—award values are not payments and overlapping/federal sources stay labelled—which help prevent misinterpretation, but it says nothing about result size, year coverage, or pagination.

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 compact sentences with no filler, and the core resource description is front-loaded. The domain caveat and the omission clause are both earned.

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 covering safety and no output schema, the remaining gaps are modest: name handling is only implied and sibling differentiation is absent. For a single-optional-parameter read tool the caveats provided are largely sufficient.

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

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

The schema has a single parameter at 0% description coverage, so the description must compensate. It does partially by explaining that omitting name lists bodies and implying name selects a specific body, but it never states the expected name format or matching 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?

It states a specific resource (a public body's reported values, by year and source, plus largest suppliers) and notes it matches the body's page. It does not, however, distinguish itself from overlapping siblings like get_totals, get_supplier, or get_department.

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 final clause 'Omit name to list bodies,' which describes two modes of one tool rather than when to choose this over alternatives. No alternatives are named and there are no exclusions, so an agent has weak routing guidance among 14 siblings.

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 a read-only, idempotent, closed-world, non-destructive operation, but the description adds substantive behavioral context: the two bases must not be summed, only whole_government yields surplus/deficit and net debt, results are sorted largest-difference-first, and every figure carries a source link. It stops short of describing pagination or error behavior, but the added disclosure is well beyond what the annotations provide.

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

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

The most important content (what is returned, the two non-additive bases, the default-year rule) is front-loaded, and the dense single paragraph is information-rich rather than padded. It is slightly long and would benefit from breaking the data-base caveat into its own sentence, but every clause carries weight.

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

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

With no output schema and two optional parameters, the description carries the return-value burden and does so well: it enumerates the returned quantities and explains the two reporting bases and their limitations. It omits return format and error/degenerate cases, but for a read-only reporting tool 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 100%, so both parameters (year, department) are already documented, and the description's note on omitting year and the partial-name matching for department largely restates the schema. It adds the ordering of department results ('largest difference first'), which is a useful but marginal addition over the schema baseline.

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

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

The description names a specific resource and enumerates exactly what is returned: budgeted vs actual spending, the difference, surplus/deficit, net debt, and per-department comparisons. It also distinguishes its two underlying data bases (modified cash Estimates vs audited Public Accounts), which lets an agent understand the tool's scope without opening siblings.

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

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

It gives an explicit usage rule ('Leave out year for the latest year with published results') and the temporal boundary (years from 2019-20; newest budgets have no results yet). It does not compare against sibling tools like get_totals or get_department, so it falls short of naming 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 establish the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely useful behavioral scope beyond them: the availability window of actuals (2019-20 to 2024-25) versus estimates (2025-26, 2026-27), which tells the agent what data can exist. No contradiction with annotations.

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

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

Two sentences, front-loaded with the core verb and resource, and every clause carries information (grain, comparison basis, year scope, mode switch). The first sentence is dense with stacked comma clauses, which slightly hurts scannability but is not 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?

For a read-only tool with two optional parameters, full schema coverage, and annotations carrying the safety profile, the description covers what an agent needs: the returned grain, the year availability, and the omit-name listing behavior. Absence of an output schema is a minor gap since 'by program' only hints at the returned structure, but nothing required to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by adding meaning the schema omits — the full valid year range and the actual-vs-estimates distinction tied to the year parameter, plus the omit-name behavior. It does not restate the name-matching semantics, which the schema already covers.

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 and resource and pins down the exact data grain: a provincial department's gross spending by program, showing actual against amended and original estimates. That precision makes it easy to distinguish from a generic budget or totals call, but the description never names or contrasts the closely overlapping siblings (get_budget, get_totals, get_pay), so it stops short of full sibling differentiation.

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

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

Gives concrete usage context: it states the valid fiscal-year scope and the important mode switch, 'Leave out name to list the departments and years,' which tells the agent how to get department enumeration instead of a single department. It offers no when-not guidance or explicit alternatives to the similarly-named budget/totals tools.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds useful behavioral context beyond the annotations: it says the result explains why people look at the pattern, how it is computed, what it cannot tell you, and its largest results. It does not cover auth or rate limits, but it meaningfully describes the tool's informational scope.

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 front-loaded sentence identifies the operation, then a colon-delimited list efficiently previews the returned content. There is no wasted wording, and the key routing information appears first.

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 one-parameter read tool with full schema coverage and annotations covering safety, the description supplies the missing context: what the returned pattern details include. No output schema exists, so the description appropriately previews the return content and limitations.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by stating that the id comes from list_flags, which tells the agent where to obtain a valid id beyond the schema's example ('no-competition').

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 one pattern by id.' It also distinguishes itself from the sibling list_flags by naming the id source and contrasting one pattern with the list operation. An agent can tell immediately what the tool returns and how it differs from list_flags.

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 parenthetical '(from list_flags)' clearly signals that this tool is used after finding an id via list_flags. It does not spell out an explicit when-not-to-use rule, but the alternative and prerequisite are clear enough for correct routing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the ranking-with-average behavior and the group switch, but says nothing about pagination, result size, or return shape. Adequate against the annotation coverage, not rich.

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

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

Three tight sentences, front-loaded with the primary ranking behavior and followed by the two mode switches. No redundant or filler text; only a slight density cost from packing multiple modes into one paragraph.

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 read-only, no-output-schema tool with four optional parameters, the description covers both operating modes, the grouping dimension, and the category filter. It leaves return structure unstated, but with no output schema that is a minor gap rather than a blocking one.

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

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

Schema coverage is 100%, so the baseline is 3. The description earns a point for explaining how parameters interact rather than just restating them: supplying name changes the tool from a ranking to a single-individual lookup, and group changes the population from MHAs to ministers. That behavioral coupling is not expressed in the schema.

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

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

The description names a specific verb (rank) and resource (Members of the House of Assembly by allowance spending), and clearly splits the tool into two modes: ranking with an average, versus a single member when a name is supplied. It does not explicitly distinguish itself from siblings like get_totals or get_pay, but the expense-ranking scope is unambiguous.

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

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

It states the trigger conditions well: no name gives a ranking with the average, providing a name yields one member's spending, and group=ministers switches to minister expense claims. Missing is any explicit exclusion or naming of the alternative sibling tools for related queries.

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 closed-world, so the safety profile is covered. The description adds genuinely useful data semantics beyond that: the $100,000 threshold that explains coverage gaps, and the warning that 'Missing lists are not zero; this is not total payroll' — a correctness caveat an agent would otherwise get wrong. Return shape and pagination are not described.

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?

Four compact clauses, front-loaded with the scope and threshold, then the caveat, then the two usage instructions. No sentence is filler, though the telegraphic first clause is slightly harder to parse than a plain verb-first sentence would 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?

For a two-optional-parameter tool with no output schema, the description covers purpose, scope caveats, a mode switch and a sibling route. It still omits the shape/size of the returned pay table and any pagination or result-limit behavior, which the agent cannot learn from a missing output schema or from the bare parameter definitions.

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 both parameters, and it largely does: 'by employer and calendar year' maps employer and year to filter semantics, and 'Omit employer to list employers' explains the optional employer parameter's special omitted-mode behavior. Year's expected format (YYYY) is left to the schema pattern rather than stated.

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 the resource precisely — published pay above $100,000 broken down by employer and calendar year, with people, common titles, overtime and severance — so an agent knows exactly what data set this returns. The verb is implicit (carried by the name get_pay) rather than stated, and the first clause is a dense noun list, but the scope is unambiguous and it explicitly separates itself from the individual-level sibling ('Individuals use search_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?

It gives a concrete mode switch ('Omit employer to list employers') and names an alternative tool with the condition that selects it ('Individuals use search_records'). That is real when-to-use routing, though the boundary against other aggregate siblings like get_totals or get_budget is not addressed.

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 value beyond that: it enumerates the returned fields and discloses a non-obvious domain behavior ('Federal amounts have no automatic provincial scaling').

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 action and identifier requirement, then the return contents. The long field list is dense but earns its place because there is no output schema to document returns.

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

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

With no output schema, the description appropriately compensates by enumerating what is returned and flags the federal/provincial scaling caveat. It is complete enough to invoke correctly for a simple single-record read, with only the absence of explicit sibling routing as a 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 100% and the single id parameter already documents the 12-character hex pattern with an example. The description's restatement of '12-character id' adds little beyond what the schema encodes, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('Get one line item by its 12-character id'), which cleanly separates it from the list-style sibling search_records. It is clear about what is retrieved, though it does not name which sibling to use instead for other lookups.

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: the agent infers it should call this when it already holds a single 12-character id rather than searching. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g., search_records) as there is in stronger sibling definitions.

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 establish the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add context it doesn't already have. It does: overlap/exclusion policy, all-years scope, breakdown dimensions, and the notable behavior that unmatched names return close matches rather than failing.

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 front-loaded sentences with little waste, and the scoping caveats come early. The breakdown list ('source, amount kind, period, native currency and location evidence') is dense but earns its place by describing the return shape in the absence of an output schema.

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

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

With no output schema, the description carries the burden of return-shape disclosure and does so via the breakdown enumeration, and the annotations cover safety. Minor gaps remain in what 'included' precisely means and how excluded/unreported values are obtained, but the core invocation picture is 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 coverage is 100%, so the two parameters are already documented, giving a baseline of 3. The description nonetheless adds meaning beyond the schema by stating that either name or supplier_id is acceptable and that unmatched names fall back to fuzzy close matches, which is not captured 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 with scope ('get included reported record values, all years, for a supplier or recipient') and explicitly disambiguates by negating what it is not ('not everything received, unique spending or spending in NL'). It does not name a specific sibling (e.g., get_totals, search), so the differentiation is by description rather than routing.

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 negative statements ('These are not everything received, unique spending or spending in NL') give implied when-not boundaries, and it explains how to supply a name or supplier_id. But there is no explicit guidance on when to prefer this over get_totals, get_record, or search, so usage is inferred 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 establish readOnly/idempotent/non-destructive/closed-world, so the bar is lower; the description still adds real behavior beyond them: grouping splits results separately by source and currency with overlap exclusions, and results are aggregate rather than paginated. It does not describe limits on result size or empty-result 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?

Three dense sentences with no filler, but the middle sentence stacks grouping and currency/overlap clauses into one run-on, and the routing caveats are buried at the end rather than front-loaded. Readable and compact, but structure could be cleaner.

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

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

No output schema and 9 mostly-undocumented parameters mean the description carries a lot of weight. It explains aggregation semantics well but omits result shape on the return end and leaves limit/body/body_id/supplier_id undefined, so an agent could still invoke it incorrectly.

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 only 11% across 9 parameters, so the description must compensate. It covers the filterable dimensions (supplier, buyer/department, year, source) and the group_by values implicitly, but leaves limit, body, body_id, and supplier_id unexplained and doesn't clarify that 'buyer' maps to the department parameter.

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 resource (aggregated totals/rankings) and its scope (full-record, filtered by supplier/buyer/year/source, grouped by several dimensions). It also names a sibling it is not (get_department) and excludes paginated-search sums, so an agent can place it. The vague phrase 'full-record totals' and the conflation of 'totals or rankings' into one tool keep it 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?

Gives two explicit routing rules: use get_department for program spending, and awards are not payments. It also signals the aggregate-only scope via 'no paginated-search sums'. It stops short of a full when-to-use statement (e.g. when to choose a ranking vs a total, or currency handling).

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 the safe read-only, idempotent, non-open-world profile, so the bar is lower. The description still adds meaningful context beyond them: it discloses that the result is hypothetical, states the denominator assumption, and explicitly disclaims geographic allocation, resident liability, and local wage/employment claims — valuable guardrails against misinterpreting the 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?

The action is front-loaded ('Hypothetically divide...'), and the two sentences contain the operation, the caveats, and the source without filler. Dense but 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?

For a single-parameter, non-destructive computation with no output schema, the description covers the operation, the denominators used, the disclaimers, and the data source. Enough for correct invocation, though it could clarify the response shape or supported amount bounds in more detail.

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

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

With one parameter at 100% schema coverage, the schema already documents the amount as Canadian dollars with an example. The description adds only the 'supported CAD' qualifier, which is mildly useful but largely restates the schema, so baseline 3 is appropriate.

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

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

States a specific operation: hypothetically dividing a supported CAD amount by NL population, households and reference median wage to express it in human terms. This distinguishes it from the get_/search/fetch siblings, which are data-retrieval tools rather than a scaling calculation.

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 phrase 'supported CAD amount' implies the accepted input domain and that non-CAD or non-supported amounts are out of scope, but there is no explicit when-to-use statement or naming of an alternative sibling. Usage is only implied by the tool's nature.

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 establish the safe read-only, idempotent profile, so the remaining burden is low. The description adds genuine interpretive context beyond the annotations: counts are returned per pattern, and critically "Each pattern is a question, not a finding," which steers the agent away from treating flags as confirmed conclusions.

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 subject (what the patterns are) front-loaded and the important caveat placed last for emphasis. 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?

With no output schema and no parameters, the description carries the whole load and does explain that each pattern comes with a count. It stops short of describing the entry shape (e.g. pattern name plus count fields) or pagination, which would fully close the 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?

The tool takes zero parameters, so the baseline of 4 applies; there is no parameter syntax for the description to clarify or omit.

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 ("List the patterns") and grounds it with three concrete examples (sole-source awards, grown contracts, just-under-limit purchases). The plural/list framing distinguishes it from the singular get_flag sibling, though it never names that 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?

Usage is only implied: an agent can infer this is the discovery step that precedes get_flag for detail, but the description never says when to call it versus get_flag, get_totals, or search. No prerequisites or exclusions are 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=true, idempotentHint=true and destructiveHint=false, so safety is covered structurally. The description adds genuinely useful behavior: results are a short list of id/title/url only, and a follow-up fetch is needed for full content. It does not disclose limits or pagination, which keeps it below 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?

Three short sentences, each load-bearing: what it returns, how to get more, and which sibling to prefer instead. No filler and the highest-value information leads.

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

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

With no output schema, the description correctly steps in to describe the return fields and the fetch follow-up path, which is the most important missing piece. It leaves the notion of 'short list' vague (no count or pagination behavior), a minor gap for a one-parameter read 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?

Only one parameter exists and schema coverage is 100% ('Words to find.'), so the schema already carries the semantic load. The description adds nothing about query syntax, matching behavior, or result caps, making a baseline 3 appropriate.

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

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

States a specific verb and resource ('Search the records') and immediately describes the return shape (id, title, url). It also separates itself from two siblings by name: fetch for full records and search_records for filtered queries, so an agent can route without opening other schemas.

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 follow-up guidance ('Use fetch with an id to get the full record') and a routing preference ('Prefer search_records when you can pass filters'). Both name the alternative and the condition, though no explicit when-not-to-use case is 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description layers on genuinely useful behavioral detail beyond them: prefix-based exact matching, largest-amount-first ranking, 25 records per page, automatic spelling correction when nothing matches, and related_by_meaning records only on page 1. It also states that each record carries a source citation, which no structured field discloses.

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: matching, ranking, pagination and correction behavior come first, with the source glossary trailing at the end. Every clause carries information, though the source-code list reads like schema glossary material and makes the block heavier than ideal.

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

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

With no output schema, the description does the work of explaining returns: exact-match semantics, ordering, page size, the 'corrected' and 'related_by_meaning' fields, and per-record citations. This is close to complete for a 6-param search tool; only the relationship to sibling search tools remains 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 coverage is 100%, so the baseline is 3, but the description adds real meaning on top: it spells out what each source code (ppa, fed_contract, sunshine, mha, etc.) actually represents, which the schema's enum does not, and restates the 25-per-page / page-1 framing for 'page'. The query/pattern/supplier_id semantics are left to the schema, hence not a 5.

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

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

The description gives a specific verb ('Search') and enumerates the exact corpus searched: contract awards, federal contracts and grants, minister/MHA expense lines, and pay over $100,000. That is far more precise than the bare name, though it never distinguishes this tool from the sibling 'search' or 'get_record', so an agent still has to guess which of the search-like siblings to pick.

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

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

'Give a query, a filter, or both' plus 'use page for more' gives usable invocation context, and the spelling-correction and related_by_meaning notes hint at fallback behavior. However, there is no explicit when-to-use-this-vs-sibling guidance (e.g. versus 'search' or 'fetch') and no exclusion conditions, so usage is only implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine behavioral context beyond them: the result is an estimate built on the receipt page's assumptions, not an authoritative assessment nor a record of the caller's actual payments — an important caveat for interpreting 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 sentences, both front-loaded with the core capability first and the disclaimers second; nothing is redundant. 'Using the receipt page's assumptions' is slightly opaque but the phrasing is compact overall.

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 one-parameter, no-output-schema tool whose annotations cover safety, the description supplies the key missing pieces: what is computed (provincial tax estimate), what else is returned (spending shares), and what the result is not. Only the units/format of the numeric input remain unaddressed.

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

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

The single parameter has 0% schema description coverage, so the description carries the burden. It clarifies that 'income' means annual employment income (rather than total or household income), but adds no currency, precision, or interpretation of the 0–10,000,000 bounds.

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 (Estimate) and resource (provincial income tax on annual employment income) and adds a second output (department spending shares). The negative clause ('Not a personal tax assessment or a trace of your tax payments') preempts the most likely misreading by an agent, so the tool is clearly separable from the generic get_*/search siblings.

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

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

The description establishes the operating context ('using the receipt page's assumptions') and an explicit exclusion ('not a personal tax assessment'). It does not name an alternative tool for when a real assessment is needed, but given no tax-related sibling exists, the routing guidance is adequate.

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