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

Annotations already cover read-only and open-world traits, but the description adds genuinely non-derivable context: the call costs 1 credit and results are cursor-paginated. It still doesn't say anything about the volume or shape of returned videos.

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 short sentences, front-loaded with the resource and immediately followed by the use-case gloss and the cost note. Nothing is redundant with 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 no output schema, the description should hint at return structure; the cursor reference implies a paginated list, and the credit cost is disclosed. Minor gap: it doesn't confirm what a page contains (video objects vs. ids).

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 75%, so the schema already documents song (music id or URL), count and cursor. The description only reinforces the cursor's paging role and leaves count limits and cache_max_age entirely to the schema, so the baseline 3 applies.

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 resource with a concrete framing: videos built on a given sound, i.e. 'who is using my track'. This clearly separates it from tiktok_song (sound metadata) and the other *_Videos siblings, though it never names those siblings explicitly.

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 'who is using my track' framing implies the use case, and the cursor mention signals paging through results. However, there is no explicit when-to-use vs. when-not guidance and no pointer to tiktok_song for retrieving the sound id needed as input.

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