Tommy Accounting

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered elsewhere. The description adds genuinely useful behavioral context beyond them: the payload is static reference facts, including what the service does NOT do, which helps the agent anticipate limitations content. It does not describe return formatting, but there is no output schema to align with.

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?

One sentence, front-loaded with the resource, then a tight enumeration of covered topics. Every clause earns its place and nothing is padded.

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

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

For a zero-parameter, read-only informational tool with no output schema, the description communicates both scope and expected content areas well enough to call it confidently. The only mild gap is no hint about response shape or size, which is a minor concern for a static fact tool.

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

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

The tool takes zero parameters, so the baseline expectation is met. The description explicitly states 'Takes no inputs,' which correctly aligns with the empty input schema and prevents the agent from inventing arguments.

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 (facts about Tommy Accounting) and enumerates the specific content areas covered: services, qualifications, how requests work, limitations, and links. That is far more specific than a tautology. It does not explicitly contrast itself with the sibling tools, though the informational framing makes the distinction reasonably inferable.

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 would call this when it needs background on the firm, since the description lists the topics available. There is no explicit statement of when to prefer this over siblings like request_bookkeeper, nor any exclusion guidance. Adequate but leaves routing to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description goes further, disclosing the method (deterministic keyword rules, explicitly no AI), that output carries a confidence level, and which expense types get flagged as non-allowable or needing care — real behavioral context beyond the annotations.

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

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

Three sentences, no filler: audience/value first, then the core mapping behavior and method, then the flagged-categories list and totals. Every clause carries information and the most decision-relevant content 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?

With no output schema, the description must carry return-value burden, and it does describe the shape of the response (category per expense, confidence level, cautionary flags, per-category totals). It is nearly complete; only the exact response structure and behavior for invalid/large inputs (200-item cap) remain unstated.

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

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

Schema coverage is 100%, so the single `expenses` array and its `description`/`amount_gbp` fields are already documented. The description adds only a marginal note that totals are produced when amounts are given, which ties to the optional `amount_gbp` but does not add format or validation detail beyond the schema. Baseline 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?

States a specific verb+resource (maps each expense to an HMRC SA103F category) plus the exact audience (UK sole traders) and the output artifacts (confidence level, flags, per-category totals). It is clearly distinguishable from siblings like estimate_tax_set_aside and check_vat_mtd_thresholds without opening any schema.

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

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

Usage is implied by the audience and scope (categorising self-employed expenses), but there is no explicit when/when-not guidance and no sibling is named as an alternative. An agent can infer the context but is not told when to prefer this over the accountant-facing 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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral detail: it outputs a 'near' flag within 10%, explains rolling 12-month and 30-day forward-look rules, and distinguishes estimate from definite answer. Return semantics are described, though depth of each explanation is unstated.

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

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

Three sentences, front-loaded with purpose and audience, then behavior, then the input-accuracy caveat. Efficient overall, though the opening 'Free estimate for UK sole traders' is slightly promotional rather than strictly informative.

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

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

With no output schema, the description carries the burden of describing returns and does so: threshold comparison, near-threshold flag, rule explanations, and MTD applicability with a start date. Nothing needed to call or interpret the tool 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 description coverage is 100%, so the schema already documents every parameter including the per-year qualifying income fields. The description only restates that qualifying income is optional and yields a definite answer, adding little syntax or meaning 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?

States a specific verb and resource: check annual turnover against the UK VAT registration threshold and determine whether/from when MTD for Income Tax applies. This is clearly distinguishable from siblings like estimate_tax_set_aside or request_bookkeeper, and the audience (UK sole traders) is named.

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

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

Gives clear context for use (UK sole traders, free estimate) and explains the condition that upgrades an estimate to a definite answer: supply qualifying income per tax year. It does not name alternatives or explicit when-not conditions, so it stops short of a 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description goes further and discloses what is actually computed (effective rate, total/12 set-aside, band-by-band breakdown, payments on account, the first 31 January payment). This is rich behavioral context well beyond the structured fields.

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

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

Two sentences, front-loaded with the purpose and scope before the output detail. The sentences are dense but each clause (effective rate, set-aside formula, payments on account, region support) carries distinct information, so little is wasted.

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

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

There is no output schema, so the description shoulders the burden of describing return values, which it does thoroughly (effective rate, suggested monthly set-aside as total/12, band-by-band working, payments on account). Combined with annotations covering the safety profile, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents all four parameters (baseline 3). The description adds real semantic value by explaining that first_year_self_employed changes the headline to include the first 31 January payment (which itself includes a payment on account), and notes the two supported regions.

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: it estimates Income Tax and Class 4 National Insurance on self-employed profit, and enumerates the outputs (effective rate, monthly set-aside, band-by-band working, payments on account). The UK-sole-trader scope makes it instantly distinguishable from siblings like categorise_expenses or check_vat_mtd_thresholds.

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 opening 'Free estimate for UK sole traders' and 'Supports England/Wales/Northern Ireland and Scotland' give clear context for when the tool applies and which region inputs are in scope. There is no explicit when-not or named alternative among the siblings, so it stops short of a 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, consistent with link building. The description adds genuinely useful behavioral facts: the agent cannot submit on the user's behalf, the link never carries name/email/phone, and a human check is required. This goes beyond the structured fields, though the pricing/sales content dilutes it.

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 core fact is front-loaded in the first sentence, but roughly half the text is marketing copy — 'Now taking enquiries', reply timeframes, and a full price list with VAT notes — that does not help an agent invoke the tool. This padding works against conciseness.

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 no output schema, the description conveys the purpose and constraints adequately. It stops short of explaining what the returned link is or how the supplied parameters influence it, which is the main remaining gap; the off-topic pricing content occupies space that could have closed 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 description coverage is 100%, so request_type, service, message and preferred_time are already documented with enums and constraints. The description adds no additional meaning about how these values shape the generated link (e.g. that they pre-fill the form). 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 first sentence states a specific verb and resource: 'Builds a ready-filled link to the Tommy Accounting request form.' It's immediately clear this generates a URL rather than submitting anything. It does not explicitly differentiate from siblings like about_tommy_accounting, but the action is distinct enough on its own.

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 describes the user-facing flow ('Give the link to your user... you cannot submit it for them'), which implies appropriate usage and clarifies the agent's role. However, it never states when to choose this tool versus siblings such as about_tommy_accounting, leaving the selection condition implicit.

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