Musicboxmelodies

Save a new music box song

create_song

Saves a melody as a new private song. The melody must have no errors (run validate_melody or fit_melody_to_box first); warnings such as notes repeated too quickly are saved and marked, as in the composer. If the person is signed in, the song goes to their account and you get a link to open it in the composer. Without an account the song is saved anonymously and you get a claim link: give it to the person so they can keep it (valid 30 days). Set save_to_my_account to true to ask the person to sign in first (apps that cannot sign in mid-conversation should save without an account and give the claim link instead). Limits: 5 songs a day without an account, 15 a day with one.

Input Schema

Name	Required	Description
`box`	Yes	Music box type: "15", "20", "30" (notes) or "freestyle" (digital only). See list_music_boxes.
`bpm`	Yes	Tempo in beats per minute (30-300).
`name`	Yes	Song title.
`tags`	No
`notes`	Yes	Notes in any order, at most 2000. Only onsets matter: music boxes have no note durations.
`artist`	Yes	Original artist or composer ("Traditional" if unknown).
`description`	No	Optional notes about the arrangement.
`save_to_my_account`	No	True to save it in the person's account; they will be asked to sign in if they are not.
`illegal_threshold_ticks`	No	Minimum gap between two identical notes, in ticks (default 384 = 2 beats).

Output Schema

Name	Required	Description	Default
`box`	Yes
`quota`	Yes
`private`	Yes
`song_id`	Yes
`claim_url`	No
`validation`	Yes
`claim_token`	No
`composer_url`	No
`claim_expires_at`	No
`saved_to_account`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 29, 2026
- addedOutput schema / properties / quota / properties / limit / description
```
Added value: +"null means no daily limit"
```
- changedOutput schema / properties / quota / properties / limit / type
```
Previous value: -"number"New value: +[
+  "number",
+  "null"
+]
```
First observedSep 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare the mutation/safety profile (readOnly=false, destructive=false, idempotent=false). The description adds substantial context beyond that: errors refuse the save, warnings are persisted and marked, signed-in saves land in an account with a composer link, anonymous saves return a 30-day claim link, and rate limits are 5/day anonymously vs 15/day signed in.

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?

Well front-loaded: purpose, then precondition, then outcome branching, then limits. Every sentence carries information, though the clause 'as in the composer' and the restated save_to_my_account behavior are mild redundancy in an otherwise dense block.

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, yet the description still usefully characterizes the two return shapes (composer link vs claim link) that drive agent behavior. Preconditions, account branching, and rate limits together cover everything needed to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 89%, so parameters are largely self-documenting; baseline is 3. The description elaborates the consequence of save_to_my_account rather than its syntax, and says nothing about illegal_threshold_ticks or tags, so it adds little at the parameter level beyond 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 ('Saves a melody as a new private song') and immediately differentiates from siblings like add_version and delete_song by noting this creates a NEW private song. The privacy default and account-vs-anonymous outcome are clear 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 Guidelines5/5

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

Explicitly names prerequisites ('run validate_melody or fit_melody_to_box first'), specifies exactly when to set save_to_my_account=true, and gives a concrete alternative path for apps that cannot sign in mid-conversation. Error-vs-warning handling (errors block, warnings save) is stated as a routing rule.

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

All Musicboxmelodies tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?