CukaiMax Malaysian Tax Authority

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

With annotations already declaring readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the description adds value by detailing the scope of the check (source records, finalised accounts, official worksheets, conditional schedules) and clarifying that it does not calculate or submit. This goes beyond the annotation-level safety information and provides useful 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?

The description is two sentences, front-loaded with the primary purpose, and uses the second sentence to clarify a key limitation. Every word earns its place, with no redundancy or 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?

Despite having 21 parameters and no output schema, the description does not explain what the tool returns (e.g., a boolean, a report, a list of missing items) or any prerequisites/error conditions. It leaves the agent without critical context on how to interpret the tool's response, making it incomplete for such a complex 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 0%, so the description must compensate for the 21 parameters. It only provides high-level categories (source records, finalised accounts, official worksheets, conditional schedules) without mapping them to specific parameters like recordsKept, businessAccountsReady, or schedule readiness flags. While parameter names are somewhat self-explanatory, the description does not clarify the varying conditional logic or the meaning of specific booleans, leaving significant ambiguity.

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: 'Check whether the source records, finalised accounts, official worksheets, and conditional schedules needed for manual Form B preparation are ready.' It uses a specific verb (check) and resource (readiness for Form B), and explicitly distinguishes from related actions by stating 'This does not calculate or submit Form B.' This distinguishes it from sibling tools like 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 provides clear context for usage: it is a pre-check for manual Form B preparation. The statement 'This does not calculate or submit Form B' clarifies what it is not for, but it does not explicitly name alternative tools or specify when not to use it. Thus it has clear context but lacks explicit exclusions or alternative references.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about the return contents (sources, validation, review status, limitations), but does not disclose deeper behavioral traits like pagination, errors, or authentication needs. This is acceptable given the annotations, but not exceptional.

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, front-loaded sentence that efficiently states the action and key outputs. No wasted words or redundant information. It earns its place without being overly verbose.

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 getter tool with annotations, the description lists the return components, which is helpful. However, it does not clarify how to specify which release (via taxYear/formType), leaves the 'audit' parameter unexplained, and with no output schema, the description could have been more explicit about the expected response structure. There is a gap in explaining the audit context.

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 0% description coverage, leaving the burden on the tool description to explain parameters. The description does not mention 'taxYear', 'formType', or 'audit' at all. While taxYear and formType are inferable from their enum values in the schema, the 'audit' nested object remains opaque. The description adds no value for parameter understanding.

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 explicitly identifies the resource ('a supported Form BE or Form B release') and what is included (official sources, validation result, review status, known limitations). This clearly distinguishes it from siblings like list_tax_authority_releases (which likely lists releases) and assess_form_b_2025_readiness (readiness check).

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 its usage: to retrieve a specific release's details. However, it provides no explicit guidance on when to use this tool versus list_tax_authority_releases or other siblings, nor any exclusion criteria. The context from sibling names suggests usage, but the description itself does not state it.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds value by specifying the kinds of information the tool reveals (years, forms, versions, statuses, capabilities, limitations), which goes beyond the safety signals and helps the agent understand what to expect from the output.

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

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

The description is a single, front-loaded sentence that packs all key details without fluff. It starts with the primary action ('Discover supported...') and immediately communicates the tool's purpose and timing. No wasted words.

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 offers a useful summary of what the tool provides, but with no output schema, it does not fully explain the return structure or how the discovered information is organized. It also lacks details about pagination, result size, or how to use the results with sibling tools like get_tax_authority_release. Adequate for a simple list/discovery tool, but gaps remain.

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 only one optional 'audit' object with properties like runId and sequence, but no descriptions. Schema description coverage is 0%, and the tool description does not mention or explain the audit parameter at all. Since the parameter is optional, this is somewhat mitigated, but the agent receives no semantic guidance on whether or how to populate it.

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

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

The description clearly states the tool's function: to discover supported years, forms, versions, statuses, capabilities, and limitations of Malaysian tax authority releases. It uses a specific verb ('Discover') and identifies the resource. While it does not explicitly name sibling tools, the phrase 'before selecting a release' hints at its role as a precursor to selection, distinguishing it from retrieval 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?

The description includes 'before selecting a release,' which gives clear context on when to use this tool—as a preparatory step. It does not mention alternatives or exclusions, but the timing guidance is explicit enough for an agent to understand its placement relative to other operations.

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?

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds critical safety context: 'never stores data or submits to MyTax' and 'output remains review-gated'. This gives the agent concrete expectations about side effects and approval flow, which is valuable beyond the structured 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?

The description is two sentences long, information-dense, and front-loaded with the main purpose. Every clause adds value, and there is no redundant restatement of the tool name or title. It earns a high score for efficiency.

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 safety and high-level purpose but is sparse for a complex tool with 11 parameters, nested objects, and no output schema. It omits details about what the returned 'Form BE fields' look like, any prerequisites beyond 'reviewed', and how to supply the required inputs. It is adequate for understanding the tool's role but not fully complete for confident 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?

With schema description coverage at only 18% and 11 parameters, the description was expected to compensate by explaining parameter meanings. It vaguely refers to 'reviewed taxpayer inputs' and 'reliefEvaluation', but does not clarify the required parameters (assessmentType, income, reliefEvaluation), their structure, or the nested object semantics. The schema itself has few descriptions, so the agent receives little guidance.

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 ('Compile') and resource ('reviewed taxpayer inputs and a deterministic TaxBrain relief evaluation into source-linked Form BE fields'), clearly distinguishing it from sibling tools like assess_form_b_2025_readiness or search_tax_authority. It precisely communicates the tool's role as a draft preparer.

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 this tool: after taxpayer inputs are reviewed and a TaxBrain relief evaluation exists, to produce a review-gated draft. It also clearly states non-uses ('never stores data or submits to MyTax'). However, it does not explicitly name alternative tools for other scenarios, so it falls short of a full 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds that it returns 'every match' and 'official source records', providing some behavioral context, but lacks details on pagination, limits, or response structure.

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 sentence that front-loads the action and resource, with zero filler. It is concise and directly usable.

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 low schema coverage, the description leaves the return format of 'official source records' unclear, and it does not mention taxYear or audit parameters. For a simple search tool with read-only annotations, it is adequate but not complete.

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

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

Schema description coverage is only 25% (only query is described). The description adds 'rule ID' to query semantics and implicitly conveys formType via 'Form BE or Form B', but it does not explain taxYear or the nested audit object, leaving gaps.

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 'Search' and clearly identifies the resource as 'cited Form BE or Form B rules', along with the search dimensions (topic, field ID, rule ID, TaxBrain category). This distinguishes it from sibling tools that focus on readiness, release, or 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 implies usage by stating what can be searched, but it does not explicitly specify when to use this tool over alternatives or provide exclusions. Sibling tools have distinct purposes, but the description offers no comparative guidance.

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