@jam-jam/convert-mcp

Get a Mastering render status

jj_mastering_get_job

Fetches a mastering render by ID to check status, progress, queue position, settings, loudness report, and result hash; optionally downloads the finished WAV to a local file.

Instructions

Fetches one of your renders by id (GET /mastering/jobs/{id}): status (queued, decoding, analyzing, rendering, done, failed, cancelled, expired), progress, queue position, a copy of the settings used and, once done, the loudness measures before and after (report) and the sha256 of the result. With download=true on a finished render, the mastered WAV (GET /mastering/jobs/{id}/result, free to repeat) is downloaded to a local file and its path returned. A render unknown or belonging to another account answers the same 404; results are kept 24 hours (410 afterwards). Costs no quota (read rate limit): poll no faster than every few seconds.

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": {
      "id": "<id>"
    },
    "name": "jj_mastering_get_job"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Job id returned by jj_master_audio (a UUID).
`download`	No	true: when the render is done, download the WAV and return its local path. Default false: status only.

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 fully carries the behavioral burden: it discloses the local-file download side effect, repeatable downloads, indistinguishable 404 responses for unknown or foreign jobs, 24-hour retention followed by 410, and quota and rate-limit behavior. It also lists terminal and nonterminal states, making polling outcomes predictable.

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?

Three dense but efficient sentences move from the core fetch operation to optional downloading and then errors, retention, and polling constraints. The state list and returned-field inventory earn their place because there is no output schema, and there is no promotional or redundant wording.

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 two-parameter status tool with no annotations or output schema, the definition supplies the information needed to invoke and interpret it correctly. It covers outputs, optional file retrieval, important failure modes, retention, cost, and a safe polling cadence.

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%, but the description adds operational meaning beyond the basic ID and download definitions. In particular, it explains error behavior for invalid, foreign, and expired IDs and clarifies that downloading applies to finished renders and can be repeated without charge.

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 uses a specific verb and resource—fetching one mastering render by ID—and enumerates the status, progress, settings, report, and result hash it provides. The mastering endpoint and render terminology distinguish it from the sibling job-status tools for other resource types.

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 concrete usage conditions: use download=true on a finished render to obtain the WAV, and poll no faster than every few seconds. It does not explicitly explain when to choose this tool over sibling get_job tools or name an alternative for other job types.

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