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

With no annotations provided, the description carries the full disclosure burden. It adds several non-obvious behaviors: that no standalone material identifiers are returned, that the material_reference from the same item must be used when citing, and that platform/country filtering is unsupported. These are meaningful beyond the schema. It does not mention read-only status or error semantics, but as a 'get' tool the non-mutating nature is reasonably implied. The description goes beyond the bare minimum.

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 five sentences, each earning its place: the first states purpose, the second lists return fields, the third gives a citation rule, and the last two state constraints. The most important information (what the tool does) is front-loaded. It is slightly longer than minimal but not verbose, and the structure is logical. A very slight redundancy exists between 'No standalone material identifiers are returned' and the citation rule, but they convey distinct aspects.

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 7 parameters with 100% schema coverage and no output schema, the description provides a good picture: it lists all return fields, states key limitations, and includes a critical usage rule (citing material_reference). It does not explain edge cases (e.g., empty results, conflicting parameters) or pagination behavior, but those are partly covered by the limit/offset schema descriptions. For a ranking tool, this is adequate and leaves few obvious gaps.

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 every parameter (date, limit, offset, period, tag_name, rank_type, class_name) already has a clear description. The tool description adds little to parameter meaning—it restates that categories are optional ('optional primary/secondary category') and mentions the rising/evergreen split, but these are already in the schema for rank_type. It does not explain parameter interactions (e.g., how period and date combine) beyond what the schema states. Baseline 3 is appropriate.

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 opens with a specific verb ('Get'), a precise resource ('rising or evergreen creative rankings'), and the key dimensions (period, optional categories). It then enumerates the exact fields returned, making the tool's function unambiguous. This clearly distinguishes it from sibling tools that handle game-level or store-level rankings, and from material search/detail tools.

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 states its scope ('by period and optional primary/secondary category') and discloses a hard limitation ('Platform/country filtering is not supported'), which implies when not to use it. However, it never names an alternative tool or explicitly says 'use this for X, use Y for Z'. The reader must infer that get_material_detail_v2 or search_materials_v2 would be used for different needs. This is functional but lacks explicit routing.

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