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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions billing per call (1 credit) but does not state whether this is a read-only operation, any rate limits, pagination behavior, or what happens if both user_id and unique_id are omitted. The lack of these details leaves the agent uncertain about side effects and constraints.

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 concise (one sentence) but mixes purpose with unrelated metadata ('Group: User Related API. Billing per call: 1 Credits'). The structure is acceptable but could be improved by separating core purpose from pricing/group info. It is not overly verbose, but the phrasing is a bit clunky.

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 the tool has 4 parameters, no output schema, and no annotations, the description is incomplete. It does not explain how to use the cursor for pagination, what the response format looks like, error scenarios, or prerequisites. For a list endpoint, this lack of context makes it difficult for an agent to use the tool effectively without additional assumptions.

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?

The schema descriptions already cover all four parameters with examples and constraints (count max 35, cursor described as 'hasMore', etc.). The description adds minimal value by indicating that either unique_id or user_id is required ('unique_id or user_id is not empty'), but it doesn't elaborate on parameter usage beyond what's in the schema. Since schema coverage is 100%, a baseline of 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 clearly states 'get user favorite videos' and identifies the resource as user's favorite videos. It also mentions that either unique_id or user_id can be used. However, the wording is slightly awkward ('for latest unique_id or user_id is not empty') and it doesn't explicitly differentiate from sibling tools like get_userPublishVideo, though the purpose is still clear.

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?

No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or when to prefer get_userPublishVideo or other user-related tools. The only contextual hint is the billing cost, which is not a usage guideline.

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