get_videoCheck a video started with create_video. Returns "queued" or "processing" while it renders, "completed" with the hosted video URL when it is ready, or a terminal failure if the render failed. Poll every few seconds until it is either completed or failed (both are terminal: stop polling once you see one). The clip is charged once, on completion.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The video job id returned by create_video. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and succeeds. It discloses the full state machine (queued/processing/completed/failed), that completed includes a hosted URL, that failed is terminal, and the billing behavior ('charged once, on completion'). This is rich behavioral context beyond what the schema provides.
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 sentences with zero wasted words. It front-loads the purpose, then covers states, polling behavior, termination conditions, and billing in a tight, readable structure.
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 single-parameter polling tool, everything an agent needs is present: what states to expect, what the final success state returns, when to stop polling, and the billing consequence. No output schema exists but none is needed given the state descriptions.
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 100%, and the single 'id' parameter is well described in the schema as the job id returned by create_video. The description reinforces this provenance by saying 'started with create_video' but adds no new parameter-level detail. Baseline 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?
States a specific verb and resource: 'Check a video started with create_video.' It clearly identifies the tool as the status-polling counterpart to the creation tool and distinguishes it from the sibling generation tools (create_video, generate_image, generate_speech, generate_text), which have different purposes.
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?
Provides explicit usage guidance: poll every few seconds, stop on terminal states, and the exact statuses to expect. It tells the agent when to use the tool (after create_video) and how long to keep using it. The terminal-state rule removes ambiguity about when to stop polling.
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 is primarily tied to a distinct modality or lifecycle step: image, music, speech, text, and video submission/polling. The only minor overlap is that generate_text can also produce SVG graphics, which borders on generate_image's territory, but the type parameter and logo hint keep them separable.
All tool names are lowercase snake_case verb_noun, which is readable and mostly predictable. The slight inconsistency is that four generators use generate_* while the video counterpart uses create_video and get_video instead of generate_video and check_video.
Six tools are well-scoped for a multi-modal generation server: text, image, music, speech, video creation, and video status. Each tool covers a necessary function without redundancy or bloat.
The tool surface covers every advertised generation modality and includes the required async polling lifecycle for video. No obvious dead ends or missing operations are needed for the core generation workflow.