Duck Tax

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

No annotations are provided, so the description carries the burden. It discloses that the tool is a read-like classification operation, that it has a quota unit per import, and that previously seen descriptions are served from a shared cache free. It also warns not to send amounts or dates. It doesn't state whether the operation is idempotent or whether it mutates state, but the cache/quota note gives meaningful behavioral 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 sentences, each earning its place: what the tool does, what to send/not send and the follow-up step, and the quota/cache behavior. The most important usage constraint is front-loaded. No fluff.

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

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

For a tool with no output schema and no annotations, the description covers the key operational details: input constraints, follow-up step, quota, and caching. It doesn't describe the exact format of the returned categories or how to handle errors, but the description is sufficient for an agent to call it correctly and know what to do next.

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 schema already documents both parameters. The description adds value by explaining the purpose of tradingType (resolving ambiguous merchants) and by clarifying that descriptions are raw strings, one per transaction. It also adds the constraint to send only descriptions, not amounts or dates, which is not in the schema. This goes beyond the baseline 3.

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

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

The description states a specific verb ('Categorise'), a specific resource ('bank-statement transaction descriptions'), and a clear outcome (mapping to fixed vocabulary for balance sheet lines). It also distinguishes itself from siblings by naming totals_to_figures as the follow-up step, and the fixed vocabulary examples (sales, software, owner-in) make the purpose 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?

The description explicitly says when to use this tool: send description strings only, never amounts or dates, and then call totals_to_figures. It also gives a quota/caching note that helps an agent decide whether to call it. This is strong usage guidance beyond the schema.

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

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

With no annotations, the description carries the full behavioral burden, and it does so thoroughly. It discloses that the tool does NOT check that the sheet balances and why (retained earnings is the balancing figure), warns against claiming it was checked for consistency, states it is free and instant, and describes the return values (derived sheet, rejected figures, completeness status). It also clarifies unit conventions (major units) and the dormant filing warning. This is comprehensive behavioral disclosure far beyond minimal assumptions.

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 relatively long but every sentence carries substantive information—purpose, returns, limitations, usage, units, and parameter guidance are all present with no filler. It is front-loaded with the purpose and immediately clarifies a critical limitation (no balance check). While not ultra-terse, it is efficiently organized and each sentence earns its place, so a 4 is warranted rather than a 5 for extreme economy.

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

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

Given the tool's complexity (3 parameters, nested figures object, 16 required sub-fields), the description provides a complete picture: what it returns, its limitations, when to call it, how to handle units, and important parameter relationships. With no output schema, it adequately describes the output components. The description suffices for an agent to correctly invoke the tool and interpret results, leaving no critical 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?

Despite 100% schema description coverage, the description adds valuable semantics beyond the schema: it explains that directorsLoan is part of creditors (never an addition), often the largest line, and repayable tax-free; it notes that lastFiledAs must come directly from lookup_company and not be guessed; and it reiterates major units globally. These enrich the bare schema definitions, justifying a score above the baseline of 3. It doesn't exhaustively detail every parameter but covers the most decision-relevant nuances.

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

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

The description opens with a specific verb and resource: 'Derive a small-company balance sheet (micro-entity, in UK terms) from raw figures and validate it.' This clearly identifies the tool's function and differentiates it from siblings like explain_accounts (which presumably interprets) and totals_to_figures (which likely prepares figures). It also states precise scope and outputs, leaving no ambiguity about the tool's purpose.

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

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

The description explicitly advises 'call it after every change to the figures' and gives the condition for the dormant warning ('when figures showing activity are about to be filed dormant again'), which guides when to invoke it. It also instructs to pass lastFiledAs from lookup_company. However, it does not explicitly name alternative tools or state when NOT to use this one, only implying it is a safe always-call tool. The guidance is clear but lacks explicit exclusion criteria, so a 4 is appropriate.

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

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

