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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the payload is rendered as Markdown and an unknown slug fails with an error rather than returning empty results.

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, no filler, front-loaded with what is read and how it is returned before the slug precondition and the failure mode. Nothing is 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?

There is no output schema, so the description correctly covers the return format (Markdown) and the error case. Combined with rich annotations, an agent has enough to call this tool correctly; only slug validation details are left solely to the schema.

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 carry the load, and it partly does: it expands the lang enum into the four human-readable languages and frames slug as a known site article identifier. It does not, however, describe the slug format constraints (lowercase hyphenated, max 100 chars) that the schema pattern enforces.

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 (Read), a specific resource (one published article), a scope (Chinese, English, Thai or Japanese) and a return format (Markdown). The resource is clearly distinct from the sibling tools (reference sources, product catalog, stick), though no sibling is named explicitly.

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?

"Use a known article slug from the site" gives a precondition, and the error-on-unknown-slug note helps, but there is no explicit when-to-use versus an alternative or discovery path for when the slug is not known. Usage is implied rather than prescribed.

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 readOnly, idempotent, non-destructive and openWorld behavior, so safety is covered. The description adds useful scope context ('current public' products) and a citation constraint about preserving review dates and limits, but says nothing about result size, freshness guarantees, or whether the response is cached/paginated.

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 the resource scope front-loaded and the citation caveat second. Both sentences carry information, though the second is an obligation rather than an aid to invocation.

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, the description does list the categories of data returned (products, languages, routes, pricing sources, availability), which is enough for an agent to know what to expect. It could go slightly further on format or size, but for a zero-parameter read with full annotation coverage this is adequate.

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 and the baseline of 4 applies. The description correctly implies the tool is unfiltered and returns the full catalog.

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 clear verb (Read) and enumerates the concrete resources returned: public products, supported languages, routes, pricing sources and availability. Sibling tools (get_article, get_wong_tai_sin_stick, get_reference_sources) are obviously distinct, so no explicit differentiation is needed, but the description never says how it differs from a generic catalog lookup.

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?

There is no guidance about when to call this tool, when not to, or what alternatives exist. The only instruction — 'Preserve the catalog review dates and limits when citing it' — is about downstream handling of results, not about tool selection.

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, openWorldHint and destructiveHint=false, covering the safety profile. The description adds behavioral context beyond that: it describes the payload as an 'index' with citation scope, limits and dataset versions, and explicitly states it does not fetch linked pages, which prevents the agent from expecting per-URL content.

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, front-loaded with the resource and its contents, with the clarifying limitation placed last. No filler or restated metadata to trim.

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 parameters, the description must carry the return-value burden, and it does — it enumerates the index contents (links, languages, citation scope, limits, versions) and rules out page fetching. 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 the baseline of 4 applies. The description is consistent with a no-argument tool and gives no misleading hints about 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 uses a specific verb ('Read') and resource ('the current public reference index') and then enumerates its contents: source links, languages, citation scope, limits, dataset versions. This is far from a tautology and clearly distinguishes it from the sibling tools (catalog, article, stick), though it never explicitly names those 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?

There is no explicit statement of when to prefer this tool over the siblings, so usage is only implied. The closing sentence 'It does not fetch each linked page' does provide a useful negative boundary — the agent learns this returns an index, not page content — which lifts it above pure absence of 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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds value beyond them: it discloses the return content (published reference and reading) and the language dimension, plus the explicit non-random/non-personalised boundary. Auth and rate-limit behavior remain unstated, so not 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?

Three short sentences with no filler: the core action and range come first, the return content second, the negative boundary last. Every sentence adds a distinct piece of 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?

For a simple two-parameter read-only lookup with annotations covering the safety profile, the description supplies purpose, scope, return content, and exclusions. The absence of an output schema means the exact shape of the returned reference/reading is only summarized, which is the only material gap.

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 carry the parameter burden, and it largely does: it states the sign_number range (1 to 100) and that language is Chinese or English, matching the zh/en enum. It does not name the parameter keys or clarify the enum tokens, so it compensates well but not fully.

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 ('Look up an existing Wong Tai Sin stick number'), pins the range 1-100, and clarifies the operation against near-neighbors ('does not draw a random stick or create a personalised reading'). It does not differentiate against the actual siblings (get_reference_sources, get_product_catalog, get_article), which are unrelated, so a 4 rather than 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?

Gives clear context for when to use it (retrieving an existing/published stick) and an explicit exclusion set: it is not a random draw and not a personalised reading. No alternative tool is named as a substitute for those excluded cases, so it stops short of a 5.

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