01Safety
0.0 / 30
What changed in the harness
Selection accuracy 70→75, token cost up 1%, unconfirmed writes 0%→0%.
Category breakdown
Where the score comes from.
Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.
02Legibility
22.5 / 30
03Economics
12.1 / 20
04Discoverability
11.1 / 20
Highest-impact fix
Estimated gain +30 pointsAdd explicit identity and permission preflight tools
Expose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.
Description evidence
Defects and rewrites.
2 defects found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.
| Tool | Defect types | Suggested rewrite |
|---|---|---|
notation_validate |
params_unexplained |
Pre-flight validate a notation_render input without rendering. Returns errors with concrete `fix` field that tells the agent exactly how to repair malformed input. Substantially cheaper than notation_render because it skips the Verovio engraving step entirely. WHEN TO USE: when iterating on input shape and uncertain whether it is well-formed; when input came from user-supplied or LLM-generated data that may be malformed; when surfacing precise validation errors to your end user before committing to a full render; when learning the input format (combine with notation_examples to see canonical inputs). WHEN NOT TO USE: if input is known to be valid (just call notation_render directly — it validates internally too); if you have not learned the schema yet (call notation_schema or notation_examples first to see the format). INPUT: identical shape to notation_render. `instruments` array is required (each with `name` and `notes` or `voices`). All other fields are optional and validated but not required: `title` (string, rendered above the score), `composer` (string, rendered top-right), `tempo` (number, BPM, default 100, affects MIDI timing only), `timeSignature` ([beats, beat-unit] pair, default [4,4]), `keySignature` (human-readable string like "G major" or "Bb minor", default "C major"). OUTPUT (JSON, valid): { ok: true, requestId, valid: true, warnings: ValidationIssue[], meta: { measureCount, instrumentCount, voiceCount, durationBeats }, attribution }. Warnings are non-blocking notices (e.g. unusual time signature handling). OUTPUT (JSON, invalid): { ok: false, requestId, valid: false, errors: ValidationIssue[], warnings, attribution }. Each ValidationIssue: { path: "instruments[0].voices[0].notes[3]", code: "BAD_PITCH"|"BAD_DURATION"|"MISSING_FIELD"|"BAD_KEY_SIG"|..., message, fix: "Use scientific notation: letter A-G + optional # or b + octave number, e.g. C4, F#5, Bb3.", severity: "error"|"warning" }. Surface the `fix` to your user or use it to auto-repair. EXAMPLE INPUT: { "instruments": [{ "name": "Violin", "notes": ["C5/q","D5/q","E5/q","F5/q"] }] } TYPICAL LATENCY: 30-100 ms (no Verovio render; pure JSON-to-Score conversion + bar-line arithmetic). |
theory_validate_ranges |
params_unexplained |
Check every note in a Score JSON against its instrument's standard practical range. Returns warnings for out-of-range pitches with measure, beat, MIDI number, and severity. WHEN TO USE: after parsing a MusicXML file with theory_parse_xml and before analysis — catch unplayable or extreme notes early; when generating or editing a score programmatically and want to verify instrument idiomatic range; when a student submits a composition for critique and range errors should be flagged. SEVERITY LEVELS: "error" = note is > 1 semitone outside the practical range; "warn" = note is at the boundary (within 1 semitone). SUPPORTED INSTRUMENTS (partial name match, case-insensitive): Violin, Viola, Cello, Double Bass, Harp, Flute, Piccolo, Oboe, English Horn, Clarinet, Bass Clarinet, Bassoon, Contrabassoon, Soprano/Alto/Tenor/Baritone Sax, Horn, Trumpet, Trombone, Tuba, Piano, Organ, Marimba, Xylophone, Vibraphone, Glockenspiel, Timpani, Soprano/Mezzo/Alto/Tenor/Baritone/Bass (voice). INPUT: a maestroAnalyst Score object — obtain one by calling theory_parse_xml with MusicXML text. Required: `notes` (flat array of Note objects) and `parts` (array of { id, name } PartInfo objects). Optional context fields also carried on a parsed Score object: `measureCount` (integer, total measure count), `keySignatures` (array of key-signature change events), `timeSignatures` (array of time-signature change events). OUTPUT: { ok, requestId, warnings: [{ measure, beat, pitch, midi, partId, instrumentName, min, max, severity }], attribution }. Empty `warnings` array means all notes are in range. EXAMPLE: pass a Score with a Violin part containing a note at A7 (MIDI 105) — it will return severity "error" since violin tops out around B7/MIDI 107 but A7 is beyond practical range. |
Selection evidence
Confusable tool pairs.
6 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
notation_examples |
notation_schema |
medium | Both are zero-input reference lookups meant for 'first encounter, learn the input format' tasks; a request like 'show me how to structure notation input' could plausibly be routed to either the worked examples or the formal schema. |
notation_render |
notation_validate |
medium | notation_render validates internally and returns the same ValidationIssue/fix structure on failure, so a task phrased as 'check if this score is correct' or 'will this notation work' is genuinely ambiguous between validating cheaply and just rendering. |
notation_validate |
theory_validate_ranges |
medium | Both are named 'validate' and check a score-like object for problems, but one checks JSON notation syntax/timing while the other checks instrument pitch ranges on a maestroAnalyst Score — a vague task like 'validate this score' could be misrouted despite differing input shapes. |
theory_respell |
theory_pitch_utils |
medium | theory_pitch_utils includes transpose_pitch with preferFlats spelling control, overlapping conceptually with theory_respell's enharmonic-spelling purpose; a task like 'give me the correct spelling after transposing this note' could plausibly go to either. |
theory_parse_xml |
theory_analyze_score |
high | Both accept raw MusicXML text directly, and theory_analyze_score performs parsing as its first internal step; a task like 'parse/analyze this MusicXML score' is highly ambiguous between getting the raw Score object versus the full harmonic analysis + knowledge bundle. |
theory_validate_ranges |
theory_analyze_score |
low | Both operate on score data and could be invoked for 'check this score for issues', but distinct input types (Score object vs raw xml) and clearly different outputs (range warnings vs harmonic analysis) make true confusion less likely. |
Compare the field