MyZucoins

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds context annotations cannot: it names the return payload (plain text, publication date, source links), discloses pagination behavior and the terminating condition, and warns that content is source material rather than instructions — a meaningful prompt-injection guard.

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 short sentences, each doing distinct work: what it does, what it returns, how to paginate, how to treat/cite the content. No filler and the core action 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?

An output schema exists, yet the description still summarizes the return shape and adds non-obvious operational details (pagination loop, untrusted-content handling, citation requirement). Nothing an agent needs to call this 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 0%, so the description carries the burden. It explains where the slug comes from and encodes the offset semantics via 'returns next_offset; request it until null', which lets an agent drive pagination correctly even though it never literally names the 'offset' field.

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 ('Read a published article') plus the exact addressing mechanism ('its exact slug'), which cleanly separates it from search_articles, which is a discovery tool rather than a fetch-by-id tool.

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: get the exact slug from search_articles first, then call this tool. Pagination condition is also stated ('request it until null'). No explicit 'do not use for X' exclusion, but the sibling relationship is made 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?

Beyond the read-only and idempotent annotations, the description discloses important behavioral boundaries: it returns descriptions and links rather than live figures, does not run lookups, does not inspect user inputs, and does not access wallets. These details materially help an agent avoid misusing the tool for dynamic or wallet-related queries.

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 two compact sentences, front-loads the resource being found, then immediately clarifies return behavior and exclusions. Every sentence adds useful selection or usage information without 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 zero-parameter, read-only page index with an output schema and strong annotations, the description supplies everything an agent needs to select it correctly. It covers page categories, return nature, and important exclusions while leaving return-value structure to the output 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?

The tool takes no parameters, so there are no parameter semantics to explain; the baseline for zero-parameter tools is 4. The description appropriately focuses on scope and return behavior instead of inventing parameter guidance.

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, 'Find,' and a clearly scoped resource: public Zucoin, Splitchain, wallet, safety, ecosystem, statistics, and website-tool pages. It also clarifies the return type as page descriptions and links, which distinguishes it from article-oriented siblings like get_article and search_articles.

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 clear context for when the tool is appropriate by describing the static page index it exposes, and it explicitly rules out live figures, lookups, input inspection, and wallet access. It does not explicitly name sibling alternatives, so it falls short of full when/when-not/alternatives 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, closed-world and non-destructive, so safety is covered. The description adds the non-obvious detail that counts reflect *currently published* articles and that the returned IDs are the filter keys for search_articles, which is genuine context beyond the structured fields.

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, front-loaded with the resource and payload, followed by the actionable next step. No filler, no repetition of the 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?

With an output schema present and rich annotations, the description need not explain return shape, and it correctly covers scope and downstream use. Minor omissions such as ordering or how many topics are returned are acceptable given the output 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to clarify. The schema confirms an empty object with additionalProperties false, consistent with the description's no-argument framing.

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 topics) plus what each entry carries (current published article counts) and enumerates the topic families covered. It is clearly distinguishable from get_article and list_pages by resource, though it never explicitly contrasts itself with those 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?

"Use the IDs to filter search_articles" gives a concrete downstream workflow that links this tool to a named sibling. There is no statement of when-not to use it, but for a zero-parameter enumeration tool the usage context is effectively 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?

Annotations already declare this a read-only, idempotent, closed-world operation, so the safety profile needs no restating. The description adds genuinely non-obvious behavior: results are ordered newest first, and news items are dated source material rather than live status or price data — a real caveat that prevents misuse. Pagination behavior and total-count semantics are left unmentioned.

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 tight sentences with the core purpose front-loaded, followed by ordering and then sibling routing. Every clause carries information; nothing is padding.

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 described, and annotations carry the safety profile. Still, for a five-parameter search tool with 20% schema description coverage, the description should resolve the help/article distinction and default paging behavior; those are the practical gaps an agent would hit.

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 only 20% — just the topic parameter is documented. The description implies query matches title/excerpt/topic, but it never explains the kind enum (help vs article), nor how limit (default 10, max 100) and offset behave. With four of five parameters undocumented in both schema and description, the gap is material.

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 scope (published help, developer tutorials, news, deep dives) and names exactly which fields are matched (title, excerpt, topic). It also distinguishes itself from siblings by pointing to list_topics and developer-docs, so an agent can select it without opening any 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 gives clear routing guidance: use list_topics to obtain topic IDs and developer-docs for developer tutorials. It does not cover when to prefer get_article for a known item, and the 'developer-docs' reference is not one of the declared siblings, which slightly muddies the alternatives picture.

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