Skip to main content
Glama

add_melody

Adds a melody with matching lyrics in one call, using pitch:beats notation and one lyric per sounding note; held syllables use '+'. Handles note and lyric entry together in OpenUtau MCP.

Instructions

Add a melody with its lyrics in one call. melody: space-separated PITCH:BEATS (r = rest). lyrics are split like set_lyrics and must give one lyric per sounding note (use "+" for held syllables). / メロディと歌詞を一度に追加します。melody は「音名:拍」(r = 休符)。歌詞は set_lyrics と同じ規則で分割され、 音の数と一致する必要があります(伸ばす音節は「+」)。

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": {
      "part": "<part>",
      "melody": "<melody>"
    },
    "name": "add_melody"
  }
}

Input Schema

NameRequiredDescriptionDefault
partYes
lyricsNo
melodyYes
languageNoauto
start_tickNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden; it does disclose meaningful behavioral detail in the melody grammar (PITCH:BEATS, r = rest) and the lyric-splitting rule. It says nothing about permissions, whether existing notes are overwritten, where the melody is placed relative to start_tick, or what is returned, so a mutation tool remains partially opaque.

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?

Front-loaded with the core action, then the format rules. The bilingual duplication is justified for a Japanese/English tool and each sentence carries format information rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter mutation tool with no annotations and no output schema, the definition covers the tricky input formats well but omits part/start_tick/language semantics and any guidance on choosing this over the near-identical sibling. Adequate but with clear gaps.

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 coverage is 0%, so the description must compensate. It gives rich format semantics for 'melody' and 'lyrics', but leaves 'part' (required), 'language' (default 'auto'), and 'start_tick' (default 0) entirely unexplained, so three of five parameters remain opaque.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb + resource ('Add a melody with its lyrics in one call') and the phrase 'in one call' signals it is the combined alternative to adding a melody and then calling set_lyrics. It does not, however, distinguish itself from the confusingly similar ustx_add_melody sibling.

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

Usage Guidelines3/5

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

Provides concrete usage rules for the lyrics portion (one lyric per sounding note, '+' for held syllables, split like set_lyrics), which tells the agent how to prepare input. It never states when to call this versus set_lyrics, add_notes, or ustx_add_melody, so selection guidance is only implied.

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