Skip to main content
Glama

Export video

export_video
Read-only

Free export: a 720p, 16:9 MP4 with a small watermark and a 2.5-second end card. It renders on the user's own computer inside the widget (about as long as the song), so this tool shows the widget and starts the export there; the user downloads the MP4 from the widget when it finishes. If their ChatGPT app can't render video, the widget offers to open the project in their browser instead.

Input Schema

NameRequiredDescriptionDefault
projectIdYesprojectId returned by create_lyric_video

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint/destructiveHint/false annotations: explains rendering happens client-side (~song length), that the tool only shows the widget and starts the export, that the user downloads the MP4 afterward, and what happens when rendering is unsupported. This is exactly the behavioral context annotations cannot convey and also explains why readOnlyHint=true is consistent (no server-side write).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences, front-loaded with the output spec, then the rendering location, then the fallback. Slightly verbose on the widget/download flow but every sentence carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly carries the return-path burden by telling the agent the MP4 is downloaded from the widget rather than returned. Combined with the fallback behavior, nothing an agent needs to call and explain the tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter and schema description coverage is 100%, with the schema already stating projectId comes from create_lyric_video. The description adds no additional meaning about the parameter, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource plus the exact output spec (720p, 16:9 MP4, watermark, 2.5s end card), and the leading word 'Free' implicitly distinguishes it from the HD export sibling. An agent can tell what it produces without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context for use (free export path, renders in the widget on the user's machine) and a fallback condition (if the ChatGPT app can't render video, the widget offers browser opening). It does not explicitly name export_hd_video as the paid alternative, so the when-not is only implied.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.