With no annotations, the description carries the full burden, and it does well: it discloses that the tool only prepares an application, can never submit one, requires a director to act on the registrar's service, has quota-charged register lookups with free cached results, and avoids side effects like filing accounts. It also reveals the first field of the response ('nextAction').

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 longer than average, but it is front-loaded with the key output and each sentence adds useful information about behavior, cost, or input modes. A little domain context (free, 15 minutes, most useful thing) could be trimmed, but it does not obscure the tool's purpose.

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 7-parameter tool with no annotations and no output schema, the description is remarkably complete. It covers input modes, parameter interactions, cost/quota behavior, side-effect safety, jurisdiction support, filing-type limits, and the shape of the answer, leaving no critical gap for an agent deciding whether and how to call it.

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 substantial meaning: it clarifies the companyNumber vs. manually-supplied-dates modes, explains that periodEnd bounds extra time, notes which jurisdictions have register access, and states that only accounts can be extended while confirmation-statement requests receive an explanatory response.

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 operation: checking whether a company can still apply for more time, how many days remain, and the late cost if missed. It also distinguishes itself from siblings by stating it never submits an application, links to the registrar's own service, and does not file accounts.

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 this tool is useful ('usually the most useful thing to tell somebody who has just found a deadline') and explains two input modes: supply a company number or provide dates yourself. It does not explicitly name alternatives or say when to choose another sibling, but the use case is concrete enough.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states the operation is permanent and irreversible, and warns about the lack of recovery options. This fully discloses the destructive nature of the tool, which is the critical behavioral trait an agent needs to know.

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

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

Two sentences, zero waste, with the core action and permanence stated upfront. The warning is concise and placed after the action. The description is highly efficient and well-structured.

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 simple delete operation with a single parameter covered by the schema, the description is complete. It covers the critical context (permanence, need for confirmation) and does not require an output schema. An agent has everything needed to call the tool correctly.

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

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

The schema description for the only parameter, id, is 'The id from list_saved_filings,' which provides clear semantic meaning. Since schema description coverage is 100%, the baseline is 3. The tool description adds no additional parameter semantics beyond what the schema already provides.

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 (Delete), a resource (saved filing), and a method (by id), and adds 'permanently' to clarify the nature of the operation. It is distinct from siblings like save_filing and list_saved_filings, making the tool's purpose unambiguous.

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

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

The description provides clear guidance to confirm with the person before calling, and warns that there is no undo or trash. It implies when to use (when a permanent deletion is intended) but does not explicitly contrast with alternatives like untrack_company_deadlines or other deletion tools. The guidance is helpful but not exhaustive.

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

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

With no annotations, the description carries the burden of describing behavior. It discloses the output composition (share capital, matching cash, zeros everywhere else), the units (major units), and the efficiency benefit ('collapses the whole form to one call'). It does not explicitly state read-only behavior, but the nature of 'figures' strongly implies retrieval rather than mutation.

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 only two sentences, with the core purpose front-loaded and no filler. Every sentence adds useful information: the figure composition, the dormant-company context, the one-call benefit, and the unit convention.

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 simple one-parameter tool with no output schema, the description provides enough context about what the tool returns and when to use it. It could be more complete by explicitly stating the response format or read-only nature, but the low complexity and clear description make it mostly 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 already fully documents the single parameter, shareCapital, including its type, default, description, and exclusivity constraint, so schema coverage is 100%. The description repeats the 'major units' detail but does not add significant parameter-specific meaning beyond the schema. Baseline 3 is appropriate given the high schema coverage.

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

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

The description clearly identifies the tool as returning the complete set of figures for a dormant company, specifying share capital, matching cash, and zeros elsewhere. It differentiates from sibling tools by emphasizing the dormant-company scope and the one-call collapse of the form. This is specific enough for an agent to understand exactly what the tool provides.

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

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

