Skip to main content
Glama

share_preset

Idempotent

Share something the user made on a device with every SynthHub user, under CC BY-SA 4.0: a sound, a sequence or pattern, a kit, a project, a bank of their own sounds, or a MIDI clip any device can play. Its content: the device's own data (SysEx, e.g. from backup_presets), settings by driver address (from list_routes, e.g. {'/filter/cutoff': [90]}, which also works for devices without dumps), and/or a standard MIDI file. Only what the user made: never factory presets, nor sounds or sequences bought or downloaded from others — set own_sound only after asking the user. Made from someone else's shared preset? Pass derived_from: it credits them, as the licence requires. Describe it well (category, genres, tags, tempo, key, tips): that is how people find it. The same content shared twice returns the existing id; the author publishes new versions with update_preset and can withdraw it (withdraw_preset). Through a relay, the device data can be captured from the device itself: pass code and start the dump from the device's menu during the call, or give request_hex (the device's dump-request message, which the user accepts at the relay). An audio preview is added by its author with PUT /u//v1/presets//audio (MP3, Ogg, M4A or WebM, 1 MB at most).

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": {
      "device": "<device>",
      "name": "<name>",
      "own_sound": "<own_sound>"
    },
    "name": "share_preset"
  }
}

Input Schema

NameRequiredDescriptionDefault
hexNoThe device data as SysEx, in hex (64 KB at most).
keyNoMusical key, e.g. 'A minor'.
codeNoA relay's pairing code: capture the device data from the device instead of hex.
kindNoWhat it is (default sound).
nameYesIts name (80 characters at most).
portNoWith code: the device's port name (or part of it), when the relay has several.
tagsNoCharacter and free words: 'warm', 'dark', 'evolving'… (8 at most).
tipsNoHow to play it: mod wheel, aftertouch, register… (500 characters at most).
tempoNoBPM, for sequences and clips.
deviceYesDriver id (e.g. 'korg/minilogue') or slug.
genresNoMusical styles: 'techno', 'ambient'… (8 at most).
secondsNoWith code: how long to wait for the dump (default 5).
user_idNoYour anonymous SynthHub id, if you kept it from an earlier session (see the server instructions). Optional.
categoryNoThe kind of sound or part.
firmwareNoFirmware version of the device it was made on.
settingsNoSettings by driver address: {'/filter/cutoff': [90], '/amp/attack': [12]} (512 at most).
librarianNoThe synth the librarian took it from (take_sound's librarian): loading it then goes through the same exchange, fitted to the receiving synth.
own_soundYesMust be true: the user made it (not a factory preset, not someone else's).
descriptionNoWhat it sounds like (500 characters at most).
midi_base64NoA standard MIDI file, base64 (64 KB at most).
request_hexNoWith code: the device's dump-request SysEx, sent first (e.g. 'F0 42 30 00 01 2C 10 F7').
derived_fromNoId of the shared preset it was made from.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / librarian
      Added value: +{
      +  "description": "The synth the librarian took it from (take_sound's librarian): loading it then goes through the same exchange, fitted to the receiving synth.",
      +  "type": "string"
      +}
  2. Changed15 schema fields changed
    • addedInput schema / properties / category
      Added value: +{
      +  "description": "The kind of sound or part.",
      +  "enum": [
      +    "bass",
      +    "lead",
      +    "pad",
      +    "pluck",
      +    "keys",
      +    "organ",
      +    "brass",
      +    "strings",
      +    "bell",
      +    "arp",
      +    "sequence",
      +    "drums",
      +    "percussion",
      +    "fx",
      +    "texture",
      +    "vocal",
      +    "other"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / code / description
      Previous value: -"A relay's pairing code: capture the patch from the device instead of hex."New value: +"A relay's pairing code: capture the device data from the device instead of hex."
    • addedInput schema / properties / derived_from
      Added value: +{
      +  "description": "Id of the shared preset it was made from.",
      +  "type": "string"
      +}
    • changedInput schema / properties / description / description
      Previous value: -"What it sounds like, how to play it (500 characters at most)."New value: +"What it sounds like (500 characters at most)."
    • changedInput schema / properties / firmware / description
      Previous value: -"Firmware version of the device the sound was made on."New value: +"Firmware version of the device it was made on."
    • addedInput schema / properties / genres
      Added value: +{
      +  "description": "Musical styles: 'techno', 'ambient'… (8 at most).",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / hex / description
      Previous value: -"The patch as SysEx, in hex (one program, 32 KB at most)."New value: +"The device data as SysEx, in hex (64 KB at most)."
    • addedInput schema / properties / key
      Added value: +{
      +  "description": "Musical key, e.g. 'A minor'.",
      +  "type": "string"
      +}
    • addedInput schema / properties / kind
      Added value: +{
      +  "description": "What it is (default sound).",
      +  "enum": [
      +    "sound",
      +    "sequence",
      +    "kit",
      +    "project",
      +    "bank",
      +    "clip"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / midi_base64
      Added value: +{
      +  "description": "A standard MIDI file, base64 (64 KB at most).",
      +  "type": "string"
      +}
    • changedInput schema / properties / name / description
      Previous value: -"The sound's name (80 characters at most)."New value: +"Its name (80 characters at most)."
    • changedInput schema / properties / own_sound / description
      Previous value: -"Must be true: the user made this sound (not a factory preset, not someone else's)."New value: +"Must be true: the user made it (not a factory preset, not someone else's)."
    • changedInput schema / properties / tags / description
      Previous value: -"A few words: 'bass', 'pad', 'warm'… (8 at most)."New value: +"Character and free words: 'warm', 'dark', 'evolving'… (8 at most)."
    • addedInput schema / properties / tempo
      Added value: +{
      +  "description": "BPM, for sequences and clips.",
      +  "type": "number"
      +}
    • addedInput schema / properties / tips
      Added value: +{
      +  "description": "How to play it: mod wheel, aftertouch, register… (500 characters at most).",
      +  "type": "string"
      +}
  3. Added

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, it discloses idempotency semantics (same content twice returns the existing id), the CC BY-SA credit obligation via derived_from, the relay capture procedure (pass code, start dump from device menu during the call, or supply request_hex), and the separate PUT endpoint for audio previews. This is substantive behavioral context the structured fields do not carry.

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-loads the core purpose and licence before branching into relay capture and audio options, and every sentence carries information. It is dense and long, and the trailing audio-preview endpoint borders on tangential, but it is largely justified by the 22-parameter scope.

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?

For a complex, 22-parameter, nested-object tool with no output schema, it covers the required-vs-optional intent, the relay path, crediting, and the duplicate-returns-id behavior. It is slightly thin on what the response contains beyond the id, but overall adequate for a correct invocation.

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 100%, so the schema already documents all 22 parameters; the baseline would be 3. The description adds working examples and cross-parameter relationships beyond the schema – the settings address/value format ({'/filter/cutoff': [90]}), the code+port+seconds/request_hex relay flow, and the derived_from crediting semantics – that meaningfully help invocation.

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 (share), the resource (user-made device content), the audience (every SynthHub user), the licence (CC BY-SA 4.0), and enumerates the content kinds (sound, sequence, kit, project, bank, clip). It also distinguishes itself from siblings update_preset and withdraw_preset in the same breath.

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 says what to include vs exclude (never factory presets or third-party downloads, set own_sound only after asking the user), routes the agent to backup_presets for SysEx, list_routes for settings, and take_sound's librarian for librarian-sourced sounds. Alternatives for versioning (update_preset) and removal (withdraw_preset) are named.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.