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 discloses several behavioral traits: returns cleaned plain text by default, returns PDF download URL instead of text for format pdf, falls back to scanned original if no typeset PDF exists, pdf_original_scan only available for pre-2008 as-enacted versions, max_chars truncation default 100000 and not applied to single section/schedule, and exclude options that affect output. It does not explicitly state whether the operation is read-only or has rate limits, but the sibling get_rate_limit_status exists. Given the absence of annotations, the description is quite transparent about output behavior and edge cases.

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 dense paragraph that front-loads the core purpose and then systematically covers variants. It is longer than ideal but every sentence adds meaningful behavioral or usage information. The structure is logical: core retrieval, section/schedule variants, discovery pointer, format variants. It could be slightly more scannable with line breaks, but it is not bloated or repetitive.

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 7 parameters, no output schema, and no annotations, the description is remarkably complete. It explains the default behavior, all parameter combinations, exclusions, format fallbacks, truncation behavior, and points to list_sections for discovery. The only minor gap is not describing the exact structure of the returned text/URL, but the description explicitly says 'returns the URL and metadata' for PDF formats and 'cleaned plain text' for text, which is sufficient for an agent to invoke correctly. The sibling get_rate_limit_status covers rate-limit concerns.

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 all 7 parameters. The description adds value by explaining the interaction between parameters: section/schedule cannot be combined, format cannot be combined with section/schedule, max_chars not applied to single section/schedule, and the fallback behavior for pdf format. It also clarifies that work_id resolves to newest version automatically. This goes beyond the schema's individual parameter descriptions, though the schema already does heavy lifting.

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 retrieves legislation text, with a specific verb ('Retrieve') and resource ('text of a piece of legislation'). It distinguishes itself from siblings by mentioning list_sections for discovering section numbers and by describing format variants (pdf, pdf_original_scan) that no sibling tool name suggests. The description also clarifies the difference between whole-document, section, and schedule retrieval, making its purpose unambiguous.

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 explicitly tells the agent when to use this tool vs alternatives: 'Use list_sections to discover numbers first.' It also provides clear conditional guidance: without section/schedule params returns whole document, with section returns just that section, with schedule returns just that schedule, and with format pdf returns URL instead of text. It also states constraints like 'Cannot be combined with section or schedule' for format, and 'Cannot be combined with schedule' for section. This is explicit when/when-not 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 provided, the description carries full behavioral disclosure. It transparently states that a minimal API request is spent by default, explains the reset time (midnight NZ time), and discloses that the burst limit is not reported in headers. This goes beyond basic purpose and informs the agent of side effects and limitations.

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, well-structured paragraph. It front-loads the core purpose, then details refresh behavior and limitations. Every sentence adds essential information; there is no filler or repetition. It is concise yet complete.

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?

Without an output schema, the description explains what the tool returns (remaining quota values) and covers the main operational details: refresh options, default behavior, reset time, and the absence of burst-limit info. An agent has enough context to invoke the tool correctly and interpret results.

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 single parameter 'refresh' is fully covered by the schema (100% coverage) with enum values and descriptions. The tool description adds value by clarifying the default ('api'), the meaning of 'none' (returns last observed without spending a request), and the distinction between API and feed quotas. This supplements the schema without redundancy.

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: it reports remaining daily quota from X-RateLimit-* headers, distinguishing between JSON API key and feed key. It clearly differentiates from sibling tools that handle legislation search/retrieval, making the tool's purpose unambiguous.

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 explains the default behavior (spends one minimal request) and the refresh parameter options, including the 'none' behavior for returning cached values. It also notes the burst limit is not reported, setting expectations. While it doesn't explicitly name alternatives, siblings are unrelated, so this is sufficient guidance for when to use the tool.

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 discloses that the tool returns metadata including format URLs, which is useful. However, it does not explicitly state that the operation is read-only or free of side effects, nor does it mention any prerequisites or error behavior. For a simple 'get' tool the implied read-only nature is reasonable, but the lack of explicit disclosure prevents a higher score.

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, concise sentence that front-loads the purpose ('Get metadata') and immediately provides specific details about the output. No unnecessary words or redundancy.

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 one parameter and no output schema, the description sufficiently explains what it returns (metadata and format URLs). It is complete for a simple read operation, though it does not mention any edge cases or additional metadata fields. Given the low complexity, this is nearly 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?

The input schema already describes version_id as 'A version_id from a search result or list_versions call', covering 100% of parameters. The description adds no additional information about the parameter or its usage, so it meets the baseline but does not go 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 clearly states the verb 'get' and the resource 'metadata for a single version', and further specifies the output includes available document formats and URLs. This distinguishes it from sibling tools like list_versions (which lists versions) and get_legislation_text (which gets text), so an agent can readily tell what it does.

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: when you need a single version's metadata and format URLs, this is the tool. However, it does not explicitly mention when not to use it or name alternatives. The distinction from siblings is implicit but not spelled out, 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.

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

No annotations are provided, so the description carries the behavioral burden. It does disclose the output scope (parts, subparts, section numbers, headings, schedules), which is the core contract for a read-only navigation tool. However, it does not address the both-optional-parameter case (what happens with neither work_id nor version_id), pagination for large documents, or how a work_id is obtained — meaningful gaps given there is no annotation coverage.

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 with zero waste: the first states purpose and output scope, the second gives the usage workflow. Every sentence earns its place and the key information 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?

