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

No annotations are provided, so the description carries the burden, and it does disclose the governing rule (fiscal year runs 1 July–30 June), which is the essential behavioral fact for interpreting results. It is a pure deterministic mapping with no side effects, auth needs, or rate limits to disclose, though it does not address boundary-date 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?

Two sentences, zero waste, with the core semantic definition front-loaded before the usage instruction. Nothing is padded or redundant.

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 deterministic conversion with a full input schema and an output schema, the description supplies the one piece of semantics the schemas cannot encode — the definition of the Australian financial year. Nothing needed 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 description coverage is 100% and the single 'date' parameter already documents its YYYY-MM-DD format in the schema. The description adds nothing parameter-specific, so the 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 and resource ('Map a date to the Australian financial year') and immediately defines the domain concept by its boundaries (1 July to 30 June). An agent knows exactly what transformation this performs without opening the schema, and no sibling competes for this function.

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?

Explicitly says 'Use this whenever a question involves an Australian financial year, rather than assuming a calendar year' — a clear trigger condition plus a caution against the default calendar-year assumption. It stops short of naming alternatives, but no sibling tool is a real substitute for this conversion.

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 does disclose a meaningful behavioral trait of the output: the `queryable` field's three states and what each means for downstream calls. However it says nothing about permissions, rate limits, or cost, and an output schema already exists.

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?

Front-loads the purpose in one sentence, then uses a tight second block to explain the `queryable` states and the follow-up calls. Every sentence earns its place with 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?

An output schema exists so return values needn't be re-explained, and the description covers the one output field an agent must act on (`queryable`) plus the routing to preview/query. Minor gap: no mention of the portal parameter's default or multi-portal behavior.

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 both parameters are already documented, making 3 the baseline. The description adds only that dataset_id comes from search_datasets; it says nothing about the portal parameter or its default.

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: 'Get one dataset's full metadata and its list of resources (files).' This clearly distinguishes it from siblings like search_datasets (list/search), preview_resource and query_resource (operate on resources).

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?

Explicitly routes the agent downstream: use the resource_id of a queryable resource with preview_resource and query_resource. It also implies the entry point by noting dataset_id comes from search_datasets. No explicit 'when not to use' statement, but the chaining guidance 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?

No annotations exist, so the description carries the full burden. It does disclose meaningful behavior: result ordering (largest first), an inclusion filter (only publishers with >=1 public dataset), and that the first result is the portal's largest publisher. It does not state that this is a read-only operation, nor anything about permissions or what happens past the limit cap.

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, front-loaded with the core action and ordering, then the inclusion rule, then the parameter hint. Nothing is repeated from the schema and no sentence is 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-required-parameter read tool with an output schema and full schema coverage, the description supplies ordering, filtering rules, and the q/limit interaction, which is enough to call it correctly. The only gap is the absence of any explicit read-only/safety statement, which matters slightly given there are no annotations.

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 real meaning beyond the schema: it explains why q exists (results beyond the default limit are not returned, so q is the way to locate a specific publisher) and ties q to the limit behaviour. That interaction is not visible from the parameter descriptions alone.

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 ("List a portal's publishers") plus the enrichment it performs (dataset count per publisher) and the ordering (largest first). This distinguishes it from list_portals and search_datasets by resource and shape, though it never names those siblings, and the name/detail mismatch ("organizations" vs "publishers") is resolved only by reading the description.

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 one concrete usage hint ("use q to find a specific one beyond the limit") and a scope constraint (only publishers with at least one public dataset are counted). However, it never says when to pick this over search_datasets or list_portals, so routing must be inferred from the resource noun.

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 supplied, so the description carries the burden. It does disclose the behavioral shape of the response (a fixed enumeration including dataset counts) and 'list' implies a safe read, but it says nothing about cost of the call, whether counts are cached/live, or any permission requirements.

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 filler. What it returns is front-loaded and the usage trigger follows; no sentence could be removed without losing 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?

An output schema exists, so return-value documentation is not the description's job, and the description still conveys the essential content (portals plus dataset counts). For a no-arg read-only enumeration, nothing an agent needs to invoke 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the empty schema is self-explanatory and the description correctly adds no parameter claims. Baseline 4 applies for a parameterless tool.

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 ('List the Australian open data portals this server can query') plus the payload detail ('with dataset counts'). It implicitly separates itself from list_organizations by scoping to portals/data sources, but never names a sibling to make the distinction explicit.

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 a clear trigger condition: 'Call this when the user asks what data sources are available.' That is actionable context, but there are no exclusions or named alternatives (e.g. use list_organizations for publishers, search_datasets for keyword lookup).

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 disclose real behavioral traits: a cost/side-effect profile (free for portal DataStore resources, otherwise it downloads and caches the file and makes the follow-up query free). It still omits permissions/auth requirements, whether the caching is durable across sessions, and failure modes for missing resource_id.

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 earning its place: one defines output, one defines the call ordering requirement, one explains cost. The prerequisite is front-loaded rather than buried at the end.

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?