The description gives clear usage context: it applies to dormant companies, and it references the register's indication of when last accounts were filed dormant. It does not explicitly name alternatives or exclusions, but the condition for when this tool is appropriate is clear.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses that the tool will not invent circumstances, leaves bracketed placeholders for missing information, requires user certification, and does not submit applications. This is rich, operationally relevant behavioral information beyond the schema.

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

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

The description is compact yet complete, with each sentence earning its place. It front-loads the core purpose, then covers constraints, user involvement, boundaries, and quota/caching behavior. There is no redundant or filler text despite the length.

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

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

For a tool with 4 parameters, full schema coverage, and no output schema, the description is complete enough. It explains what the tool does, what it refuses to do, how the agent should interact with the user, and important operational details. The only omitted details are already covered by the input schema.

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

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

Schema coverage is 100% and every parameter already has a detailed description, including 'Facts only', 'Never estimate it', and 'if they have said'. The tool description adds general behavioral constraints like not inventing facts and using placeholders, but no parameter-specific meaning beyond what the input schema already provides. 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?

The description uses a specific verb-resource pair: turning a short factual account into reason text for an extension application. It clearly frames the output as registrar-facing text and distinguishes itself from submission or filing tools by stating it does not submit or file. This makes the tool's purpose immediately identifiable and distinct from siblings.

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

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

The description gives explicit usage boundaries: it must be given facts by the user, it must ask the user rather than inventing, every sentence must be checked, and it does not submit or file accounts. It also explains cost/caching behavior. These are concrete when-to-use and when-not-to-use instructions that prevent an agent from misusing the tool.

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

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

With no annotations, the description carries the burden and does a good job: it discloses the privacy boundary (no company name/number sent), the quota/cache behavior, and the narrative style/audience. It stops short of stating what happens on invalid figures or how 'derived' figures should be prepared, but the core behavioral traits are transparent.

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, each carrying distinct information: purpose, privacy constraint, and quota/cache behavior. The key purpose is front-loaded and there is no redundant wording.

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 gives the output type (plain-English reading), the audience, the input boundary, and cost behavior, which is sufficient given the fully-described schema. The only ambiguity is what 'derived sheet' means and how it relates to the figures object, but the schema resolves most of the input structure.

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

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

The schema already describes all parameters in detail (100% coverage), so the baseline is 3. The description only adds that the figures object is the entire 'derived sheet' sent to the model, which is a mild semantic clarification but doesn't expand on individual parameters.

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

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

The description uses a specific verb phrase ('a plain-English reading') and identifies the resource ('a set of figures' / 'derived balance sheet'), the audience, and the output content ('what the derived balance sheet says... anything that needs attention before filing'). This makes the tool's purpose distinct from siblings like check_accounts, which implies validation rather than explanation.

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 implies when to use the tool: before filing, for a non-accountant director, and it notes that only the derived sheet is sent to the model. However, it never explicitly names alternatives or states when not to use it (e.g., versus check_accounts), leaving the routing partly to inference.

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

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

With no annotations, the description carries the burden. It discloses quota charges ('Quota-charged; cached results are free') and accuracy ('gets the comparatives exactly as filed'), which are valuable beyond the obvious read behavior. It doesn't cover error handling or edge cases, but the cost and accuracy notes add real 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?

The description is a compact paragraph that front-loads the primary purpose, then layers usage context, conditions, and cost in a logical order. Every sentence earns its place with no redundancy.

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 simple read tool with one parameter and no output schema, the description explains the output's purpose (drop into *Prior fields), the conditions (GB, digital filing), and cost. It could mention what happens if accounts aren't available, but overall it's complete enough for an agent to call it correctly.

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

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

Schema coverage is 100% with a single parameter described as 'The GB company number.' The description reinforces the GB scope, but adds no new semantic detail beyond what the schema already provides. 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?