Purpose, output scope, and workflow position are all present, and the parameter either/or relationship is fully covered by the schema. Minor gaps remain: the description doesn't note how to obtain a work_id/version_id (e.g., via list_versions) or what to expect on very large documents, and there is no output schema to describe the return shape.

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%: both parameters already carry the 'Provide either version_id or work_id' semantics and the 'newest version will be used' resolution note. The description adds no parameter-level detail, so the schema baseline of 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 ('List') and resource ('structure of a legislation document'), then enumerates exactly what is included: 'Parts, subparts, section numbers and headings, and schedules.' The content enumeration distinguishes it from siblings like get_legislation_text (content retrieval) and list_versions (version metadata).

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 positions the tool in a workflow: 'Use this before get_legislation_text to find the right section or schedule number.' It names the downstream alternative tool and the condition that selects it, leaving nothing 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?

No annotations are provided, so the description carries the full burden, and it does well: it discloses automatic pagination, the 100-per-page API limit, default sort order, the is_latest_version flag, and de-duplicated work-level metadata. This goes well beyond a bare 'list versions' statement.

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?

Four sentences, each earning its place: purpose, return shape, pagination behavior, and intended use case. The most important capability is front-loaded before implementation details.

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 no annotations, the description still tells the agent what results look like, how pagination behaves, and when to use the tool. Nothing essential for correct invocation or interpretation 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 all four parameters in detail. The description reinforces the page/per_page behavior and the work_id source, but adds little 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?

States a specific verb ('List') and resource ('point-in-time versions of a work'), with clear scoping by work_id. It distinguishes itself from siblings by describing what it returns (versions with URLs and is_latest_version flag) versus details, text, or sections.

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 to find a version_id for a specific date,' which gives a concrete use case. It also explains pagination behavior clearly, but does not name alternative tools or explicitly state when not to use 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?

With no annotations provided, the description carries the full burden. It discloses the auth requirement (LEGISLATION_NZ_RSS_API_KEY), describes the return contents (entries with URL, version_id, timestamp, feed URL), and flags the tool as legacy. It does not mention rate limits or error conditions, but the core behavior is transparent enough for a simple read 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?

The description is three sentences, with the core purpose and endpoint in the first sentence, return structure and use case in the second, auth and alternative in the third. Each sentence earns its place, and the most important information is front-loaded. 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?

For a one-parameter tool with no output schema, the description covers the essential aspects: what it reads, what it returns, the auth key, and when to choose an alternative. It omits explicit mention of pagination or output format, but since it is an Atom feed and the scope is small, the description is sufficiently complete for correct 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 100%, and the work_id parameter is already well-documented with an example. The description adds no additional parameter details beyond including work_id in the endpoint path, so it stays at the baseline score; no compensation is needed.

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 ('Read'), names the exact resource ('legacy Atom feed of a work's versions'), and cites the endpoint path. It also distinguishes itself from the sibling list_versions by calling out the preference for on-demand queries, leaving no ambiguity about what this tool does.

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 explicitly states when to prefer the alternative tool ('For on-demand queries prefer list_versions') and implies the suitable use case for this tool ('subscribable feed URL for change monitoring'). It also conveys the separate API key requirement, which is a key prerequisite for using this tool correctly.

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 full behavioral burden. It discloses meaningful quirks: ephemeral ids (~) carry ephemeral:true, latest_matching_version_is_latest is false when only an older version matched, and type-specific filters imply legislation_type. It does not cover rate limits or auth, but for a read/search tool these are less critical.

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?

Five sentences pack a large amount of information: scope, modes, return fields, a subtle result-field condition, filter interaction, ephemeral-id handling, and a usage priority hint. No filler or redundant restatement of schema details.

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?

This is a 17-parameter tool with no output schema and no annotations, but the description covers the essential behavioral nuances and result fields. Pagination/sorting defaults are left to the schema, which is acceptable. It gives an agent enough context to select and invoke the tool correctly in most situations.

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 adds cross-parameter semantics beyond individual schema entries: type-specific filters imply legislation_type and cannot be mixed, and browsing is achieved by omitting search_term. The Elasticsearch syntax and stemming note already appears in the schema, so the added value is useful but modest.

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 ('New Zealand legislation'), enumerating the categories and the two operation modes (search vs browse). It clearly describes the return fields. It doesn't explicitly contrast with the sibling search_legislation_rss, but the 'Use this first to find a work_id or version_id' hint helps define its role among the siblings.

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 first to find a work_id or version_id' and explains when to browse (omit search_term, use filters alone). It also warns that mixing type-specific filters is rejected. Missing: does not name alternatives for other tasks (e.g., list_versions, get_legislation_text), so the routing guidance is incomplete.

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 full responsibility and does so thoroughly: it discloses the legacy endpoint, the 100-entry limit, the need for a separate RSS-only API key, and the actual behavior of search_field where 'content' and 'fulltext' are both sent as content. It also notes paging is ignored. This exceeds what a typical description provides.

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 information-dense but well-organized, starting with the core purpose and then layering in essential behavioral details. It is slightly long, but every sentence serves a purpose—no filler. The structure is logical, moving from action to parameters to usage guidance.

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's complexity (5 params, no output schema), the description covers everything an agent needs: what it returns (entries with fields and a subscribable feed URL), the key requirement (API key), limitations (100 entries), and parameter semantics. It is self-contained and leaves no critical gaps for correct 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?

Although schema coverage is 100%, the description adds substantial meaning: it explains ElasticSearch query syntax, stemming and quoting, clarifies the search_field enum mapping, and describes the limit behavior and its interaction with the feed. This goes beyond the schema's terse descriptions.

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 searches New Zealand legislation via the legacy Atom feed, supports title/full-text search with filters, and explicitly differentiates from the sibling search_legislation by noting it is a superset for on-demand queries. The verb and resource are specific, and the distinction prevents ambiguity.

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 advises 'For on-demand queries prefer search_legislation, which is a superset,' giving clear when-to-use guidance and naming the alternative. It also explains the browse-by-filters use case when search_term is omitted, covering both main usage patterns.

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