An output schema exists, so return values need not be explained, and the description still summarizes them usefully. It covers the prerequisite, the cost model, and the caching side effect, leaving only auth/permission context and error behavior unaddressed — modest gaps for an otherwise well-specified read-with-caching 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%, so resource_id, limit, and portal are already documented in the schema; the baseline is 3. The description only alludes to the sample size implicitly ('a sample of rows') and adds no formatting or portal-selection guidance 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 first sentence names a specific verb plus the exact payload the agent gets back: columns, column types, sample rows, and total row count. That is enough to separate it from get_dataset (metadata) and query_resource (SQL execution) without opening either 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 states an explicit prerequisite ('ALWAYS call this before query_resource') and gives the reason ('you cannot write correct SQL without first seeing the column names'), which is precisely the routing decision an agent needs. The alternative tool is named and the condition that triggers this one is unambiguous.

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 largely succeeds: it discloses read-only semantics, the DuckDB dialect, the fixed table alias `t`, and hard restrictions (no DDL, no DML, no other tables or files). It omits timeout/error behavior on violations, which keeps it short of 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 short paragraphs, front-loaded with the action and then the constraints. Every sentence carries information; nothing is repeated from the name or title.

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?

An output schema exists, so return format need not be explained, and required params are documented in the schema. The description covers dialect, restriction scope, and table naming; only edge-case behavior (errors, timeouts) 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 baseline is 3. The description reinforces the dialect and table naming for the `sql` param but adds no syntax examples, escaping rules, or guidance beyond what the schema already states.

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?

Starts with a specific verb+resource ('Run a read-only SQL query over one tabular resource') and states the return ('get the rows back'). This distinguishes it from siblings like preview_resource and get_dataset, which do not accept SQL.

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 constrains the operation (single SELECT, DuckDB, table `t`) but never says when to choose this over preview_resource or how to obtain a queryable resource_id (the schema covers the latter). Usage is implied by the SQL-execution framing rather than explicitly routed.

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 behavioral burden, yet it discloses nothing beyond the one-line purpose. It does not say whether results are paginated, how ranking works, whether the portal parameter changes coverage, or anything about rate limits or read-only safety.

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 front-loaded sentence with no filler or redundancy. It is efficient, though its brevity borders on under-specification rather than disciplined 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?

An output schema exists, so return values need not be explained, and the rich schema covers all five parameters. However, for a multi-portal search tool with zero annotations, the description omits scoping behavior (e.g. that portal defaults to federal only and 'all' broadens coverage) that would help an agent 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 description coverage is 100%: q, limit (cap 50), format, portal, and organisation are all documented in the schema, including the portal enumeration semantics in prose. The description adds no parameter meaning beyond that, so the 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 (search) and resource (Australian government datasets) with the query mechanism (keyword). It is clear on its own, but it does not differentiate itself from siblings like get_dataset or query_resource, which an agent must infer.

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 when-to-use guidance, no prerequisites, and no mention of alternatives. The agent must infer that this is the discovery entry point versus get_dataset (single record retrieval) or query_resource (data extraction) purely from the names.

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 still discloses the behavioral profile that matters: the check is deterministic and authoritative (modulus-89 against the ATO checksum), which tells the agent the result is trustworthy and not heuristic. It doesn't mention error behavior for malformed input, but as a stateless pure validator that is a minor 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?

Two short sentences with no filler; the what is front-loaded and the why/when follows immediately. Every clause 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 one-parameter validator with an output schema present, the description supplies everything the agent needs: what is validated, against what authority, and why to prefer it over inference. Return format is covered by the output schema, so nothing essential 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% and the single parameter's format ('11 digits, with or without spaces or hyphens') is fully documented in the schema. The description adds no parameter-level detail beyond that, so the 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?

The description gives a precise verb plus resource ('Validate an Australian Business Number') and even names the authoritative mechanism ('ATO's official checksum'). No sibling tool in the set performs validation, so the scope is unambiguous at a glance.

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 tells the agent when to use it ('Use this instead of judging an ABN yourself') and names the alternative it is displacing — self-reasoning. It gives the rationale (deterministic modulus-89), though it offers no explicit exclusions or edge-case conditions.

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