Skip to main content
Glama

concat

Join two or more media files into one output, re-encoding inputs so files with different codecs or sizes can be combined.

Instructions

Join 2+ media files into one. Re-encodes, so inputs may differ in codec or size.

Input Schema

NameRequiredDescriptionDefault
inputsYesFiles in order
outputYesPath to the file (relative or absolute)
audio_codecNoaac
video_codecNolibx264

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.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 that the operation re-encodes, which implies quality/speed cost and codec normalization — real behavioral value. Missing are whether the output path is overwritten or must be new, what happens on mismatched resolution/framerate, and whether the call is destructive to inputs.

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?

Two tight sentences with the core action front-loaded and the re-encode caveat immediately after. Nothing is wasted, though it is arguably too short for a 4-parameter mutation tool.

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?

Given a small flat schema with a clear required/optional split and no output schema, the definition covers the essentials an agent needs to invoke it. The main omission is output-file behavior (overwrite vs. create) for a tool whose entire job is writing a file.

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 coverage is 50%: inputs and output are documented in the schema, while audio_codec and video_codec have only defaults and no descriptions. The description's mention of re-encoding hints that codec params matter, but it does not explain them or their defaults, so it does not compensate for the gap.

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?

Names a specific verb and resource ('Join 2+ media files into one') and adds a constraint that matches the schema's minItems=2. It is clearly distinct from siblings like convert or trim, though it never names an alternative explicitly.

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?

The clause 'inputs may differ in codec or size' implicitly tells the agent this is safe for heterogeneous inputs, which is a useful usage signal. However, there is no explicit when-to-use/when-not guidance versus convert or other siblings, and nothing about ordering expectations beyond the schema's 'Files in order'.

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