Cesure

Edit measures

edit_measures

Destructive

Rewrite measures from..to (numbers, inclusive) of ONE track of the draft with .cesure measures, as read_score returns them; to = from - 1 inserts before from. A measure written with its id stays that measure, even rewritten; one written without its id is a new measure, and the one it stood for is removed with what it carried (a repeat it opened, say). A measure of the range left out is removed, and measures [] removes the whole range. The other tracks follow column by column, as in the editor: a column is inserted, removed or given a time signature on every track; its repeat signs are carried as the editor carries them, and a tempo change stays on its column (on the next one when its column is removed), so no other column changes tempo. A note may be written by its pitch (E4, Bb3) in place of fret.string: Cesure chooses its string and fret, and never moves a note written with its string. The answer names the measures written. A written measure that does not read or does not fill its time signature refuses the whole call, the refusal naming each fault with its place; a measure sent back unchanged (same id and content) is kept as it was. Measure notation (.cesure): each voice is one string of beats separated by spaces. beat = content.duration[{d | tu 3}]; content = fret.string[{note props}] | pitch | (note note …) | r. Durations, on EVERY beat: 1 whole, 2 half, 4 quarter, 8, 16, 32, 64. Strings from 1 (the highest); x as fret mutes. A pitch (C4 = middle C, F#3, Bb2) lets Cesure choose string and fret; a staff is all by pitch or all fret.string. Beat props: d dotted, tu 3 triplet on each beat of the group. Note props: t tie, h hammer/pull-off and sl slide to the next note on that string, v vibrato, b (0 4) a whole-tone bend. EACH VOICE FILLS ITS TIME SIGNATURE EXACTLY: 4/4 = 4 quarters = 8 eighths, 3/4 = 3 quarters, 6/8 = 6 eighths; rests complete a short one. A measure without numerator/denominator is 4/4, whatever came before. A second voice (a bass under a melody) is a second string in voices. Examples (4/4): "5.3.4 7.3.4 r.2" (fret 5 then 7 on string 3 (strings from 1, the highest), quarters; a half rest); "(0.1 1.2 0.3).2 x.6.4 r.4" (a chord, a half; a muted note); "E4.8 F#4.8 G4.4 Bb3.2" (notes by pitch (C4 = middle C): Cesure chooses string and fret); "5.3.4{d} 5.3.8 2.1.8{tu 3} 3.1.8{tu 3} 5.1.8{tu 3} 7.2{h}.8 8.2.8" (dotted quarter; a triplet of eighths (each beat carries it); a hammer-on to the next note); "5.3.2 5.3{t}.4 7.2{sl}.8 9.2{v}.8" (a tie to the note before, a slide, a vibrato). A measure: {"id":"p2","numerator":3,"denominator":4,"staves":[{"voices":["0.1.8 2.1.8 3.1.4 5.1.4","0.6.2{d}"]}]}. The full format: https://cesure.app/format

Input Schema

Name	Required	Description
`to`	Yes	Last measure replaced; from - 1 to insert.
`from`	Yes	First measure replaced, from 1.
`draft`	Yes	The draft: the id a previous tool gave (draft).
`track`	No	The track, from 1 (default 1).
`measures`	Yes	The new measures, .cesure measure objects as read_score returns them; [] removes the range.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 10, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and idempotent=false, but the description adds substantial behaviour: atomic refusal of the whole call when a measure fails to parse or fill its time signature, the refusal naming each fault and its place, unchanged measures being preserved, and the column-wise propagation of repeats and tempo to other tracks. It even states what the response names.

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 operation contract is front-loaded, but the body is a very long single block that embeds a full notation grammar and many worked examples, duplicating what the linked format page and the schema cover. It is dense rather than wasteful, yet the notation reference could be trimmed in favour of the URL.

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 mutation tool with nested .cesure payloads, the description covers parsing rules, failure modes, cross-track effects, and input constraints, and an output schema exists so return-value details need not be restated. Nothing an agent needs before invoking it is missing.

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 goes beyond the schema by defining .cesure measure object semantics (id retention vs new measure, staves/voices, time-signature fill rules) and the exact meaning of from/to inclusivity and insertion. Only the track default is left to the schema.

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 with exact scope: 'Rewrite measures from..to (numbers, inclusive) of ONE track of the draft with .cesure measures'. It distinguishes itself from read_score by defining the notation it consumes and clarifies the insertion edge case (to = from - 1) and range removal (measures []).

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?

The description gives clear operating context: it explains replacement vs insertion, deletion of omitted measures, cross-track column behaviour, and how pitch-vs-fret input constrains string choice. It does not name sibling alternatives (e.g., transpose, refinger) or when-not to use it, so it falls short of a 5.

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

All Cesure tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?