Skip to main content
Glama
Sign In
modularsynth-mcp

modularsynth-mcp

by gregorybruneau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Set sample

set_sample

Load a sound (an id from list_sounds) into a sampler module. Then trigger it with its gate input (from a Trigger Seq, a Note Grid or MIDI→CV) and choose how it plays with set_param "mode": 0 one-shot (drums), 1 hold (plays while the gate…

Instructions

Load a sound (an id from list_sounds) into a sampler module. Then trigger it with its gate input (from a Trigger Seq, a Note Grid or MIDI→CV) and choose how it plays with set_param "mode": 0 one-shot (drums), 1 hold (plays while the gate is high), 2 loop (synced to the clock).

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": {
      "id": "<id>",
      "sound": "<sound>"
    },
    "name": "set_sample"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
soundYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.1

TDQS

A4.1/5.0
Behavior4/5

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

Annotations only cover the safety profile (not read-only, not destructive, closed-world); the description adds real behavioral context — the sampler must be gated to sound, and the three playback modes (one-shot, hold, loop-synced) determine behavior. It omits what happens if the module isn't a sampler or if a sample is already assigned (overwrite vs. append).

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 load action and keeps the trigger/mode context in a single tight follow-on sentence. The inline mode enumeration is informative but partly belongs to set_param, slightly diluting focus.

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 two-parameter, no-output-schema tool, the description covers purpose, the sound-id source, the trigger path, and mode semantics. The remaining gap is the ambiguity of the 'id' parameter and error/overwrite behavior, which are minor for a simple setter.

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?

With 0% schema coverage the description must carry both parameters. It explains 'sound' well (an id obtained from list_sounds) but never clarifies what 'id' refers to — presumably the target sampler module — nor the expected id format. That half-explained pair puts it at the minimum-viable level.

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 ('Load a sound ... into a sampler module') and anchors the 'sound' argument to a sibling tool (list_sounds). An agent can distinguish it from set_param, list_sounds, and add_module immediately.

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?

Gives the operational context: the sample must be loaded, then triggered via gate input from a Trigger Seq, Note Grid, or MIDI→CV, and the playback mode is chosen with set_param 'mode'. It routes to the sibling for mode selection but doesn't state prerequisites such as needing an existing sampler module or how it differs from add_module.

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