Skip to main content
Glama

edit_code

Modify existing Strudel music code by sending exact old-to-new text replacements; all edits apply together, or the call is rejected when a match fails.

Instructions

Changes part of the code that will play by exact text replacement, sending only the change. Use it to change an existing piece; use set_code for a new piece or a rewrite of most of its lines. Each edit has old_string, new_string and optional replace_all, as in your own Edit tool. Every old_string must match exactly once (or set replace_all), and every edit is matched against the code as it is before this call, so edits must not overlap and one edit cannot match text another edit writes. An edit that matches nowhere, matches more than once, overlaps another edit or changes nothing refuses the whole call with the reason and the edit number: nothing is applied and nothing reaches the page. CRLF counts as LF. The edits apply to the newest code that will play: the change waiting for its bar or phrase line when one waits (get_code shows the code playing until then), otherwise the code playing now with the user's evaluated hand edits; text typed in the page but not evaluated is replaced, as with set_code. Pass base, the version number get_code shows, to have the edit refused when the music moved on since. at, phraseCycles and label work as in set_code, and the edited program goes through the same checks, history entry and notices. The reply gives the version, when the change takes over and the changed lines with a few lines around them, not the whole program; get_code returns it. Put all replacements for one change in a single call: a second edit_code sent before the first reply is refused. It edits music that already plays, so before Moontide is started it is refused and starts nothing: use set_code first. Call get_code before changing existing music.

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.
baseNoThe version number get_code shows (#N); the edit is refused when another version plays now
editsYesThe replacements, 1 to 50, applied all together or not at all
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.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and does substantial work: it discloses atomicity ('nothing is applied and nothing reaches the page'), the exact rejection reasons reported with the edit number, the reference version edits apply against, CRLF-as-LF normalization, and the concurrency rule. It also describes the shape of the reply (version, takeover time, changed lines with context). The main gap is permissions/auth and rate-limit context, which is minor here given the richness of the rest.

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?

Purpose and the sibling contrast are front-loaded in the first two sentences, and almost every sentence carries operational information. It is dense and paragraph-shaped rather than scannable, and a few clauses (the parenthetical about get_code showing the playing code, the repeated get_code advice at the end) restate earlier points, costing some tightness.

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 7-parameter mutation tool with no output schema, the description covers everything an agent needs: preconditions, atomicity, matching rules, precedence between pending and currently playing code, batching, concurrency, and what the reply does and does not contain. It explicitly defers the full program to get_code, which closes the remaining question about return values.

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, but the description adds real cross-parameter meaning the schema cannot express: edits are matched against the pre-call code, must not overlap, and one edit cannot match text another edit writes. It also explains base as the version from get_code that causes refusal when the music moved on, and says at/phraseCycles/label work as in set_code rather than restating them.

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 precise verb+resource and mechanism: 'Changes part of the code that will play by exact text replacement, sending only the change.' It immediately contrasts itself with the sibling set_code ('use set_code for a new piece or a rewrite of most of its lines'), so an agent can distinguish the two without opening either 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?

Gives explicit routing rules against alternatives (set_code for new code or majority rewrites, get_code before editing existing music), plus hard preconditions ('before Moontide is started it is refused... use set_code first') and a batching rule ('Put all replacements for one change in a single call'). It even names the failure mode of violating that rule (a second edit_code sent before the first reply is refused).

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