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

With no annotations, the description carries the burden, and it discloses key behavior: the returned entity fields, the hard 180-day date cap, and the important semantic limitation that similarity is not proof of reuse. It does not cover pagination side effects or rate limits, but those are less critical for a read-only lookup as there are no destructive or auth-related behaviors to disclose.

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: the first states the core action, the second covers output and constraints, and the third covers a caveat and alternative. Every sentence earns its place with no 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?

For a 7-parameter tool with no output schema, the description covers the main invocation requirements (required dates, range cap, input reference) and lists the returned data fields. It could elaborate on response shape and edge cases such as default game-scope behavior, but the schema covers parameters and the return-field list is sufficient for correct invocation.

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?

All seven parameters are already described in the schema, so the description need not repeat them. It reinforces the date constraint and explains that detail_url holds an opaque material_reference, but adds no parameter-level syntax beyond the schema; 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 names a specific operation ('Find visually similar creatives') on a defined resource ('a complete material_reference') and notes the mechanism (stored video-content vectors). It also explicitly disentangles this tool from get_material_reuse_clues, so an agent can distinguish it from the most closely related sibling without opening other definitions.

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 explicitly states when not to rely on the tool ('Similarity does not establish reuse') and routes to the alternative get_material_reuse_clues for recorded reuse and chronology. It also flags the mandatory date range constraint, which tells an agent the tool cannot be used without a valid 180-day window.

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