osc-bridge

load_preset

DestructiveIdempotent

Load a shared preset (find_presets, get_preset) into the user's device through a relay: its settings are sent through the driver, its patch data as SysEx — which replaces the sound the device holds, so the relay asks the user to accept it and this call waits for the answer (up to 2 minutes): tell the user first. Afterwards, tell SynthHub how it went with report_preset.

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": {
      "code": "<code>",
      "id": "<id>"
    },
    "name": "load_preset"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Preset id (e.g. 'p3fa9c1d2e4b7').
`code`	Yes	The pairing code the relay page or program shows.
`port`	No	Output port name (or part of it); needed when the relay has several.
`device`	No	The device it goes into, when not the preset's own: one of get_preset's loads_on (an M-VAVE FM-1 takes DX7 voices); the sound is sent unchanged.
`gap_ms`	No	Pause between the SysEx messages, for devices that write slowly (default 50).
`user_id`	No	Your anonymous SynthHub id, if you kept it from an earlier session (see the server instructions). Optional.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 24, 2026

addedInput schema / properties / device

Added value: +{
+  "description": "The device it goes into, when not the preset's own: one of get_preset's loads_on (an M-VAVE FM-1 takes DX7 voices); the sound is sent unchanged.",
+  "type": "string"
+}

AddedOct 23, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses that the transfer replaces the sound currently on the device, that the relay prompts the user and the call blocks waiting for the answer for up to 2 minutes, and that the agent should not invoke it without warning the user. That is precisely the kind of consequence detail destructiveHint alone cannot convey.

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?

A single dense sentence that front-loads purpose, then the consent and follow-up obligations. It reads a bit run-on due to nested dashes and parentheticals, but every clause carries operational information and nothing is wasted.

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 destructive, blocking, open-world transfer with no output schema, the critical facts (replacement, relay prompt, 2-minute wait, follow-up reporting) are all present. What is missing is what the call returns or what happens if the user declines or the relay fails.

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%, so all six parameters (id, code, port, device, gap_ms, user_id) are already documented with examples and constraints. The description adds no parameter-level detail such as which device is the target or how the pairing code relates to the relay, so the baseline 3 applies.

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 — loading a shared preset into the user's device via a relay — and explicitly names the sibling tools involved (find_presets, get_preset), plus the follow-up (report_preset). The mechanism (settings through the driver, patch data as SysEx) makes it unmistakable versus relay_send or take_sound.

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?

Clear sequencing guidance: consent must be obtained from the user first, and the outcome must be reported afterward with report_preset. The discovery-to-transfer chain (find_presets/get_preset then this tool) is stated explicitly, though no explicit when-not-to-use condition is given.

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

All osc-bridge 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.