Magic Master MCP

Overview Schema Source Related Servers Discussions Admin

Master an album or a batch

batch_master

Master up to 10 audio tracks in one call with shared settings, preserving relative loudness in album mode. Get per-track job IDs, dry-run pricing, and apply consistent mastering across your album.

Instructions

Master up to 10 tracks in one call with the same settings. Needs N TOKENS 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) — the account may allow bigger uploads on the site, but not through this channel. 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 the price 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 the price and 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 remove the Suno/Udio AI fingerprint. 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.3.1Sep 8, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The description substantially exceeds the sparse annotations by explaining costing per track, memory-based upload limits, relative-leveling behavior, processing time, per-track job IDs, and exact dry_run semantics before anything is spent. This is exactly the kind of behavioral context an agent needs beyond readOnly/destructive hints.

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?

Every sentence in the description earns its place: purpose, pricing, behavior, limits, latency guidance, return format, and dry-run safety. It is dense but not bloated, and the critical operational constraints appear early.

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 8 parameters and an output schema, the description covers all consequential aspects: cost model, constraints, album-mode behavior, timing, polling workflow, and a safe preview path. An agent can correctly select and invoke this tool with confidence.

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 already high at 88%, so the baseline is met. The description adds meaningful semantics beyond the schema: album_mode means the loudest track hits the target while others keep offsets, N tracks cost N tokens/runs, and there are per-file/per-call size caps not encoded in the schema. This elevates the value beyond the field descriptions alone.

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: 'Master up to 10 tracks in one call with the same settings.' This clearly distinguishes the tool from the sibling master_track as a batch operation while stating its scope precisely.

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?

It gives clear operational guidance: token/free-run costs per track, server caps, album-mode semantics, timing expectations, dry_run usage, and a recommendation to send fewer, longer tracks per call. It does not explicitly name master_track as the alternative for single-track jobs, but the batch context and sibling list make the usage clear.

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

Deploy Server