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

Annotations already establish readOnly, idempotent, non-destructive behavior. The description adds value by clarifying that this is a readiness check only and explicitly excludes calculation and submission, which is a meaningful behavioral boundary beyond the annotations. It does not describe the output shape, but the safety profile is well covered.

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. It front-loads the core purpose, lists the relevant record types, and closes with an important exclusion. 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?

Given the tool has 21 parameters, 8 required booleans, a nested audit object, and no output schema, the description is too thin. It does not explain what the returned readiness result looks like, how required parameters interact, or what conditional schedule dependencies exist, so an agent would still need to infer much of the calling contract.

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 input schema has 21 parameters with 0% description coverage, and the description does not compensate. It only refers broadly to 'source records, finalised accounts, official worksheets, and conditional schedules,' leaving key parameters like assessmentType, partnershipIncome, foreignIncomeReceivedInMalaysia, and the various schedule-ready booleans unexplained.

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

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

The description uses a specific verb ('Check whether...are ready') and identifies concrete resources: source records, finalised accounts, official worksheets, and conditional schedules. It further distinguishes itself from preparation/calculation/submission tools, especially the sibling prepare_be_2025_draft.

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 context is clear: this tool is for assessing readiness before manual Form B preparation. It explicitly states what it does not do ('does not calculate or submit Form B'), providing a useful when-not signal, though it does not name sibling alternatives or explicitly sequence it before prepare_be_2025_draft.

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?

The annotations already communicate read-only, idempotent, non-destructive behavior, so less description is needed. The phrase 'supported' adds a hint of availability filtering and the response contents are useful, but the description does not disclose error cases, operational constraints, or required auth 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?

One sentence with no filler, front-loaded with the core action and resource, then a compact enumeration of return contents. 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?

With no output schema and a nested audit parameter, the description is too thin. It does not clarify the taxYear values, the meaning of 'supported,' the audit fields, or how to choose among the sibling tools, leaving a nontrivial operation underspecified.

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 needs to compensate. It mentions Form BE or Form B, which maps to formType, but it does not explain the taxYear parameter, the audit object, or how they affect the release being returned.

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, 'Return,' and names the resource as a supported Form BE or Form B release, while also listing what is included: official sources, validation result, review status, and known limitations. It is clear on its own, but it does not explicitly contrast itself with sibling list/search tools.

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

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

No usage guidance is provided. The description does not say when to use this tool instead of list_tax_authority_releases, search_tax_authority, or the preparation/assessment siblings, and it lacks any prerequisites, exclusions, or selection criteria.

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 convey that this is a safe, read-only, idempotent operation, so the description does not need to repeat those facts. It adds value by disclosing what the tool reveals: supported years, forms, versions, statuses, capabilities, and limitations. It does not mention pagination or exact response shape, but that is secondary for a discovery 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?

A single sentence, front-loaded with the tool's purpose and ending with the concrete dimensions the agent can discover. Every phrase earns its place 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?

For a read-only listing/discovery tool with strong annotations and only one optional audit parameter, the description gives the agent enough context to call it at the right time and understand what can be learned. It does not detail the return structure, but given the explicit list of discovery dimensions, the omission is acceptable.

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 only parameter, audit, is an optional nested object with runId, sequence, and previousEventId, and schema description coverage is 0%. The description does not explain this parameter at all, leaving the agent without guidance beyond raw field names and JSON structure. Since schema coverage is low and the description fails to compensate, this dimension is poorly served.

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 clear discovery-oriented verb and names the resource—tax authority releases—and its purpose: to learn supported years, forms, versions, statuses, capabilities, and limitations before selecting a release. It distinguishes itself from fetch-style siblings like get_tax_authority_release by framing this as the pre-selection discovery step, though it does not explicitly name alternatives.

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 a clear context for use: call this tool before selecting a release, so the agent can understand available options and constraints. It does not explicitly name sibling tools or state when not to use it, so it falls just short of full alternative-routing guidance.

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

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

The description adds valuable behavioral facts beyond the annotations: 'never stores data or submits to MyTax', 'output remains review-gated', and 'source-linked'. These details align with readOnlyHint=true, idempotentHint=true, and destructiveHint=false, with no contradiction.

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

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

The description is two concise sentences with the core action front-loaded and the safety/review constraints stated immediately after. No filler or redundant information.

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

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

Given 11 parameters, nested objects, no output schema, and low schema coverage, the description covers the tool's purpose and constraints but leaves out guidance on how to structure the inputs or what the returned draft will contain. It is adequate for selection but not fully complete for invocation.

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

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

Schema description coverage is low at 18%, so the description must compensate for undocumented parameters, but it only generically references 'taxpayer inputs' and 'relief evaluation'. It does not explain required fields like assessmentType or income, or clarify the meaning of the many nested objects.

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 the specific verb 'Compile' and names the resource 'Form BE fields', with clear inputs ('reviewed taxpayer inputs and a deterministic TaxBrain relief evaluation'). It also distinguishes itself from the sibling tools, which are about tax authority releases and readiness assessment, by focusing on draft preparation.

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 implies the tool should be used after inputs have been reviewed and after a deterministic TaxBrain relief evaluation exists. It does not provide explicit exclusions or name alternatives, but the context signals and sibling list make the intended usage reasonably 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?

Annotations already reveal readOnly, idempotent, and non-destructive behavior, so the description only needs to add context beyond that. It does so by noting the tool 'Returns official source records with every match', which clarifies result completeness and source authority. It does not contradict the annotations.

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

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

Two compact sentences pack in the action, resource, search dimensions, and return behavior with no filler. The key scoping information is front-loaded and every clause adds value.

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 search tool, the description covers scope, search inputs, and return shape ('official source records with every match'). It lacks explicit guidance on taxYear semantics and the internal audit parameter, but those are partially addressed by schema defaults and the tool's nature. Overall it is adequate for successful invocation without being exhaustive.

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 25%, so the description carries significant parameter-documentation responsibility. It enriches the query semantics by mentioning field ID and rule ID, and it covers formType via 'Form BE or Form B', but taxYear and audit are not explained in the description. This is a partial, not complete, compensation for the low 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 opens with a specific verb ('Search'), names the resource ('cited Form BE or Form B rules'), and enumerates search dimensions ('topic, field ID, rule ID, or TaxBrain category'). This clearly separates it from sibling tools like list_tax_authority_releases or prepare_be_2025_draft.

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 by defining it as a search operation, but it does not explicitly state when to choose this over sibling tools, nor does it name alternatives. With siblings like list_tax_authority_releases and get_tax_authority_release, some implicit differentiation exists, but no explicit usage boundary is provided.

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