The description states a specific verb ('Read') and resource ('last year's figures out of the company's last filed accounts at Companies House'), and clarifies its role as a helper for check_accounts and save_filing. It clearly differentiates from siblings by specifying it populates *Prior fields and is GB-only.

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 provides explicit usage conditions: GB only, last accounts filed digitally, and positions it as a time-saver over manual PDF entry. It doesn't name alternative tools or state when not to use it, but the context 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?

No annotations are provided, so the description carries the full burden. It discloses exactly what the tool returns (days, penalty band, next cost) and implies it is a read-only calculation. It does not mention side effects, but for a pure calculation tool this is sufficient. No contradictions.

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

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

The description is a few sentences with the core purpose front-loaded. The phrase 'the number that makes someone act today' is slightly rhetorical but does not detract. It is concise and informative, though it could be trimmed slightly.

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

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

With one parameter and no output schema, the description adequately explains input (due date from lookup_company or letter) and output (days, penalty band, next cost). It does not detail error handling or edge cases, but for a simple calculation tool this is acceptable. The description covers the essential context 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?

The schema has 100% coverage for the single parameter, including a description and pattern validation. The tool description adds no additional semantic value beyond referencing 'due date', which matches the schema. Baseline 3 applies since the schema does the heavy lifting.

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

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

The description clearly states the tool's function: given an accounts due date, it returns days remaining/overdue, the penalty band incurred, and the next band cost. It also scopes to UK private companies, distinguishing it from related tools like check_filing_extension or track_company_deadlines.

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 implies usage: when you have an accounts due date and need to know the financial consequence of missing it. It mentions 'UK private companies only' as a constraint but does not explicitly contrast with alternatives or state when not to use it. Clear context, but no explicit exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly describes what the tool returns (jurisdiction capabilities, currency, identifiers) and, being a list operation, implies read-only behavior. However, it does not explicitly state that it makes no changes or that it requires no special permissions, but for a simple list operation this is not a significant gap.

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

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

The description is two sentences, tightly packed with all essential information. The first sentence enumerates the output details, and the second gives a crisp usage instruction. No fluff or repetition—every sentence 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 zero-parameter, no-output-schema tool, the description is complete. It tells the agent exactly what to expect and when to use it. There is no missing information that would prevent an agent from correctly invoking or interpreting 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 has zero parameters, so the description cannot add parameter semantics. The schema is trivially complete (no properties). The baseline score of 4 for zero-parameter tools applies, and the description correctly avoids inventing parameters.

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

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

The description clearly states the tool's purpose: to list the jurisdictions the server knows about and their capabilities. It specifies the exact information provided (accounts engine, register search/lookup, currency, identifiers) and even includes a usage hint ('Call this first when unsure'), which distinguishes it from other sibling tools that are more specific.

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

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

The description explicitly says 'Call this first when unsure,' providing a clear trigger for when to use the tool. While it doesn't list exclusions, it implies this is a discovery/orientation tool and the natural first step before using more specific jurisdiction-dependent 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?

With no annotations, the description carries the behavioral disclosure burden. It reveals return ordering ('most recently touched first'), units ('major units'), and consistency with the dashboard. It does not mention read-only side effects or pagination, but for a zero-parameter list tool this is adequate.

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 with no waste. The key facts (what it lists, ordering, units) are front-loaded, followed by a practical usage cue. Every word 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 simple read-only list tool with no parameters and no output schema, the description covers all essential aspects: the resource, ordering, unit format, and a usage trigger. An agent can invoke it correctly without further clarification.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific semantics because none exist; the schema already fully covers this.

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

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

The description clearly states the tool lists the user's saved filings with specific ordering and unit formatting. It also ties it to the website dashboard and gives a concrete trigger ('my accounts'/'my company'), which distinguishes it from siblings like check_accounts or save_filing.

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 provides an explicit 'when to use' instruction ('Start here when asked about...'), giving clear context. However, it does not name alternative tools or state when not to use it, so it falls short of the full 5 standard.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the tool never contacts a register, is free, and only shows deadline info where a cached register record exists. This gives the agent important expectations about cost and data availability without needing external hints.

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 add distinct value: the scope of results, the fields shown, and the behavioral guarantee of no register contact. The description is front-loaded with the core purpose and contains no filler.

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

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

