Tell this server what you needed and could not get. Free — no payment required. Your input goes to the operator's queue and to a public board of unmet agent demand (contact details are never shared; entries are reviewed before publishing). Include what you would pay if you know.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | ||
| tried | No | ||
| contact | No | ||
| would_pay_usd | No |
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 and does so exceptionally. It details data flow (operator queue, public board), privacy safeguards (contact details never shared), review process (entries reviewed before publishing), and cost (free). This is comprehensive for a simple submission tool.
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 three sentences long, starts with the core purpose in the first sentence, and each subsequent sentence adds essential context (cost, data handling, user guidance). There is no redundancy or filler, and the structure is easy to skim.
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 lightweight tool with no output schema, the description explains the outcome (input goes to operator queue and public board) and the procedural details (review before publishing). The only minor gap is that it does not mention whether any confirmation or request ID is returned, but this is not critical for a simple submission tool.
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 description adds meaning to several parameters: 'what you needed' maps to need, 'Include what you would pay' relates to would_pay_usd, and 'contact details are never shared' addresses contact. However, the 'tried' parameter is never mentioned, and with 0% schema_description_coverage, the description only partially compensates for the missing schema-level explanations.
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 opens with 'Tell this server what you needed and could not get,' clearly identifying the action (submit a capability request) and the resource (the server's capability queue). It stands apart from sibling tools like fetch_video, get_job, or submit_video_job, which focus on video/job operations, making the purpose unambiguous.
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 statement 'Tell this server what you needed and could not get' implies the appropriate context: when an agent's need is unmet by existing tools. It also clarifies cost ('Free — no payment required'), which is relevant given a payment_info sibling exists. However, it does not explicitly name alternative tools or state when not to use it, so it lacks the explicit exclusion guidance seen in a 5.
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 has a distinct role in the video generation workflow: submit creates, get_job polls, fetch_video retrieves the result, list_jobs lists history, and the remaining tools cover voices, payment, service info, and feedback. There is no meaningful overlap between tools.
Most tools follow a verb_noun pattern (submit_video_job, get_job, fetch_video, list_jobs, list_voices), but payment_info and service_info use a noun_info pattern. This is a minor deviation; all names are clear, snake_case, and readable.
With 8 tools, the set is well-scoped for a video generation service. It covers job submission, monitoring, retrieval, listing, voice selection, and two informational endpoints, without unnecessary bloat or a feeling of incompleteness.
The core lifecycle is covered: submit, poll, fetch, and list jobs, plus listing voices and payment guidance. The only notable gap is the lack of job cancellation or update operations, but agents can work around this since the service is fire-and-forget.