ReadGZH

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

No annotations are provided, so the description must carry the burden. It only mentions 'cached' to indicate source, but does not disclose what happens on missing slug, required permissions, rate limits, or return format. Lack of output schema further reduces transparency.

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 wasted words. The first states the action, the second provides usage context. Well-structured and 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?

Given the tool's simplicity (one required parameter, no output schema), the description is adequate but incomplete. It does not describe the return value structure or error scenarios, which would be helpful for an agent.

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%, but the description adds value by explaining the slug as a 'short slug/URL path' and providing an example ('minicpm-o-4-5'). This clarifies the parameter beyond the schema's minimal description.

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 'get a cached WeChat article by its short slug/URL path', specifying verb and resource. It distinguishes from siblings by mentioning 'cached' and 'slug', but does not explicitly contrast with other tools like readgzh.list or readgzh.search.

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 gives explicit guidance: 'Use when you have a slug ... from a previous read.' This tells when to use the tool, but does not discuss when not to use it or alternative tools.

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 provided, but description states it returns titles, authors, and links, implying a read-only operation. However, it does not explicitly mention lack of side effects, authentication needs, or rate limits.

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 wasted words. Front-loaded with purpose, followed by useful context. Could be slightly more structured but effective.

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 list tool, it covers key aspects: what it does, what it returns (titles, authors, links), and the limit parameter. No output schema, but return value hint is provided. Missing details on recency definition but acceptable.

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% for the single 'limit' parameter, with description in schema. The tool description adds no additional meaning beyond what the schema provides.

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?

Clearly states the verb 'List' and the resource 'recently cached WeChat articles', distinguishing it from sibling tools like readgzh.get (specific article), readgzh.read (content), and readgzh.search (search).

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?

Indicates it's useful for browsing previously read and cached articles, providing clear context for when to use this tool over alternatives. Lacks explicit exclusions but suffices.

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 must disclose behavioral traits directly. It does this well by highlighting the key limitation: 'IMPORTANT: this only covers articles already cached by ReadGZH — WeChat has no public API for a full account archive, so the result is not exhaustive.' This is crucial non-obvious behavior beyond the basic action of listing. It also explains the reason, which helps the agent understand the tool's scope. It does not mention auth requirements or return format, but the main gotcha is covered.

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, each with a clear purpose: the first states the core function, the second delivers the critical caveat in an 'IMPORTANT' callout, and the third provides a practical usage scenario. It is front-loaded with the action and resource, and there is no redundant 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?

Given the tool's relative simplicity (2 parameters, no output schema), the description provides the essential context: what it does, its limitation regarding cached data, and when to use it. It lacks details about response format or pagination, but those are not required if not specified in the schema. The description is sufficiently complete for an agent to effectively select and invoke the 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?

The input schema already provides full descriptions for both parameters (account and limit), including defaults and partial-match support. The description itself does not add any parameter-specific semantics beyond referring to 'one Official Account', which aligns with the 'account' parameter. With schema_description_coverage at 100%, the baseline is 3, and the description does not elevate it further.

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: 'List cached WeChat articles published by one Official Account (公众号) via ReadGZH.' It names the specific resource (articles), the scope (one account), and the service (ReadGZH), which distinguishes it from sibling tools like 'list' (general) or 'search'. The usage sentence reinforces the purpose: 'Use it to find other articles by the same author after reading one.'

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 a concrete use case: 'Use it to find other articles by the same author after reading one.' It also sets expectations with the caveat that it only covers cached articles and is not exhaustive, which implicitly tells the agent when not to use it (e.g., when a full archive is needed). It does not explicitly name alternatives, but the context 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?

Discloses caching behavior and output format (Markdown). No annotations exist, so the description carries the burden, and it adequately covers the read-only nature and 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 sentences efficiently convey purpose, procedure, and caching detail. The description is front-loaded and concise with 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 simple single-parameter tool with no output schema, the description sufficiently explains input and expected output, including caching. It lacks only potential error handling details.

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 description adds an example URL and clarifies that the parameter is a WeChat article URL, adding meaningful context beyond the raw 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 states the tool reads and extracts full text of a WeChat article, listing input and output specifics. However, it does not differentiate from sibling tools like readgzh.get or readgzh.search, which may have overlapping functionality.

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 providing a URL but offers no guidance on when to use this tool versus alternatives, nor any conditions or prerequisites.

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, description must disclose behaviors. It mentions cached articles and snippets but lacks details on authentication, rate limits, or cache freshness.

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 no filler, front-loaded with purpose and scope.

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 search tool, description covers main behavior and output. Could mention caching implications or result fields, but adequate overall.

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 baseline 3. The description rephrases the schema's parameter info without adding new meaning.

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 cached WeChat articles by keyword in titles and content, returning snippets. This distinguishes it from siblings like get, list, and read.

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 as searching by keyword, but no explicit guidance on when to use over siblings or when not to use.

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