Skip to main content
Glama

set_code

Replaces the live music in Moontide with complete Strudel code and schedules takeover now or at the next bar/phrase, starting playback first if needed.

Instructions

Replaces the music in the Moontide page with new Strudel code; the new pattern takes over within a fraction of a second, mid-cycle, without stopping the music. To change part of an existing piece, edit_code sends only the change; set_code is for a new piece or a rewrite of most of its lines. With at: 'bar' or at: 'phrase' the code is checked at once and takes over on the next bar line or the next phrase line instead (a bar is one cycle of 4 beats; a phrase is 4 cycles, or phraseCycles, counted from Play); the reply gives the cycle and about how many seconds, a newer change replaces a waiting one, and Stop cancels it. When the tempo changes, the reply gives it in BPM. Every call runs the whole program again, so a getTime() anchor restarts at each change; a transition that must keep running takes .timeline(id), which keeps its anchor as long as the code keeps the same id (see the transitions topic). Double-quoted and backtick strings are parsed as mini-notation wherever they appear, helpers included, while single-quoted strings stay plain JavaScript (see the tidal-differences topic). When Moontide is not started yet, set_code starts it first: its page opens in a new browser tab and the call waits up to 30 seconds for that page to connect. Before changing existing music, call get_code and build on what it returns, including hand edits. Keep what the user said matters; if a small request needs a full rewrite and the user said what matters, ask first, otherwise rewrite and say so. When a request is vague, act on your own reading of it instead of asking first. Returns the code as confirmed by the page. Pass a short label saying what changed; every version that plays is kept in the history. Then tell the user in one line what you chose: the musical terms, plus a short image in plain words.

Input Schema

NameRequiredDescriptionDefault
atNoWhen the change takes over: 'now' (the default) within a fraction of a second, 'bar' on the next bar line, 'phrase' on the next phrase line (4 cycles, counted from Play). The code is checked at once; the reply says the cycle and about how many seconds away it is.
codeYesComplete Strudel code to play
labelNoA few words saying what this change is, for example "added a bass"; shown by list_history
answeringNoThe id of the page request this change answers, from its request line; the page shows that request as applied only when the change names it here
glideBarsNoWhole bars, 1 to 64, to move the tempo smoothly from the tempo that plays to the one this code sets with setcps or setcpm; with at, it starts at the line. Refused when nothing plays, no tempo is set or it already plays. Stop, or code with another tempo or none, cancels it
phraseCyclesNoHow many cycles one phrase lasts, for at: 'phrase' (2 to 64, default 4)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

No annotations exist, so the description must carry the full burden and largely does: takeover latency ('within a fraction of a second, mid-cycle'), deferred takeover semantics for at, waiting-change replacement and cancellation by Stop, a 30-second wait when Moontide is not started, restart of getTime() anchors on every call, and history retention per played version. The gaps are minor rather than structural — error/failure modes beyond the 'refused' case for glideBars are not described.

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 purpose and the edit_code contrast are front-loaded, which is correct, but the body is one very long compound paragraph in which timing behavior, string-parsing rules, startup waiting, edit policy, history, and user-facing response style are all run together. The sentences are individually dense and several pack two or three distinct facts separated by semicolons, which raises reread cost; the editing-policy sentence ('Keep what the user said matters...') is agent instruction that sits awkwardly beside mechanical tool behavior.

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 six-parameter mutation tool with no annotations and no output schema, the description covers what an agent needs to call it correctly: when it fires, what it returns ('the code as confirmed by the page', the cycle and rough seconds, BPM on tempo change), what the label and history do, and the prerequisite of reading get_code first. Return-value and prerequisite knowledge that would otherwise be missing is present.

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 baseline is 3; the description earns above that by explaining cross-parameter behavior the schema does not: that 'bar'/'phrase' validate the code immediately but defer takeover, that phrase length is 4 cycles or phraseCycles counted from Play, and that glideBars starts at the deferral line and is cancelled by Stop or a tempo-less rewrite. It still leaves 'answering' and 'label' almost entirely to the schema, so it stops short of a 5.

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?

Opens with a specific verb and resource: 'Replaces the music in the Moontide page with new Strudel code', and immediately names the sibling it is not ('edit_code sends only the change; set_code is for a new piece or a rewrite of most of its lines'). An agent can distinguish it from edit_code and get_code without opening any schema.

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?

Explicit routing rules against alternatives (edit_code for partial edits, get_code before altering existing music), plus decision rules for ambiguous cases: ask first when a full rewrite would override what the user said matters, otherwise rewrite and say so, and act on your own reading when the request is vague. When-not-to-use conditions are stated, not implied.

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