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

No annotations are present, so the description carries the full burden. It does disclose that the information is general and not licensed financial advice, and that each item includes its source. However, it does not describe look-up behavior, supported year ranges, or handling of invalid inputs.

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 and front-loaded: the first sentence states the purpose and enumerates the returned categories, and the second adds a relevant disclaimer. No filler or repetition.

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

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

For a one-parameter lookup with an output schema, the description sufficiently covers what the tool returns and the expected input format. Minor gaps include missing sibling routing and explicit supported-year bounds, but these are not critical for basic 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 coverage is 0% and the schema only names financial_year as a string. The description adds a concrete format example ('2026-27') and clarifies that it refers to a single financial year, which is useful, but it does not define valid ranges or formatting constraints beyond the example.

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 resource: caps and thresholds for a specific financial year, and enumerates the exact categories returned. It lacks an explicit verb like 'retrieve' or 'get' and does not explicitly contrast itself with sibling tools, so it falls just short of a 5.

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

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

No guidance is given about when to use caps versus sibling tools like list_rules, get_rule, search_rules, or contribution_headroom. The phrase 'for one financial year' implies the parameter usage, but there is no explicit when-to-use or when-not-to-use 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?

With no annotations, the description carries the burden of behavioral disclosure. It does this well by revealing key operational details: integer cents in and out, no division so nothing is rounded, total super balance is the prior 30 June figure, and each applied rule is listed and cited. It also disclaims that it is general information, not licensed financial service. This goes beyond a generic calculation description, though it could still mention side-effect-free/read-only behavior explicitly.

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, information-dense sentences with no filler. The core computation is stated first, followed by precise numeric/rounding behavior and the TSB date rule, then the disclaimer. Every sentence earns its place and no structured fields are repeated.

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?

Although an output schema exists, the input side is complex and poorly documented. The description fails to explain the roles of several parameters (especially age_at_1_july and unused_concessional_cents), which are likely central to the headroom calculation. It also does not mention how financial_year or age thresholds affect the caps. An agent would struggle to provide correct input values without domain knowledge.

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% and there are six parameters, so the description must compensate. It provides some meaning for total_super_balance_cents ('prior 30 June figure') and the general 'integer cents' convention, but leaves age_at_1_july, financial_year, concessional_ytd_cents, non_concessional_ytd_cents, and unused_concessional_cents semantically unexplained. This is a significant gap for an agent trying to supply correct inputs.

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 calculation ('remaining room under the concessional and non-concessional caps') with a clear resource (contribution caps) and an identifiable verb ('Remaining room'). It also specifies the input basis ('from the figures given') and that cited rules are output, which differentiates it from sibling tools like list_rules or caps that merely display rules or cap amounts.

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: when you already have YTD contribution figures and need to compute remaining headroom. However, it provides no explicit guidance on when not to use it or which sibling alternative might be appropriate, such as caps for static cap amounts or list_rules for rule texts. The context is clear but the exclusions and alternatives are absent.

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 behavioral disclosure. It supplies meaningful context: the Sydney calendar/timezone conversion for `now`, and that `now` may be an ISO datetime with offset or a date. It does not claim destructive/read-only behavior, so there is no contradiction, but it stops short of describing edge cases like invalid ids or day-count inclusivity.

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 concise and front-loaded: the main purpose appears in the first sentence, followed by the `now` parameter detail using backticks, and a one-sentence legal/informational disclaimer. The disclaimer is slightly peripheral to tool invocation but not bloated.

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

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

For a two-parameter tool with an output schema, the description covers the required target values, the optional `now` behavior, and the timezone semantics needed to invoke it correctly. It is complete enough without needing to describe return values because an output schema is present.

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 bare schema. It does so thoroughly: it lists the valid deadline id values, allows YYYY-MM-DD as an alternative target format, and explains the accepted formats and Sydney conversion for `now`. This adds substantial meaning beyond the parameter names.

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 that the tool computes days from today on the Australia/Sydney calendar to either a named deadline id or an explicit date. It distinguishes itself from sibling rule-list/retrieval tools by being a date-calculation tool, and it enumerates the accepted deadline ids.

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: the agent can infer the tool is for calculating days until a known deadline or date. However, the description gives no explicit guidance on when to prefer this over sibling tools such as list_rules, get_rule, or search_rules, and it does not mention exclusions or 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?

