MakersMCP

Overview Schema Source Related Servers Discussions Admin

Read a music track

analyze_music

Analyzes a music track's tempo, beats, bars, drop and ending, saving them to FIT.md and cues.json so you can pick the right hit before fitting music.

Instructions

Reads a music track without changing it: its tempo, beats, bars, drop and ending, written to FIT.md and cues.json. Use it before fit_music to pick the hit. (musicfit 0.1.2, on this machine.)

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": {
      "track": "<track>"
    },
    "name": "analyze_music"
  }
}

Input Schema

Name	Required	Description
`bpm`	No	The tempo, when the one found is half or double the real one.
`meter`	No	Beats to a bar (default: found).
`track`	Yes	The music file, or a video whose sound to read.
`out_dir`	No	Folder to save into, absolute or relative to /app. Default: musicfit-{stem:track}.
`wait_seconds`	No	How long to wait for the result before returning a job_id to wait on. 45 is safe for clients that stop a tool call after 60 seconds.

Output Schema

Name	Required	Description
`kit`	Yes
`tool`	Yes
`files`	No
`folder`	No	Where the kit saved its files.
`job_id`	Yes
`passed`	No	For checks: whether the check passed.
`status`	Yes
`exit_code`	No
`last_line`	No	What the kit was doing last.
`expires_at`	No	When the download links stop working.
`next_action`	No
`elapsed_seconds`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.3/5.0

Behavior4/5

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

The description usefully reconciles the apparent read/write tension in the annotations: it "reads" the track without altering it, yet writes FIT.md and cues.json to disk, which is why readOnlyHint is false. It also signals local execution ("on this machine"), consistent with openWorldHint=false. It does not mention that long jobs can return a job_id for later polling, though the schema's wait_seconds parameter covers that mechanism.

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?

Two compact sentences with the capability front-loaded and the sibling relationship second. The trailing parenthetical ("musicfit 0.1.2, on this machine") carries mild context about local execution and version, but is close to filler for tool selection.

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?

With a full output schema, complete parameter descriptions, and annotations present, the description only needs to convey purpose, artifacts, and sequencing — all of which it does. The one gap is not flagging that the call may return early with a job_id on longer tracks, which matters for an agent deciding how to follow up.

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 description coverage is 100%, so every parameter is already documented, including the bpm half/double override, meter, out_dir default, and the 45-second wait heuristic. The description adds little per-parameter meaning but does clarify that the outputs land in FIT.md and cues.json, reinforcing what out_dir controls. Baseline-plus rather than a genuine semantic addition.

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 ("Reads a music track") and enumerates exactly what it extracts: tempo, beats, bars, drop and ending, plus the artifacts written (FIT.md, cues.json). It also names the sibling it precedes (fit_music), so an agent can separate it from fit_music or the video/kit tools without opening the schema.

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?

"Use it before fit_music to pick the hit" gives an explicit ordering constraint against a named sibling, which is real when-to-use guidance. It stops short of stating when not to use it (e.g. when a FIT.md already exists) and "pick the hit" is domain jargon, but the sequencing is unambiguous.

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

Deploy Server