For a zero-parameter, no-output-schema read tool, the description explains what is returned, mentions the caching caveat, and states the cost/network behavior. It could be more explicit about the exact output structure, but it is sufficient for an agent to select and invoke the tool correctly.

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

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

The tool has zero parameters, so there is no parameter meaning for the description to add. The baseline of 4 applies because the schema is empty and the tool requires no input decisions.

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

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

The description clearly states the tool returns 'every company this user gets deadline reminders about,' including companies implied by saved filings. This gives a specific resource and scope, and distinguishes the tool from list_saved_filings without needing to open 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 description provides useful context cues: it covers deadline-reminder companies, includes implied saved-filing companies, and notes that it never contacts a register. It does not explicitly name a sibling alternative or state when not to use it, but the context strongly implies its role as the lightweight, free list.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It is transparent about rate limits, quota charges, cached-result behavior, and the exact contents of the returned public record including deadlines and penalties. It does not mention auth or error behavior, but the key operational costs and outputs are 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?

The description is three focused sentences: what it does, what it returns and costs, and how to obtain the input. Every sentence earns its place, the key action is front-loaded, and the prerequisite instruction is placed as a natural closing call to action.

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

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

Given that there is no output schema, the description enumerates the return fields and explains the cost model, which is important context for an agent. It is slightly incomplete regarding the IE/US enum values, since the description and schema mention register access only for GB and AU, leaving the behavior for IE/US unspecified.

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

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

The schema already documents both parameters with descriptions and examples, and coverage is 100%. The description adds only the mapping that the registered number is either a GB company number or AU ABN, which is useful but only marginal value beyond the schema. Baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Look a company up on its public register' by registered number. It clearly scopes the tool to GB and AU registers and distinguishes it from search_companies by naming the prerequisite, so an agent can tell lookup from search 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?

It explicitly instructs 'Find the number first with search_companies,' giving a clear when-to-use and prerequisite. It also notes that the tool is rate limited and quota-charged while cached results are free, which directly helps the agent decide when to call this tool versus alternatives.

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

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

There are no annotations, so the description carries the burden of behavioral disclosure. It reveals what the sample contains, that it is the simplest permitted UK accounts, and that amounts are in major units. It does not explicitly state that the call is side-effect-free, but the example/template framing and zero parameters strongly imply a pure data retrieval with no destructive or mutating behavior.

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

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

The description is three concise sentences with no filler. The first sentence front-loads what the tool is, the second explains why/when to use it, and the third adds the unit convention. Every sentence 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 zero-parameter, no-output-schema example-data tool, the description is largely complete: it explains the content, the intended use, and the unit convention. The only minor gap is that it never explicitly states the return shape or type, but for this simple fixture tool an agent has enough context 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?

The tool has zero parameters and the schema is empty with additionalProperties false, so there is nothing for the description to explain. Per the baseline for zero-parameter tools, a score of 4 is appropriate; the description also adds the useful detail that amounts are in major units.

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 identifies the tool as 'a real worked example' of UK accounts, listing concrete characteristics (nil turnover, director loan, near-empty bank account). It doesn't use an explicit verb like 'returns' or 'provides', but it is clearly a data resource rather than an action, and the 'template' phrasing makes the purpose unambiguous. It also distinguishes itself from sibling action tools such as check_accounts and categorise_transactions.

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

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

The description explicitly says to use it 'to demonstrate check_accounts or as a template for a first-year company', giving clear, concrete usage scenarios. It does not mention alternatives or exclusions, but for a zero-parameter sample-data tool the guidance is sufficient.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states that the filing is saved even when validation finds problems, that problems are returned in the response, and that figures are in major units. It does not discuss auth requirements or overwrite semantics, so a small gap remains.

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-load the core purpose, then add units and the validation nuance. Every sentence earns its place with no redundant 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?

