Skip to main content
Glama
Sign In
moontide

moontide

by konni-arcadia
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

save_midi_model

Checks and summarizes a drafted MIDI instrument model, then saves it to the user's Moontide data folder only after confirmation. Prevents unconfirmed or shipped-model overwrites.

Instructions

Saves an instrument model that you drafted from a page of the instrument's manual the user pasted, into the user's Moontide data folder (models/.json), never into Moontide itself. First call it with confirmed: false: it checks the model and returns a summary (channels, sounds with their program numbers as sent and as numbered in a manual from 1, controls, reset bytes, notes) and saves nothing. Show that summary to the user, and call it again with the same model and confirmed: true only after they say yes. It refuses an id of a model Moontide ships, and an existing model unless overwrite is true. Fields: id (lowercase letters, digits, dashes or underscores, at most 32), name, channels { melodic, rhythm } (lists of channels 1-16), bankSelect (none, msb or msb-lsb), rhythmBank (optional: true when the instrument chooses drum kits by bank select and program change; every rhythm sound then needs a bank), drumMaps (optional, at most 8: [{ id, name, notes: [{ note 0-127, name }] }] typed from the instrument's manual), drumMap (optional: the id of the map of kits without their own; general-midi is built in), a rhythm sound's noteMap (optional: a map id, or null when no map is known for that kit), defaultVolume (0-127), clock (optional: true when the instrument follows MIDI clock, so Moontide sends it the clock, Start and Stop), monophonic (optional: true when the instrument plays one note at a time), reset (optional: sysex with at most 4 messages, each { kind: roland-dt1, model, address, data } as hex bytes or { kind: raw, bytes } from F0 to F7 and at most 32 bytes, and waitMs), controls ([{ id, name, cc, min, max, default }]), sounds { melodic, rhythm } ([{ name, program 0-127 as sent, bank { msb, lsb } when the instrument needs one }]) and notes (facts about the instrument, at most 10).

Input Schema

NameRequiredDescriptionDefault
modelYesThe drafted model, as a JSON object
confirmedYesfalse to check and summarize without saving; true only after the user said yes to the summary
overwriteNotrue to replace an existing user model with the same id

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so: it discloses the dry-run behavior ('saves nothing'), the exact contents of the check summary (channels, sounds, program numbers, controls, reset bytes, notes), and the refusal conditions. Overwrite semantics and the user-confirmation gate are spelled out, which is exactly what an agent needs before a write.

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?

Front-loading is good — workflow first, field inventory second — and every clause carries real constraint information. However, the field list is a single run-on enumeration that would be far more scannable as a bulleted or structured block, making it easy to mis-parse nested optional fields.

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?

For a complex nested write tool with no annotations and no output schema, the description covers the confirmation loop, refusal cases, return-summary contents, and all field constraints. An agent has enough to call this correctly on the first try.

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% for the three top-level params, but the 'model' parameter is an open object with no internal schema, so the description is the only source of the field structure. It documents id format and length, channel ranges, bankSelect/rhythmBank/drumMaps rules, reset sysex limits, and program ranges; the density makes some nesting (drumMaps vs drumMap, noteMap) harder to parse than ideal.

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 ('Saves an instrument model... into the user's Moontide data folder (models/<id>.json)') and explicitly scopes it away from Moontide itself, which separates it from the sibling save_midi_catalog by resource and destination.

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?

Prescribes an exact two-step workflow: call with confirmed: false first, show the returned summary to the user, then re-call with confirmed: true only after they approve. It also names the refusal cases (shipped ids, existing models without overwrite), leaving nothing to inference.

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