Skip to main content
Glama
hermoso-ai

Hermoso

Official
by hermoso-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Post-production edit

post_edit

Apply mechanical video edits—trim, speed, mute, audio gain, fade-out, watermark, end card, or film grain—to an existing MP4, returning a new video without re-rendering or AI.

Instructions

MECHANICAL post-production on an EXISTING rendered video (its served mp4 URL) — an ordered plan of whitelisted primitives executed by ffmpeg (+ Chrome for typeset cards) in seconds for ~2 credits flat, NO AI model, the original untouched (returns a NEW video). The lane for: append a branded end card ('add an end card with our logo and website' — ADDS its seconds, never re-renders), trim, speed (0.5-2x), mute (whole or a window), audio_gain (-20..+6 dB), fade_out, corner logo watermark, anti-AI film grain. Up to 6 ops per plan, applied in order. Brand assets (name/domain/logo/accent) load from the workspace brand automatically; override per-call if needed. NEVER use generate_video/render_ad for these mechanical asks.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opsYesthe ordered edit plan (max 6 ops)
accentNooverride the brand accent hex
domainNooverride the brand website
videoUrlYesthe served URL of the video to edit
brandNameNooverride the workspace brand name

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.161
    • changedOutput schema / (root)
      Previous value: -{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "additionalProperties": false,
-  "properties": {
-    "jobId": {
-      "description": "the render job id — poll get_job with this id to resume or inspect",
-      "type": "string"
-    },
-    "model": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "description": "the product-facing label of the model that rendered it"
-    },
-    "raw": {
-      "description": "the raw job result payload (e.g. images[] for carousel template ads)"
-    },
-    "stillRendering": {
-      "description": "true when the render is still in progress — keep polling get_job with jobId",
-      "type": "boolean"
-    },
-    "url": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "description": "the served URL of the finished media (absent/null while still rendering)"
-    }
-  },
-  "type": "object"
-}New value: +null
  2. Addedv0.1.15

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only mark the tool as non-read-only, non-idempotent, etc., but the description supplies the important behaviors: it never modifies the original, costs ~2 credits flat, runs no AI model, executes up to 6 ops in a deterministic order, and append_card 'ADDS its seconds, never re-renders.' No contradiction with the annotations.

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 description is dense and every clause carries information, with the core distinction front-loaded. The heavy use of all-caps and a single long paragraph make it less scannable than a bulleted structure, but it contains very little waste.

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?

For a tool with no output schema, the description still explains enough to invoke it successfully: video input, ordered op plan, limits, brand defaults/overrides, cost, non-destructiveness, and exclusions. Edge cases like custom end-card HTML and user color precedence are covered, so an agent has the full call contract.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds the operation-level semantics an agent needs to compose a plan: op ranges, 'applied in order', the max plan size, the append-card special behavior, and automatic brand loading with per-call overrides. It goes well beyond the raw property names and enum values.

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?

The description names an exact action ('mechanical post-production on an EXISTING rendered video'), identifies the input (served mp4 URL), and enumerates the concrete primitive operations. It explicitly distinguishes itself from AI-generation tools by saying 'NO AI model' and from re-rendering by saying 'original untouched (returns a NEW video)'.

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

Usage Guidelines5/5

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

It gives a direct 'lane for' list (end card, trim, speed, mute, audio_gain, fade_out, watermark, grain) and an explicit negative routing instruction: 'NEVER use generate_video/render_ad for these mechanical asks.' This tells an agent exactly when to select post_edit over the main alternatives.

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