Echoteka MCP

Official

Overview Schema Source Related Servers Discussions Admin

Master an album or a batch

batch_master

Master up to 10 tracks in one call with shared settings, preserving album-relative loudness or processing singles separately. Returns one job ID per track to poll.

Instructions

Master up to 10 tracks in one call with the same settings. Needs N CREDITS for N tracks, or N free runs - not one. album_mode (default true) levels the tracks RELATIVE to each other: the loudest hits the target exactly, the others keep their offsets, so a quiet interlude is not inflated to single level. Limits: 10 tracks, 100 MB per file and 300 MB per call (this server's own caps, for memory). A big album takes minutes - send fewer, longer tracks per call rather than all at once. Returns one job id per track - poll each with get_job. Pass dry_run=true to see what would be used and the settings before anything is spent.

Input Schema

TableJSON Schema

Name	Required	Description
`style`	No	Preset key from list_presets.
`bitrate`	No	MP3: 128/192/256/320; OPUS: 128/192.
`dry_run`	No	Report what would be used and the settings without mastering and without downloading anything.
`album_mode`	No	Keep relative loudness between tracks. Default true. Set false for unrelated singles.
`audio_urls`	Yes	Public https URLs, in album order.
`out_format`	No
`target_lufs`	No	Target for the LOUDEST track in album mode.
`remove_watermark`	No	Also run AI artifact cleanup first. Free.

Output Schema

TableJSON Schema

Name	Required	Description
`jobs`	No
`tracks`	No	job_id, filename, source_url, target_lufs and album_lufs_offset as APPLIED by the server
`dry_run`	No
`job_ids`	No
`poll_with`	No
`would_charge`	No
`enough_capacity`	No
`nothing_was_charged`	No
`album_mode_requested`	No
`album_offsets_applied`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnly=false, destructive=false, openWorld=true. The description adds cost modeling (N credits for N tracks, not one, or N free runs), resource caps (10 tracks, 100 MB/file, 300 MB/call) attributed to server memory, runtime expectations ('takes minutes'), return shape (one job id per track), and the dry_run escape hatch. This is rich behavioral context well beyond 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?

Front-loaded with purpose, then cost, then the highest-value semantic (album_mode), then limits and workflow. Every sentence carries information, though the batching advice and repeated target_lufs phrasing make it slightly longer than necessary.

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?

An output schema exists and annotations carry the safety profile, yet the description still supplies the polling workflow (get_job per job id), cost, caps, and timing needed to call this batch mutation correctly. Nothing an agent needs is missing.

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 88%, so baseline is 3, but the description adds real meaning: album_mode is explained with the relative-leveling behavior ('the loudest hits the target exactly, the others keep their offsets, so a quiet interlude is not inflated'), and credits are tied to audio_urls count. Other params (style, bitrate, out_format) are left entirely to the schema.

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?

States a specific verb and resource with scope: 'Master up to 10 tracks in one call with the same settings.' An agent can distinguish it from the sibling master_track (single) purely from the description.

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?

Gives clear context for use: batching up to 10 tracks sharing settings, album vs unrelated singles via album_mode, and routes polling to get_job and previewing to dry_run. It never explicitly names master_track as the single-track alternative, so routing between the two is inferred rather than stated.

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

Deploy Server