@jam-jam/convert-mcp

Create a Mastering preset

jj_create_mastering_preset

Saves a named mastering preset with all module settings, loudness target, and normalization to an account for reuse. Enforces unique names and preset limits.

Instructions

Saves a named Mastering preset on the account (POST /mastering/presets): a name of 1 to 60 characters, unique among the account presets, and the settings (all eight modules with value and enabled, a loudness target, normalize). Each value must be within its range and on its step: read them with jj_mastering_capabilities, or copy the settings of a built-in preset and change a few values. The API answers 422 with the path of every rejected field when the settings are invalid, 409 when the name is taken or the 50-preset cap is reached. Open to any account, free or Premium. Counts one unit of the daily write quota. Only call it when the user asked to save a preset.

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": {
      "name": "<name>",
      "settings": "<settings>"
    },
    "name": "jj_create_mastering_preset"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes	Preset name, 1 to 60 characters, unique on the account.
`settings`	Yes	The preset settings (format version 1).

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.2Nov 13, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations supplied the description carries the full burden and does so: it discloses validation behavior (422 returning the path of every rejected field), conflict/limit behavior (409 on duplicate name or the 50-preset cap), quota cost (one daily write unit), and account eligibility. This is exactly the kind of failure-mode and cost context an agent cannot get from the schema.

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?

Purpose is front-loaded in the first clause, followed by constraints, error behavior, cost, and the call gate in a logical order with no filler. It reads as a dense run-on paragraph, but essentially every sentence carries distinct information.

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 nested-object creation tool with no output schema, the description covers inputs, validation source, failure modes, and quota. The one real gap is the return payload: it never says what a successful save returns (e.g., a preset id or the stored settings), which the agent would need for follow-up calls.

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 100%, so the baseline is 3; the description goes further by stating that all eight modules are required and that each value must fall within its range and on its step, pointing to jj_mastering_capabilities as the source of those constraints. It does not, however, explain the semantics of individual modules or the target/normalize interplay beyond what the schema already says.

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 ("Saves a named Mastering preset on the account") and anchors it with the endpoint POST /mastering/presets, which cleanly separates it from jj_list_mastering_presets and jj_mastering_capabilities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly gates use ("Only call it when the user asked to save a preset") and routes the agent to the prerequisite tool for valid ranges (jj_mastering_capabilities) plus a viable alternative workflow (copy a built-in preset and tweak it). Eligibility is stated too, so the agent knows the call works on free and Premium accounts alike.

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