Skip to main content
Glama
Sign In
Tapra MCP server

Tapra MCP server

Official
by tapra-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Edit audio

edit_audio

Prepare audio for videos and posts by joining, trimming, removing silence, normalizing loudness, fading, and converting formats locally with ffmpeg; writes a new file and keeps originals unchanged.

Instructions

Prepare audio for videos and posts, locally with ffmpeg: join several files in order, trim, remove long silences, normalize loudness (-14 LUFS for social video, -16 podcasts, -23 broadcast), fade in/out, and convert to any of the 19 formats. Video inputs contribute their sound. Writes a new file; never changes the originals. Free.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "input_paths": "<input_paths>"
    },
    "name": "edit_audio"
  }
}

Input Schema

NameRequiredDescriptionDefault
formatNoAudio format: wav (default, lossless), mp3_<rate>_<kbps>, pcm_<rate> (16-bit WAV), ulaw_8000 / alaw_8000 (telephony), opus_48000_<kbps> (Ogg Opus). mp3, opus, ulaw and alaw need ffmpeg.wav
channelsNoauto = mono only if every input is mono.auto
trim_endNoKeep audio up to this second (of the joined audio).
trim_startNoKeep audio from this second (of the joined audio).
input_pathsYesAudio or video files, joined in this order.
output_pathNoWhere to save. Relative paths go in the output folder.
loudness_lufsNoTarget loudness. -14 social, -16 podcast, -23 broadcast.
remove_silenceNoShorten silences longer than min_silence_seconds.
fade_in_secondsNo
fade_out_secondsNo
min_silence_secondsNo
silence_threshold_dbNoQuieter than this counts as silence.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the annotations, the description discloses that processing is local via ffmpeg, that it writes a new file, that originals are never changed, that video inputs contribute their sound, and that it is free. These are meaningful behavioral traits for a mutating tool with destructiveHint=false, though it does not discuss overwrite behavior or failure modes.

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?

The purpose is front-loaded and the operation list is dense but readable, with no filler. Short follow-up sentences add the important non-destructive and local-processing facts without bloating the definition.

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?

For a 12-parameter tool with no output schema, the description covers the main capabilities, processing locality, non-destructive behavior, and video-input handling. The schema supplies most parameter details, though the description could say more about output return values or overwrite behavior for full completeness.

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 75%, already documenting most parameters including format, trim, silence, and loudness behavior. The description reinforces the operation categories and mentions the 19 formats and loudness presets, but it largely repeats what the schema already provides rather than adding new parameter-level semantics.

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 opens with a specific verb and resource: 'Prepare audio... locally with ffmpeg.' It then enumerates the concrete operations — join, trim, silence removal, loudness normalization, fades, and format conversion — so the tool's purpose is unmistakable and clearly distinct from the speech/transcription/translation siblings.

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?

The description gives clear usage context: preparing audio for videos and posts, with specific loudness presets for social video, podcasts, and broadcast. It does not explicitly name when not to use it or compare it to an alternative, but no sibling tool overlaps with audio editing, so the guidance is sufficient without formal exclusions.

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