show_generationGet the full detail of one of your generations by task id — prompts, model, ref counts, saved/failed counts, ETA hint, asset ids.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | Task id from generate_image or list_generations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds context about the response contents (prompts, model, counts, etc.) but does not disclose other behavioral traits like rate limits, permission requirements, or response format beyond the field list. Since annotations cover the main behavioral aspect, a score of 3 is appropriate.
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 that front-loads the core action ('Get the full detail...') and then lists the useful response contents. Every word adds value with no redundancy.
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 lookup tool with one parameter and no output schema, the description is complete: it identifies the resource, the lookup key, the response contents, and implicitly differentiates from list-oriented siblings. No further information is needed for an agent to select and invoke it correctly.
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% for the single parameter (taskId), with its own description. The tool description reinforces that it's 'by task id' and the schema states the source, which is helpful, but the description adds little beyond the schema's own parameter documentation. Baseline 3 applies.
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 verb ('Get'), resource ('one of your generations'), and key dimension ('by task id'), while enumerating the details returned. This distinguishes it from siblings like list_generations (which lists all) and check_job_status (which only checks status).
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 it: when you have a specific taskId and need full generation details. The schema further clarifies the taskId source (from generate_image or list_generations). However, it does not explicitly mention when to use an alternative, such as list_generations for summaries or check_job_status for status only, so it falls just short of 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.
Several tools occupy nearly identical semantic ground: apply_iphone_realism and apply_ugc both describe casual phone-shot looks, upload_media and upload_reference_asset both accept uploads, and analyze_video overlaps heavily with analyze_video_report. The many apply_* style tools are essentially one tool parameterized by style, so agents can easily select the wrong one.
Most tools follow a clear verb_noun snake_case pattern such as generate_image, list_my_videos, get_editor_run, and upscale_video. A few outliers like voice, talking_avatar_video, and video_to_prompt do not use the same verb-first convention, but they are still readable and do not create significant confusion.
At 55 tools, the surface is far beyond what is appropriate for an MCP server; many of these be collapsed or parameterized, especially the 10 apply_* style wrappers and several overlapping upload/status helpers. Even for a broad media platform, this scale forces a huge context window and makes selecting the right tool impractical.
The surface covers generation, media display, video analysis, and Editor workflows well, but there are obvious gaps in library lifecycle management: move_asset and create_folder are referenced in tool descriptions without being exposed, and there is no clean way to delete or reorganize media assets. Agents following the descriptions will try to call tools that do not exist.