Видео объявлений

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

Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds a small amount of context by stating that IDs are required by the API and that fetching goes through raw_request (advideos/add), but it does not cover output structure or edge-case behavior.

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 short and front-loaded with the core purpose. The parenthetical about raw_request is slightly technical but not verbose, and no words are wasted.

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 simple get-with-IDs tool, the annotations and schema handle most context. The description is adequate, but with no output schema and no mention of return or error behavior, an agent lacks some information about what to expect after the call.

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?

Input schema has 100% parameter description coverage: ids, limit, and offset are all documented. The description only repeats that ids are required, so it adds little beyond the schema. This matches the baseline 3 for full schema coverage.

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 clearly states a specific action ('Читает') and resource ('видео из библиотеки видео по id'), making it obvious this is a read operation for video-library entries. It implicitly distinguishes itself from siblings like get_ad_images and get_creatives by focusing on videos, though it does not explicitly contrast itself with them.

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 conveys when to use the tool: when you need to read videos from the library by given IDs. However, it does not provide clear exclusions or alternatives, and the note about raw_request/advideos.add is more implementation detail than usage guidance.

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