Skip to main content
Glama

get_midi_instruments

Read-only

Lists user-described MIDI instruments with ports, channels, status, and sound counts so you can verify setup before writing MIDI code. Pass an id to retrieve its full sound list.

Instructions

When the user has described their instruments, call this before writing MIDI code. Lists the MIDI instruments the user described in instruments.json, as facts: for each one its id, model, exact port name, whether it is connected right now, its channels and their roles, how many sounds it has, its bank select, its reset, whether it follows MIDI clock and its controls. Pass instrument (an id from that list) to get that instrument's full sound list, with the program number sent for each sound and its bank when it has one. A sound is chosen in the code with the sound option of .midi(). An instrument with a sound catalog shows how many sounds the catalog holds and its categories; search_midi_sounds finds them. For an instrument whose model describes settings it lists the tone, part and scene setting names with their ranges, the tone ones per engine, and the settings topic of get_strudel_reference has their rules; with instrument set it gives the engine of each sound the catalog places in one. For an instrument with a rhythm channel it says how a kit goes out and which drum map applies; with instrument set it lists each drum map as note numbers and drum names, a kit's own map only when it differs from the model's, and says when a kit has no known map. Drum notes are written as note numbers in the code. It also says which instruments the user switched off in the page: their notes are silent, and .midi() code newly aimed at them is refused until the user switches them on.

Input Schema

NameRequiredDescriptionDefault
instrumentNoAn instrument id from instruments.json, to list its sounds

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

With only readOnlyHint=true supplied, the description carries the behavioral burden and does so richly: it lists the returned facts, explains conditional sound-list and drum-map behavior, and notes enforcement such as silent notes and refused .midi() code for switched-off instruments.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening trigger is front-loaded, but the description is a single sprawling block with long sentences covering settings, drum maps, sound selection, and disabled instruments. The information is mostly useful, yet it is not concise or easy to scan.

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

Completeness5/5

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

There is no output schema, so the description must explain return values and conditional behavior; it does so extensively. For a one-parameter read-only getter, the definition leaves no material gap for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, but the description adds real meaning: it says instrument must be an id from the listed instruments and explains that setting it expands the result to full sound lists, program numbers, banks, engines, and drum maps. This is substantially more than the schema alone provides.

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?

The description gives a specific verb and resource: it lists the MIDI instruments the user described in instruments.json and enumerates the facts returned. It also distinguishes itself from search_midi_sounds and get_strudel_reference by naming those siblings in the relevant conditional contexts.

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?

It gives a clear trigger: call it before writing MIDI code when the user has described their instruments. It also explains what passing instrument does, but it stops short of explicit when-not-to-use guidance or a crisp decision rule against every sibling.

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