Skip to main content
Glama

video_resize

Resize videos or change aspect ratios to fit target dimensions and presets such as 16:9 or 9:16, returning a JSON result with the output path.

Instructions

Resize a video or change its aspect ratio. Returns JSON {success, output_path}. Use to fit a video to target dimensions or a preset ratio. Pass input_path as the source video (e.g. from video_info) and either width/height or aspect_ratio to define the target.

Args: input_path: Absolute path to the input video. width: Target width in pixels. Use with height. height: Target height in pixels. Use with width. aspect_ratio: Preset aspect ratio (16:9, 9:16, 1:1, 4:3, 4:5, 21:9). Overrides width/height. quality: Quality preset (low, medium, high, ultra). output_path: Where to save the output. Auto-generated if omitted.

Input Schema

NameRequiredDescriptionDefault
widthNo
heightNo
qualityNohigh
overwriteNoExplicitly allow replacing existing media. Existing non-media files are protected.
input_pathYes
output_pathNo
aspect_ratioNo

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. First observedv0.2.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It does disclose two real behavioral facts: aspect_ratio overrides width/height, and output_path is auto-generated when omitted. It does not cover re-encoding/lossiness, overwrite behavior (which the schema documents but the description omits), or what error occurs if neither width/height nor aspect_ratio is given.

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?

Front-loaded summary followed by a compact per-argument list; no filler sentences. Mild redundancy between 'Resize a video or change its aspect ratio' and the following 'Use to fit a video to target dimensions or a preset ratio' keeps it from a 5.

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

Completeness3/5

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

An output schema exists, so the brief return-value note is sufficient. But the combination rule between width/height and aspect_ratio is only half-stated ('Use with height'), and the overwrite safety flag present in the schema is never referenced in the description, leaving gaps for a 7-parameter mutation tool with no annotations.

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

Parameters4/5

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

Schema coverage is only 14%, but the description compensates well: it enumerates the accepted aspect_ratio values (16:9, 9:16, 1:1, 4:3, 4:5, 21:9) and quality presets (low, medium, high, ultra), neither of which appears as an enum in the schema. Only the overwrite parameter is left to the schema's own description.

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?

States a specific verb and resource ('Resize a video or change its aspect ratio') and names the two modes of operation (target dimensions or preset ratio). It does not, however, distinguish itself from adjacent siblings like video_crop, video_rotate, or video_convert, so an agent must infer the boundary itself.

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?

Offers implied usage ('Use to fit a video to target dimensions or a preset ratio') and one useful upstream hint ('input_path ... e.g. from video_info'), but never says when to prefer crop or convert instead, nor what happens when no dimension argument is supplied. Usage is inferable but not spelled out.

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