Skip to main content
Glama

hyperframes_to_mcpvideo

Render a Hyperframes composition and run mcp-video post-processing in a single step to create the final video output.

Instructions

Render a Hyperframes composition and post-process with mcp-video in one step.

Args: project_path: Absolute path to the Hyperframes project directory. post_process: List of post-processing operations, each with 'op' and 'params' keys. Example: [{"op": "resize", "params": {"aspect_ratio": "9:16"}}] output_path: Where to save the final output. Auto-generated if omitted.

Input Schema

NameRequiredDescriptionDefault
overwriteNoExplicitly allow replacing existing media. Existing non-media files are protected.
output_pathNo
post_processYes
project_pathYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.16.4
    • addedInput schema / properties / overwrite
      Added value: +{
      +  "default": false,
      +  "description": "Explicitly allow replacing existing media. Existing non-media files are protected.",
      +  "title": "Overwrite",
      +  "type": "boolean"
      +}
  2. Changed1 schema field changedv1.16.0
    • addedInput schema / additionalProperties
      Added value: +false
  3. Addedv1.5.1

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses only that output_path is auto-generated when omitted; it says nothing about runtime/long-running behavior, whether rendering is idempotent, what happens on partial failure of post-processing, or what permissions/auth the pipeline needs.

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?

The one-line summary is front-loaded and states the core value proposition, followed by a compact Args block. The docstring formatting is mildly wasteful but every line conveys usable information, and there is no filler.

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

Completeness2/5

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

An output schema exists so return values need not be explained, but for a two-stage render pipeline the description omits critical context: which composition in the project is rendered, the vocabulary of valid post-processing ops, and failure/overwrite semantics beyond the schema's own overwrite field. An agent cannot reliably construct a correct post_process list from this alone.

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 25% (only 'overwrite' is documented), so the description must compensate — and it partly does: it gives an example post_process structure with 'op'/'params' keys and clarifies output_path auto-generation. However, it never enumerates valid 'op' values or their params, leaving the most complex parameter only half-specified.

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

Purpose4/5

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

Specific verb+resource: 'Render a Hyperframes composition and post-process with mcp-video in one step' clearly states it is a combined render+post-process pipeline. It is distinguishable from hyperframes_render (render only) by implication of the post-processing stage, though the sibling is never named.

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

Usage Guidelines3/5

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

Usage is only implied by the tool name and the phrase 'in one step' — an agent can infer this is the choice when post-processing is needed alongside rendering. There is no explicit when-not guidance, no mention of hyperframes_render as the simpler alternative, and no stated prerequisites for the Hyperframes project.

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

Deploy Server

Other Tools