Skip to main content
Glama

Export the finished video

export_video

Render the project to MP4 in the user’s editor, save it to their library and return a share link. Takes about as long as the video, so this returns a job id at once: poll get_job. The plan’s limits apply (Free: 720p with a watermark, videos up to 10 minutes, 10 exports a month; Starter 1080p; Pro and Business 4K).

Input Schema

NameRequiredDescriptionDefault
fpsNo
shareNoAlso make a public watch link (default true)
projectYesProject id from list_projects or create_project
qualityNo
resolutionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover safety (destructiveHint=false, idempotentHint=false, openWorldHint=true), and the description adds substantive context beyond them: asynchronous execution with immediate job-id return, approximate duration, and concrete plan quotas (720p + watermark, 10 min cap, 10 exports/month). That is exactly the operational and rate-limit information annotations cannot carry.

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

Conciseness5/5

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

Three sentences, front-loaded with the action and its effects, then the async behavior, then the constraints. No filler and no repetition of the title or name.

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

Completeness4/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 explains the return value (job id, later a share link) and the asynchronous contract, which is the main thing an agent needs. Minor gaps remain around failure modes (quota exceeded, render errors) and whether a re-export overwrites a previous one.

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?

Schema description coverage is only 40%, so the description should compensate. It partially does by tying resolution to plan tiers (720p/1080p/4K), but says nothing about fps, quality, or the share flag's semantics, leaving three of five parameters with no added meaning.

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 concrete verb and resource ('Render the project to MP4'), plus the three side effects: saved to library, share link returned, job id issued. An agent can distinguish this from siblings such as get_shared_video or get_job without opening any 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?

Explicitly routes the agent onward ('this returns a job id at once: poll get_job'), which is the key sequencing decision for a long-running operation. It does not state when *not* to use it (e.g. mid-edit, or which tool to use for a preview), so it falls short of full when/when-not coverage.

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.

Resources