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

With no annotations, the description carries the full burden and does so for the key behaviors: relative vs absolute semantics, the default mode, the y-axis direction (downward positive), and the critical autoplace=false meaning (MuseScore stops auto-repositioning). It omits auth needs, reversibility, and return behavior, hence not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then targeting, then modes, then autoplace — a logical progression where each sentence conveys operational detail. Dense but not padded; minor density in the targeting clause keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-param mutation tool with no annotations and no output schema, the description covers targeting, mode semantics, and autoplace behavior adequately. Gaps remain around return values and whether multiple elements can be affected, but the essentials for correct invocation are present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 40% across 10 params, but the description compensates well: it defines id format (DYNAMIC#3), the type+measure+staff+nth targeting, dx/dy units (sp, y-down), mode defaults, and autoplace. Most semantically ambiguous params gain meaning beyond the schema, though score_id and the nth detail rely on schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (ずらす/move) plus the resource (記号), and enumerates concrete element types (強弱・歌詞・テキスト・テンポ・ヘアピン). An agent can distinguish this from layout_inspect and layout_set_* siblings without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the two targeting strategies (layout_inspect element id vs type+measure+staff+nth) and the two operating modes (relative default vs absolute), giving clear when/how context. It does not, however, explicitly name sibling alternatives or exclusions, so it stops 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.

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

With no annotations, the description carries the full burden and does well: it discloses that vertical spread is disabled, specific spacing values are tightened, spatium is binary-searched, and a new version is baked via `mscore -S`. It also states the no-op condition when the score already fits. It stops short of describing permissions, failure behavior, or how the new version is surfaced.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first sentence, followed by the tightening algorithm and the no-op edge case. It is dense and technical but appropriately sized for a complex layout mutation, with little wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex mutation tool with no annotations and no output schema, the description covers internal behavior well but omits what the caller gets back, how the new version is identified, and whether the operation requires an open score or specific state. Those are important gaps for correct invocation and follow-up.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 60%, and the description adds meaningful semantics for the undocumented `tighten` parameter and for `max_spatium_mm` (allowing enlargement up to a limit). `pages` is also clarified by the purpose. `min_spatium_mm` is left to the schema, which already documents it, so the description adds solid value without fully restating every parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource: fit a score within N pages. It is clearly distinguishable from sibling layout tools such as layout_set_stretch and layout_systems_every because it targets a page-count outcome rather than manual spacing or system breaks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the default tightening behavior and the no-op case when the score already fits, which implies when the tool is useful. However, it never names alternatives or says when to prefer layout_set_stretch, layout_systems_every, or layout_inspect instead, so routing guidance is only implicit.

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

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

With no annotations at all, the description carries the full burden and does disclose meaningful behavior: coordinates are in sp (staff-space) units, ids follow a concrete format (DYNAMIC#3, LYRICS#10, HAIRPIN#0.1) usable by element_offset, and it warns that the 1-based measure index can diverge from displayed measure numbers for pickup or skipped measures. It does not state read-only status explicitly or address cost/response size on large scores, so it is strong but not complete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One dense but well-ordered paragraph: return payload first, then units, then id format, then the measure-numbering caveat. Every clause carries operational information; nothing is redundant with the title or schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter, no-annotation, no-output-schema inspection tool, the description covers the returned structure (systems/pages, measures, symbols, overlaps), units, and id cross-references well enough to call it correctly. Remaining gaps are the unspecified include_measures behavior and no guidance on result size when include_elements is true.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 57%, and the description compensates for the undocumented measure_from/measure_to by defining measures as 1-based sequential indices with the pickup/skipped-measure caveat. It also supplies the element-type id vocabulary that element_types filters on and the sp unit convention. It adds little for include_measures and does not clarify range semantics (inclusive/exclusive) for measure_from/to.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a concrete enumeration of what the tool returns: measure order per system/page, per-measure width/stretch/break, symbol positions (dynamics, lyrics, text, hairpins) and overlap candidates. That is a specific resource (layout) with a read-oriented verb implied by '返す', so an agent knows what it gets back. It never explicitly contrasts itself with the sibling setters (layout_set_break, layout_set_stretch, layout_systems_every), which is the only reason it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: it hands off element ids to element_offset and explains that measures[].index/no resolves numbering ambiguity, which tells the agent it is the inspection step before element_offset. There is no statement of when to call this versus the layout_set_* mutators, nor any prerequisite or exclusion. Adequate but inferential.

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

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

With no annotations, the description carries the full burden: it discloses that existing breaks on the measure are replaced (an overwrite/destructive trait), that the operation runs through the headless MuseScore API, and that it produces a new version rather than mutating in place. It also warns that 1-based measure indices can diverge from displayed numbering. It does not mention error conditions (bad score_id, measure out of range) or whether score_save is still needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose, then the kind table, then replacement/new-version behavior, then the numbering caveat — a sensible order with no filler sentences. The trailing parenthetical on measure numbering is long and nested, slightly hurting scanability, but each clause conveys operational information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an unannotated mutation tool with no output schema, the description covers what changes (breaks replaced), the side effect (new version created), the execution environment (headless API), and the indexing convention with a way to verify it. Remaining gaps — failure modes and whether the result must be saved via score_save — are minor but real.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 33% (only score_id is documented in the schema), so the description must compensate, and it does: every kind enum value is defined in prose, and measures is explained as 1-based sequential ordering from the top of the score, including the pickup/anacrusis and skipped-number caveat plus the layout_inspect cross-reference. This adds real meaning beyond the integer-array schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: insert a break at the end of the specified measures, with 'none' explicitly removing it. The five kind values (line/page/section/nobreak/none) make the scope unambiguous, and the title reinforces the insert/remove duality. An agent can distinguish this from layout_set_stretch or layout_fit_pages purely from the description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The enumeration of kind values effectively tells the agent which mode to pick for each intent (line break, page break, section break, keep measures together, remove break). It also points to layout_inspect's measures[].index / no for resolving numbering, which is a concrete usage prerequisite. It never states when *not* to use it versus the other layout_* siblings, so it stops just 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.

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

With no annotations, the description carries the full burden, and it does disclose real behavior: values are clamped to 0.1–10 at MuseScore render time, and measure indices are 1-based with a pickup-measure offset caveat. It omits mutation-relevant facts such as whether the change is persisted, whether score_save is needed, or whether score_undo reverses it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The action and its parameter semantics are front-loaded in the first clause, and the trailing parentheticals each add distinct operational value (numbering caveat, cross-reference to layout_inspect). No sentence is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter mutation with no annotations and no output schema, the description covers the value scale, the range semantics, the index-base caveat, and where to verify index correspondence via layout_inspect. Return values are not needed since the effect is a setting write, and the remaining gaps are minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50% (from and value have no schema descriptions), and the description compensates well: it defines value's scale (1 = standard, >1 wider, <1 narrower, clamped 0.1–10) and explains that measures are 1-based sequence numbers with a display-number mismatch caveat. The from/to range pairing is only implied by 範囲, and score_id is left entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (設定する) and resource (小節の範囲の伸び縮み / userStretch), which is clearly distinct from siblings like layout_set_break, layout_systems_every, and layout_fit_pages. It stops short of explicitly contrasting itself with those alternatives, so it does not reach a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the subject matter: use it to widen or narrow a measure range. The description never states when to prefer this over layout_fit_pages or layout_systems_every, nor any prerequisites such as the score being open, so guidance remains inferential.

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

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

With no annotations, the description carries the full burden and does so: it discloses that existing breaks and nobreak marks inside the range are removed first, that page breaks and section breaks survive and are returned in keptBreaks, and that lock requires MuseScore 4.6+. That is precisely the destructive side-effect and version-permission information an agent needs before calling a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core action is front-loaded in the first clause, and the heavy parentheticals on method semantics, break removal, and numbering all carry real information. It is dense and nested rather than wasteful, but the numbering caveat could be split out for readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter mutation tool with no output schema and no annotations, the description covers method semantics, side effects, keptBreaks as a return field, and how to verify measure indices via layout_inspect. It omits whether an undo point is created and any precondition that the score must be open, which score_undo/score_open siblings imply but never state.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 60% — 'every' and 'method' have no schema descriptions — but the description compensates fully, defining 'every' as measures per system and spelling out both enum values of 'method' with their behavioral differences and the 'lock' default. It also clarifies the 1-based sequential measure numbering and the pickup/skipped-measure offset, which the schema does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource: it converts a measure range into systems of N measures, with a default of the whole score. It clearly differs in intent from layout_set_break (single break insertion) and layout_fit_pages, though it never names those siblings to route the agent explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains the two methods and their trade-offs — lock keeps exactly N measures per system even when the width is short (MuseScore 4.6+), whereas breaks may let MuseScore break earlier. Defaults are given for range and method, but there is no explicit statement of when to choose this bulk tool over layout_set_break or layout_fit_pages.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the comparison's output dimensions (including pixel-level image diff, hinting at rendering cost), but it never states that this is a read-only operation, whether missing versions error out, or what the response shape is.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence, front-loaded with the core action and the default behavior before enumerating comparison outputs. The list is long but every element describes a real returned metric; no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully substitutes by enumerating return contents, which is the strongest part. However, for a 4-parameter tool with 25% schema coverage and no annotations, it leaves parameter meaning and safety/side-effect profile underspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 25% (only score_id documented). The description implies the from/to defaults ('previous and current') but never names those parameters or explains their semantics (version indices? numbers?), and the dpi parameter — clearly relevant to the pixel-diff output — is not mentioned at all.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb (compare) + resource (two versions) plus an explicit enumeration of what differences are returned: page count, systems, measures per system, stretch/break changes, style diffs, pixel diffs. No sibling tool offers version comparison, and the description makes that niche unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The default 'previous vs current' behavior is stated, which is useful context, but there is no explicit when-to-use/when-not guidance and no disambiguation from layout_inspect or score_render, which also surface layout information. Usage is inferable rather than directed.

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

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

With no annotations, the description carries the burden and does well: it discloses that the file is copied to a working area, that the original is never written to, that an overview is returned, and that a score_id is the handle for later calls. It stops short of stating permission requirements or error behavior for unsupported/corrupt files.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Very compact: one sentence covers the action, formats, non-destructive copy, and return contents, and a second sentence covers the score_id handoff. Front-loaded and free of filler, though the two ideas could be split more cleanly for scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description must describe the return, and it does: the overview fields and the score_id are enumerated. For a single-parameter entry-point tool this is nearly complete; only failure modes (bad path, unsupported format) are unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter, and schema coverage is 100% with its own description ('absolute path'), so the schema does the heavy lifting. The description adds value by enumerating the accepted file extensions (.mscz/.mscx/.musicxml/.mxl), which the schema does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (open/copy a score file) plus the supported formats, and discloses that it returns an overview (title, parts, measures, pages, system layout). The clause '元のファイルには書き込まない' implicitly contrasts it with the mutating siblings such as score_save, so the agent can tell what this tool is and is not.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says subsequent operations use the returned score_id, which tells the agent this is the entry point before score_render/score_save/etc. It does not name an alternative or state when NOT to use it (e.g., versus score_compare), so it falls short of full routing guidance.

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

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

No annotations, so the description carries the full burden. It usefully discloses the return form (PNG images) and the hard 4-page-per-call ceiling, but the dpi range and defaults merely restate the schema, and nothing is said about error behavior for out-of-range pages or how multi-page results are packaged.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences: what it renders and returns first, then the dpi constraint, then the batch limit. Zero wasted words and correctly front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly explains the return type (PNG images) and the cardinality cap. It falls slightly short on how multiple page images are delivered and on failure modes, but it is sufficient for a simple read-only render tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75%, with score_id, version, and pages already documented in the schema. The description only echoes the dpi bounds and the version default, adding little meaning beyond the structured fields; a 3 baseline applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb and resource: render pages of the current (or specified) version to PNG and return images. None of the siblings render or produce images, so an agent can distinguish it without inspecting schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The parenthetical '（または指定した版）' implies when to pass a version, and the 4-page cap sets a batching constraint. However, there is no explicit guidance on when to render vs. inspect structure (e.g., layout_inspect) or what to do for larger page ranges.

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

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

With no annotations, the description carries the full burden and does so richly: default non-overwrite, overwrite=true triggering a '.bak-timestamp-random' backup (itself never overwritten), rejection of write-protected/working folders even via symlinks or case variants, and rejection when the destination is a symlink. This is exactly the behavioral context an agent needs before a destructive write.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action in the first clause, then layers overwrite/backup and folder restrictions. Dense but nearly every sentence carries distinct, necessary information; minor edge is the single dense paragraph.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A 3-parameter mutation tool with no annotations and no output schema; the description adequately covers overwrite behavior, backup policy, and access restrictions. It could mention return/confirmation behavior, but the operational picture is essentially complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67%, with path and score_id documented in-schema. The description compensates strongly for the undocumented overwrite parameter by fully specifying its true/false semantics and side effects, adding meaning well beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (保存する/save) plus the resource (今の版/current version) and the output formats (.mscz or .pdf). An agent can distinguish this save operation from siblings like score_open or score_render 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains constraints (default non-overwrite, folder restrictions) but never names an alternative or explicitly says when to prefer this over score_render or other siblings. Usage is implied rather than routed.

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

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

With no annotations, the description carries the full burden, and it does disclose a genuinely useful behavioral trait: version 0 means the state right after opening, and filenames are not reused so numbering diverges from filename digits after an undo followed by an edit. However, it never states that this is a read-only operation, nor what errors occur for an unknown or unopened score_id.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, with the purpose front-loaded and the numbering caveat second. Nothing is wasted, though the caveat sentence is dense and could be clearer about the undo-then-edit scenario it refers to.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must explain the return value, and it only says it returns versions and the current version without describing the shape (e.g. list of version numbers with filenames). For a zero-argument-complexity read tool this is adequate but leaves the response structure undefined.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single parameter score_id is documented in the schema as the value returned by score_open. The description's phrase 'the open score' loosely implies the same scope but adds no new syntax or constraints, so the schema baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: it returns the version list of the currently open score plus the current version, with version 0 defined as the state right after opening. It is clearly distinguishable from siblings like score_undo or score_save, though it never explicitly names how it differs from score_compare, which also inspects score state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to call this versus alternatives such as score_undo, score_compare, or score_save. Usage is only inferable from the fact that it reports version state, so the agent must guess the workflow context.

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

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

With no annotations, the description carries the full load, and it does disclose the crucial destructive trait: any change made after reverting discards all versions beyond the revert point, while the file itself survives. This is exactly the kind of irreversible side effect an agent must know before calling. It stops short of covering permissions, rate limits, or whether the revert itself is undoable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence with the core action front-loaded and the caveats in a parenthetical immediately after. Every clause carries information: the operation, the non-deletion guarantee, and the forward-history loss. Nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-parameter mutation tool with no annotations and no output schema, the description covers purpose and the main destructive consequence. It could go further by saying whether the score_id remains valid after a revert or what the call returns, but the essential contract is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%: score_id is documented in the schema (from score_open), while steps only has type/default/bounds. The description compensates by explaining that steps means how many versions to move back, which adds semantics beyond minimum/maximum 1–100. The default of 1 is left to the schema and not restated, which is acceptable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (戻す/revert) applied to a specific resource (今の版/current version) and names the controlling parameter (steps). No sibling overlaps with this operation (score_save, score_open, score_render, etc. are all non-reverting), so an agent can identify it immediately, though the description never explicitly contrasts itself with a sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the verb 'revert' plus the constraint that the file itself is not deleted, which signals this is a history operation rather than a delete. However, there is no explicit statement of when to prefer this over, say, re-opening or comparing versions, and no prerequisites (permissions, whether score_save is needed first) are given.

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

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

With no annotations, the description carries the full burden, and it contributes one genuinely useful behavioral fact: keys absent from the score return their default values, so absence is not an error. It does not disclose the return shape (key→value mapping?), whether the read is scoped to 'now' version only, or any permission expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero waste, with the resource identified first and the default-value caveat second. Nothing padding and nothing redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter getter this is close to sufficient, but with no output schema and no annotations, the description should say what comes back (a mapping of requested keys to values) and how to discover valid key names. Those two gaps keep it at minimum-viable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% and the undocumented parameter is the important one: `keys`. The description implies they are style key names but gives no format, no naming convention, and no pointer to style_list as a way to discover valid keys, nor any note about the 1–100 item bound. Only the score_id parameter is documented, and that is in the schema, not the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb + resource pair: reads the current version's style values, and it names the underlying artifact (score_style.mss). An agent can tell this apart from style_set (write) without opening the schema, but the description never explicitly contrasts with style_list or style_set.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use / when-not-to-use or named alternative, but the read semantics are strongly implied by '読む', which combined with the sibling names style_set and style_list makes the correct choice reasonably inferable. Guidance is left implicit rather than stated.

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

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

With no annotations, the description carries the burden and does well: it discloses the return payload fields, the default cardinality (~60), the full searchable universe (1972), and version pinning (v4.7.6). Read-only nature is implied by '返す' but not stated explicitly, and no pagination/limit behavior is mentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with no waste: the return shape is front-loaded, then default-vs-query behavior. Every clause carries information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only listing tool with no output schema, the description adequately characterizes the returned fields (type, unit, default, description) and the dataset size. The only real gap is the undocumented category filter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains query fully (searches names and descriptions across all 1972 entries), but the category parameter is completely unaddressed in both schema and description. Half the parameters remain opaque.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (返す = returns) and resource (レイアウトに効くスタイルのキー / style keys affecting layout), plus the exact version (v4.7.6 Sid). It clearly describes what comes back (type, unit, default, description). It does not contrast itself with the sibling style_get, so sibling differentiation is missing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It usefully explains the default behavior (~60 common keys) versus the query behavior (search across all 1972), which is real usage guidance. But it never names style_get as the alternative for fetching a single key, and there are no explicit when-not-to-use conditions.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the mutation mechanism (build a partial .mss and bake it in), that a new version is produced rather than in-place mutation, and what is returned (pages/systems before and after). It also surfaces non-obvious interaction hazards (vertical-spread overrides, page width pairing) that no annotation or schema field would reveal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose and example, then units, mechanism, and caveats in a compact block with no filler. Dense but every sentence contributes; the caveat sentence is slightly run-on but earns its space by preventing known failure modes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema and no annotations, it covers mechanism, units, validation, return contents, and interaction constraints — enough to call it correctly. Minor gaps remain: no guidance on discovering existing keys (style_get/style_list) or on failure behavior for invalid keys, but nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50% — `values` is an untyped object — but the description compensates by specifying the unit conventions per value type (SPATIUM in sp, page* in inches, spatium in mm, BOOL as true/false, POINT as {x,y}) and noting values are validated against type. The only parameter the schema documents (score_id) is already self-explanatory.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: batch-setting style keys/values, illustrated with a concrete payload example ({"spatium":1.5, "minSystemDistance":10}). It is clearly the write counterpart to style_get, so an agent can distinguish it from the read sibling without inspecting either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operating context: send only the keys you want changed, values are type-checked, and the tool bakes a fresh .mss via mscore -S to produce a new version. It adds two situational exclusions (enableVerticalSpread=true disables staffDistance/akkoladeDistance/minSystemDistance; pageWidth changes need pagePrintableWidth), though it never routes to sibling tools such as layout_set_stretch for non-style adjustments.

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