With no annotations provided, the description carries the behavioral burden. It states the operation is a read-style 'Return' and discloses the output components plus the informational nature of the rules. It does not cover not-found or error behavior, but for a simple get-by-id tool this is reasonably 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?

Two sentences, no filler. The core purpose and return contents are front-loaded, and the disclaimer is kept separate and brief.

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 it has only one required parameter and an output schema, the description is largely sufficient for calling the tool. The main gap is not pointing to list_rules or search_rules as the source of a rule id, but that is not essential for a basic get operation.

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% and the description never explains the 'id' parameter or where it comes from. The parameter name is self-explanatory, but the description adds no meaning beyond the schema.

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

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

The description opens with a specific verb and resource: 'Return one rule in full'. It enumerates concrete content areas (summary, figures in cents, mechanics, sources and provenance), which clearly distinguishes it from list/search siblings that would not return the full rule detail.

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 use when you need complete detail about a single rule, but it never explicitly says when to use this tool instead of list_rules or search_rules. The 'not a licensed financial service' sentence is a disclaimer, not usage 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It adds a helpful content limitation ('General information about the rules, not a licensed financial service') and the verb 'List' implies a read-only operation. It does not explicitly state read-only status, auth expectations, or behavior for an invalid/missing category, but for a simple listing tool with an output schema this is a reasonable baseline.

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 and front-loaded. The first sentence states the core action, the second gives the category vocabulary in a scannable list, and the third adds a relevant caveat. Every sentence earns its place and there is no redundant prose.

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 a single optional parameter and an output schema, the description covers how to invoke it, which categories are valid, and the general nature of the returned information. It is functionally complete for calling the tool correctly, though it could be stronger with a brief pointer to sibling search tools for broader lookups.

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 only provides the category field as an optional string/null with a default of null, and schema description coverage is 0%. The description compensates by stating that category is an optional filter and enumerating the valid category values: caps, contributions, deadlines, division-296, franking, glossary, pension. This adds real meaning beyond the schema, though it doesn't explain what each category represents.

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 action and resource: 'List the rules in the corpus, optionally filtered by category.' It also lists concrete category values, which adds specificity. It does not explicitly distinguish itself from sibling tools like search_rules or get_rule beyond the different verb, so it stops short of a 5.

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

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

The description makes the intended use clear: an agent should call this to list rules, optionally narrowing by a listed category. However, it gives no explicit guidance about when to prefer search_rules or get_rule instead, nor any exclusion criteria. Usage is implied rather than explicitly contrasted with 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?

With no annotations, the description carries the full behavioral disclosure burden. It does disclose the token-matching behavior and ranking by hits, which adds value beyond the tool name and schema. However, it does not clarify case sensitivity, which parts of a rule are searched (e.g., title vs. body), result size limits, or pagination, so the behavioral picture is only partially complete.

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, no filler. The core function and algorithm are front-loaded in the first sentence, and the second sentence adds a useful context/disclaimer. 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 low-complexity, single-parameter search tool with an output schema present, the description is largely sufficient: it explains what the tool does, how matching works, and how results are ranked. The only notable gap is the lack of explicit guidance on when to choose this over sibling tools, which is minor given the clarity of the stated purpose.

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 0%, so the description must compensate. It does: 'query's words' clarifies that the single string parameter is tokenized into words for matching, and it explains how those words are used ('simple token match, ranked by hits'). This adds real meaning beyond the bare property name 'query'.

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

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

The description states a specific verb and resource: 'Find rules whose text contains the query's words'. It also adds clarifying detail about the matching algorithm ('simple token match') and ordering ('ranked by hits'), making the tool's function immediately clear and distinguishable from sibling tools like list_rules, which would list rules, and get_rule, which retrieves a single rule.

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

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

Usage is implied rather than explicit: the description indicates this tool is for finding rules by text content, which suggests it is the right choice when searching by keywords rather than enumerating or fetching specific rules. However, it does not explicitly state when not to use it or name alternatives as preferable in certain situations, leaving some inference to the agent.

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