Skip to main content
Glama
Sign In
SoundMCP

SoundMCP

by Plagnito
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

create_music

Compose original game music tracks in 19 styles from a seed, rendering WAV or MIDI with seamless loops for menus, levels, and ambient background.

Instructions

Compose et rend une piste musicale de jeu (WAV stéréo, MIDI GM, ou les deux). 19 styles : ambient, lofi, chiptune, epic, mystery, fantasy, upbeat, sad, dungeon, menu, suspense, victory, village, combat, rock, jazz, horror, hiphop, space. Déterministe : même seed = même musique. loop: true produit une boucle sans raccord audible, parfaite en fond de jeu.

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": {
      "style": "<style>"
    },
    "name": "create_music"
  }
}

Input Schema

NameRequiredDescriptionDefault
keyNoTonalité, ex. "A minor", "F# dorien", "la mineur", "C majeur". Optionnel : choisie selon le style sinon.
loopNoBoucle sans raccord (pour fond de jeu continu). Par défaut : true pour la plupart des styles.
monoNoExporte en mono (taille moitié). À réserver aux fonds ambisoniques ou aux contraintes de taille.
seedNoGraine aléatoire. Même seed + mêmes paramètres = musique identique. Change le seed pour une variation.
styleYesStyle musical. Utilise list_styles pour voir le détail de chacun.
tempoNoTempo en BPM (40-220). Optionnel : chaque style a un tempo naturel.
titleNoTitre de la piste (sert aussi de nom de fichier).
formatNoFormat de sortie : wav (audio prêt), midi (éditable dans un DAW), both.wav
output_dirNoDossier de sortie. Par défaut : <projet>/output.
sampling_rateNoFréquence d'échantillonnage du WAV en Hz. 44100 par défaut (qualité CD) ; 22050 divise la taille par deux, suffisant pour les fonds de jeu.
duration_secondsNoDurée cible en secondes (5 à 600). Arrondie à un nombre entier de mesures.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It usefully discloses determinism ('même seed = même musique'), seamless looping, and the three output formats, but it never mentions that the call writes files to disk via output_dir, how long a render takes, or what is returned.

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?

Three tight sentences, front-loaded with what is produced and the key behavioral guarantee (determinism), then looping. The enumeration of 19 styles duplicates the enum already in the schema and is the only notably redundant element.

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 an 11-parameter generation tool with no annotations and no output schema, the description covers the conceptual essentials but omits the practically important bits: that files are written to output_dir and what paths/identifiers come back. An agent can call it, but cannot predict the result it can act on.

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 100% and every parameter including style, seed, loop, tempo and format is already documented in the schema. The description adds only the determinism rule for seed and the seamless-loop meaning of loop, both essentially restatements, so baseline 3 applies.

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?

The description states a specific verb and resource: composing and rendering a game music track, with formats called out (WAV stéréo, MIDI GM). It is clearly a music-track generator rather than an ambience or SFX generator, but it never names those siblings, so differentiation is inferred from the noun rather than stated.

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?

Usage is implied rather than prescribed: 'loop: true ... parfaite en fond de jeu' tells the agent one good scenario, and the style list hints at selection. There is no explicit 'use this when X, use create_sfx/create_ambience instead when Y', so the agent must infer routing.

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

Deploy Server

Other Tools