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

Goes well past the readOnly/non-destructive/openWorld annotations: views is a sum over the last `days` days (default 30, JST day boundaries), while favorites/known/likes are current snapshot counts where `days` is ignored and the response echoes days as null. It also discloses that `known` excludes 知りたい, that closed rows suppress body text in `label`, that output is aggregate-only with no viewer identity, and that STG data is noisy.

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 core action, then the target/by matrix, then the metric semantics, then caveats — a sensible ordering with dense but purposeful sentences. The inline parentheticals («工夫», «見て知った», the STG warning) are justified because they prevent misreading the labels, though the combination list is heavy prose that a table would render more scannably.

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?

No output schema exists, so the description must explain returns, and it does cover the important ones: `label` (redacted for closed rows) and `days` (null for snapshot metrics), plus the aggregate-only nature of counts. It stops short of describing the full response shape (e.g., how ranks or counts per row are named), which is a modest gap for a ranking endpoint.

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?

With 0% schema description coverage the description carries the load, and it explains `target`/`by` enumerations and interactions plus `days` semantics (default 30, JST, ignored for non-view metrics) far beyond the bare enum lists. The `limit` parameter (1-100) is never mentioned, leaving one of four parameters defined only by JSON-Schema bounds.

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 behavior: returns a top-N list ordered by reader counts, enumerated per target (game/gene/claim/trivia/rumor/person) and metric (views/favorites/known/likes). The ranking-by-popularity angle distinguishes it from the plain listing siblings like gamegene_games, but it never names an alternative tool, so differentiation is implied rather than 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 full valid-combination matrix (which `by` applies to which `target`), states that unsupported pairs return an error, and warns against using STG/pre-launch numbers for trend conclusions because admin verification views are mixed in. It does not say when to prefer this over gamegene_search or the per-type sibling tools, which keeps it from a 5.

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