The description covers the key behaviors an agent needs: create/update semantics, units, and the validation-failure behavior. There is no output schema and no explicit success-response shape, but the statement that problems come back in the response gives enough direction for practical use.

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 83%, so the input schema already documents parameters well. The description adds some reinforcement about units and the id's role, but it does not meaningfully go beyond the schema's rich per-field descriptions.

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 uses specific verbs ('save' and 'update') and clearly names the resource ('a set of figures to the user's account'). It distinguishes the update path by referencing list_saved_filings as the source of the id, which separates it from sibling tools like delete_filing or sample_accounts.

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 clearly explains the create-versus-update usage and points to list_saved_filings for obtaining an existing id. It does not explicitly enumerate when not to use the tool, but the context is clear enough for an agent to select it appropriately.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses quota and rate-limit behavior ('Free of the daily quota; lightly rate limited'), which is useful. However, it does not explicitly state read-only operation, error behavior, or multi-match handling, leaving notable gaps for a no-annotation tool.

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

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

Three sentences: purpose, usage guidance, and quota note. Each sentence earns its place, no fluff, and the most important information is front-loaded.

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

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

Given the tool's simplicity (2 params, no output schema, no annotations), the description covers the key aspects: what it does, when to use it, what it returns, and rate-limit context. Minor gaps remain around multiple matches and exact result format, but these are acceptable for a search tool.

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

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

Schema description coverage is 100%, with both parameters adequately described (e.g., 'The company name, as someone would say it.'). The description adds no additional parameter meaning beyond what the schema already provides, 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 action ('Find a company by name on its public register') and the results (registered number, status, address). It also explicitly distinguishes from the sibling lookup_company by positioning this as the entry point when only the name is known.

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 clearly tells when to use this tool: 'This is how you reach lookup_company when the person only knows the name.' It names the alternative and the condition that selects it, though it does not enumerate other sibling exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It implicitly indicates a read-only operation by describing a status report, but it does not explicitly state that it has no side effects or that it is safe to call. It does add context about what information is returned (integrations, token validity, quota), which is useful. A more explicit statement about being read-only would improve transparency.

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

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

The description is two sentences with no filler. The primary purpose is front-loaded, followed by a clear usage directive. Every word earns its place, making it highly efficient and easy for an agent to parse.

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

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

Given the tool's simplicity (no parameters, no output schema), the description is quite complete. It states what information the agent can expect and when to call it. The only minor gap is that it doesn't describe the exact response format or structure, but the categories it lists are sufficient for most use cases. With no output schema to reference, a bit more detail on response fields would be ideal, but it's adequate for the tool's scope.

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

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

The tool has zero parameters, so the schema is trivially complete. Per the rubric, the baseline is 4. The description adds value by explaining what the tool returns (integrations, token validity, quota usage), which goes beyond the empty schema. No further parameter explanation is needed.

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

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

The description clearly states the tool's purpose: reporting on deployment capabilities, token validity, and quota usage. It uses a specific verb ('report', 'tell you') and a specific resource (deployment status), and it distinguishes itself from the sibling tools by focusing on overall system status rather than a specific action. The phrasing 'What this deployment can actually do right now' is concrete and sets it apart from action-oriented 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 explicitly states when to call the tool: 'Call it when a tool refuses and you want to know whether the feature is off or used up.' This provides clear context and a specific trigger condition. However, it does not mention when not to use it or suggest alternative tools, so it stops short of the full 'when/when-not/alternatives' guidance that would earn 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?

With no annotations, the description carries full behavioral burden. It discloses key transformation rules (income→turnover, expenses→operating costs, owner top-up excluded) and the signed-major-units convention. It stops short of describing error behavior, unknown-category handling, or output format, which prevents 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 with no filler. The action is front-loaded, and each clause adds either a rule or a reference. Every word 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?

The description thoroughly covers input format and mapping rules, but with no output schema it does not specify the structure of the returned balance sheet figures or error cases. For an agent to consume the result downstream, the return format would need to be known, so completeness is adequate but not full.

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

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

Schema coverage is 100% and already describes the totals object with sign, units, and an example. The description restates that but adds the cross-reference to categorise_transactions for obtaining codes, a small value-add. Baseline 3 applies because the schema does the heavy lifting.

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 transformation ('Turn categorised bank-statement totals into balance sheet figures') and enumerates the rules that define its behavior, making it clearly distinct from siblings like categorise_transactions (source of codes) and dormant_figures (different purpose).

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 implies usage after categorise_transactions by telling the agent to get codes from that tool, and the context of producing balance sheet figures indicates a later stage in the pipeline. It does not explicitly mention alternatives or when not to use it, but the usage context is clear enough.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses channel variability ('the reply reports what will really be sent, and it can be nothing at all, so read it rather than assuming'), the reminder ladder and content ('each one states the company, the deadline, the date, the days remaining and the penalty'), and the idempotent/update behavior. This is exceptionally transparent.

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

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

The description is a single dense paragraph, but every sentence earns its place. It front-loads the core purpose, then addresses key gotchas (channel availability, no saved filing needed, ladder, update behavior). It is not overly verbose given the amount of behavioral detail it conveys.

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

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

For a tool with 5 parameters, no annotations, and no output schema, the description covers essential aspects: what it does, when to use it, what reminders contain, channel variability, and re-call semantics. It stops short of enumerating error cases or jurisdiction-specific nuances, but for the given complexity this is 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?

Schema coverage is 100%, so the schema already documents each parameter. The description adds value by specifying the default ladder (90, 60, 30, 14, 7, 1) not present in the schema, and by explaining the 'tightest rung' logic and channel dependency, which clarifies the email and push parameters beyond their basic type/description.

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

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

The description opens with a clear verb-resource-purpose statement: 'Watch a company by its register number and get reminded before its filing deadlines.' It distinguishes this from sibling tools like untrack_company_deadlines and save_filing by explicitly noting that no saved filing is needed. The 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 explains when to use this tool relative to saving filings ('No saved filing is needed: this is for the deadline itself') and clarifies re-calling behavior ('Calling this again updates the settings and un-mutes a company that was untracked'). It does not explicitly name alternative tools, but the context is enough for an agent to infer that this is for deadline tracking, not for filing preparation.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It transparently explains the mute-not-forget semantics, which is a key behavioral trait: the tool does not delete, it only pauses reminders, and it warns about the re-add behavior. This goes beyond the basic schema to clarify side effects.

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

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

The description is compact, two sentences, with the primary purpose front-loaded. Every clause adds value: the 'mutes rather than forgets' clarification and the re-add caveat are essential for correct usage and are stated with zero fluff.

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

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

The tool is simple with only 2 parameters fully documented in the schema, and no output schema is needed since the action is a configuration change. The description fully explains the behavioral nuance (mute vs forget) and the re-addition risk, making it complete for an agent to invoke 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 schema description coverage is 100%, so both parameters are well documented in the schema. The description references companyNumber in the schema ('as in track_company_deadlines') but does not add substantial new meaning beyond the schema's existing explanations. For full coverage, the baseline of 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?

The description opens with a specific verb ('stop sending') and a precise resource ('deadline reminders about a company'), clearly distinguishing the tool's core action. It also explicitly contrasts with the sibling 'track_company_deadlines', which is the inverse operation, eliminating ambiguity.

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 states exactly when to use this tool — to mute reminders — and clarifies that it is not a permanent forget, explaining the nuance that a saved filing could re-add the company on the next scan. It also names the sibling tool that un-mutes, providing explicit guidance on when to use that alternative.

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