Get trending DesAira videos by engagement for a time window (max 20).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-based) | |
| cursor | No | Opaque pagination cursor from a prior call | |
| window | No | Time window | |
| per_page | No |
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | ||
| videos | No | ||
| has_more | No | ||
| next_cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the 'max 20' limit and 'by engagement' ranking, but does not mention pagination behavior, default values, or any side effects. As a read-only operation, there is no destructive behavior to disclose, but it still could include more contextual detail like rate limits or required auth.
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 a single well-structured sentence front-loaded with the action and resource. Every word contributes meaning, with no redundant or vague 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?
The tool has an output schema and simple read semantics, so the description covers the core purpose and key constraints. It does not mention pagination defaults or behavior, but these are partially captured by the schema. Given the low complexity, the description is nearly complete but lacks explicit guidance on defaults or the relationship to sibling tools.
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 75% (3 of 4 params have descriptions). The description adds context for 'window' and 'per_page' via 'time window' and 'max 20', but does not explain 'page' or 'cursor'. The schema already documents page and cursor well, so the description adds marginal value but not enough to exceed baseline.
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 trending DesAira videos by engagement for a time window (max 20).' It uses the specific verb 'get', identifies the resource as trending videos, and includes key qualifiers 'by engagement' and 'time window.' This distinguishes it from sibling tools like get_feed or search_content.
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 implies when to use the tool (when retrieving trending videos with a time window) but does not explicitly contrast it with alternatives or provide exclusions. It lacks guidance on when not to use this tool versus siblings such as get_feed or search_content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource and retrieval mode: feed and trending differ by sorting, user and video are specific entities, creators and tags are directory listings, and search is a cross-cutting keyword query. No two tools are ambiguous in purpose.
All tool names follow a consistent snake_case verb_noun pattern, using get_ for entity retrieval, list_ for directory browsing, and search_ for keyword search. The naming is predictable and uniform.
Seven tools is an ideal size for a video platform's public API, covering browsing, discovery, and search without redundancy or bloat. Each tool earns its place in the set.
The server provides a comprehensive read-only surface: chronological feed, trending, user profiles with recent videos, video metadata, creator directory, tag categories, and keyword search. This fully covers the stated purpose of public content exploration with no obvious gaps.
