Dorico Maestro

by romanstark

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes: navigation, mode switching, playback, saving, status, note/rest input, transposition. The two signature tools are identical in nature (both report unsupported popover actions), and run_command is a generic escape hatch that overlaps with all, but these are understandable exceptions.
Naming Consistency4/5
The naming pattern is mostly verb_noun with underscores (switch_mode, get_status, add_notes, set_time_signature, run_command), but a few tools use bare verbs or nouns (navigate, playback, save, transpose). No camelCase or chaotic mixing, so the inconsistency is minor.
Tool Count4/5
Twelve tools fits well within the expected 3-15 range for a music notation control server. The two unsupported signature tools are effectively stubs that report limitations rather than providing functionality, which slightly detracts from the count's value but is not excessive.
Completeness3/5
The set covers core workflows: navigation, playback, mode switching, saving, note/rest input, transposition, and status. However, it lacks direct operations for selection, undo/redo, deletion, or editing existing notes except via the generic run_command, and time/key signature setting is explicitly unsupported, creating notable gaps for a notation tool.
Average 4.2/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only says 'Save the current project' without mentioning overwrite behavior, file path implications, or any side effects. This is minimal for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the meaning, making it highly concise and well-structured.
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 simple zero-parameter action with an output schema, the description is fully complete. It explains the tool's purpose sufficiently without needing extra details on return values or parameters.
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?
The tool has zero parameters, so schema coverage is complete. The description does not need to elaborate on parameter semantics, and the baseline of 4 applies.
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?
The description clearly states the action ('Save') and the resource ('the current project'), with a specific reference to the File.Save command. This is unambiguous and distinguishes the tool from siblings like navigate or run_command.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of exclusions or typical scenarios, leaving the agent to infer usage solely from the name and save operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Maps to Window.SwitchMode' but does not state side effects, prerequisites (e.g., Dorico must be running), or whether this is a state-changing operation.
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?
The description is short and front-loaded, with the purpose stated in the first sentence. However, the truncated phrase 'the ``kWriteMode``…' suggests incomplete content, slightly detracting from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter and no annotations, the description covers the core functionality but lacks information about return values, failure conditions, or prerequisites. The presence of an output schema reduces the need to explain return values, but behavioral context is still minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a string type with no description or enum. The description compensates fully by listing the allowed modes ('write', 'engrave', 'play', 'print', 'setup') and noting that kWriteMode forms are accepted. This is essential for correct invocation.
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?
The description clearly states 'Switch Dorico's window mode' with a specific verb and resource. It distinguishes itself from sibling tools like navigate, playback, and run_command by focusing on window mode switching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and description, but no explicit guidance is given on when to use this tool versus alternatives. The listing of allowed modes provides some context for appropriate usage, but no 'when not to use' or alternative references are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly discloses that the tool reports the limitation rather than silently dropping the request, and explains the underlying reason (popover can't be filled via Remote Control API). This goes beyond what annotations would provide.
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?
The description is a short paragraph with three sentences covering purpose, rationale, and parameter examples. Each sentence earns its place, and the overall length is appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a stub that reports an unsupported operation, the description fully explains what the tool does, why it does it, and what the parameter should look like. With an output schema present, return value details are not needed here.
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?
The schema has one parameter, signature, with 0% description coverage. The description adds meaning by providing examples ('4/4', '3/4', '6/8') and indicating the expected format, which the schema does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's intended action ('Set a time signature') but immediately clarifies it is 'NOT yet supported over the API' and that the tool actually 'reports the limitation.' This specific behavior distinguishes it from sibling tools like set_key_signature, which presumably works.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should not be used for actually setting a time signature because the API can't transmit the value, but it gives no explicit 'when to use' or alternative tools. The limitation is clear, but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a meaningful behavioral trait: the first connection shows an approval dialog and token reuse on later runs. This adds useful context beyond a simple 'connect' action. However, it does not detail other side effects or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and purpose. The second sentence adds valuable behavioral context without redundancy. Every word earns its place.
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 zero-parameter tool with an output schema, this description is complete. It states the tool's primary function (connect and return status) and its key behavioral nuance (approval dialog and token reuse), leaving no major gaps for a simple tool.
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?
The tool has zero parameters, so the baseline is 4. The description adds no parameter information, but none is needed since the schema is empty and there is nothing to explain.
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?
The description uses a specific verb 'Connect' and a resource 'Dorico', and clearly states it returns 'live status'. This distinguishes it from siblings like get_status by emphasizing the connection action and approval flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description mentions the approval dialog on first connection, implying it may be a prerequisite, but does not state when to call it or what happens if not called. No exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the start/stop behavior and maps to the underlying API (Play.StartOrStop / Play.Stop), but it does not disclose any preconditions, side effects, or requirements such as an active connection to Dorico. It does not contradict any annotations because none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with a one-line purpose followed by a parameter explanation. The 'Maps to' line provides useful implementation context without unnecessary length. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values need not be explained. The description covers the tool's purpose and both parameters with accepted values. However, it omits environmental context like whether a connection is required, which might affect usage in a larger workflow. Given the low complexity, this is a minor gap.
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?
The schema has 0% description coverage for parameters, so the description must compensate. It does so by listing the allowed values for action ('play' or 'stop') and explaining the meaning of location with four enum values (kPlayhead, kSelection, kStartOfFlow, kLastStartPosition). This adds meaningful value beyond the bare schema, though it could elaborate on what each location represents.
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?
The description clearly states 'Start or stop playback' with a specific verb and resource. It distinguishes itself from sibling tools like navigate, save, and add_notes by focusing solely on playback control. This is not a tautology but a clear, actionable purpose.
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 provides clear context on how to use the tool, including the two parameters and their allowed values (e.g., action: 'play' or 'stop'). However, it does not explicitly mention when to use this tool over alternatives or any exclusions, so it misses the top score for explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of transparency. It openly discloses the unsupported status and the technical reason (popover action, tonality cannot be transmitted via Remote Control API). This is exemplary honesty about expected behavior, going beyond what annotations might provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the critical unsupported warning, then explains why and gives a parameter example. Every sentence adds necessary information with no fluff, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an unsupported tool, the description covers the main requirements: what it attempts, why it won't work, and the parameter format. It does not describe the return value or error behavior, but given the explicit 'not supported' disclosure, the context is sufficient for an agent to decide not to call it.
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?
The schema has only a 'key' parameter with no description (0% coverage). The description compensates by providing concrete examples ('C major', 'G major', 'F minor') and clarifies the expected format. This adds meaning beyond the bare schema, though it does not explain defaults or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a key signature, but immediately qualifies it as 'NOT yet supported over the API.' This makes the purpose clear but not fully actionable. It does not explicitly differentiate from siblings like set_time_signature beyond noting the unsupported status, so 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns that the tool is not supported, implying 'do not use this to set a key signature.' It draws an analogy to time signature being a popover action, giving context for why it fails. However, it does not suggest any alternative tool or workaround, so it lacks a full when-to-use versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals important traits: start/end move the viewport (not the caret) and 'bar' is unsupported due to an API limitation (Edit.GoTo dialog field). These are meaningful beyond the schema, though additional details like error behavior for 'bar' or return behavior are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured: a short opening line states the purpose, followed by clear parameter definitions and a brief note on limitations. Every sentence contributes useful information with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple navigation tool, the description covers the main caveats (viewport vs caret, bar unsupported). An output schema exists, so return values are covered. It lacks details on error handling for unsupported targets, but given the tool's simplicity, this is sufficient.
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 description coverage is 0%, so the description must compensate. It explains both parameters: target takes 'start', 'end', or 'bar', and bar is a 1-indexed bar number only meaningful with target='bar'. This adds significant meaning beyond the bare schema, though it could be more explicit about the exact behavior of start/end.
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?
The description clearly states the tool's purpose with a specific verb+resource: 'Move around the score.' It distinguishes from sibling tools (like add_notes, transpose, playback) by focusing on navigation, and further specifies it affects the viewport rather than the caret, making its role unambiguous.
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 context on when to use the tool and explicitly excludes the 'bar' target, noting it is not yet supported. It also clarifies that start/end move the viewport, not the caret, which aids decision-making. However, it does not explicitly name alternative tools or provide when-not-to-use guidance beyond the 'bar' limitation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the operation is selection-only, notes the precedence of octave over chromatic, and maps to internal NoteEdit commands. It doesn't discuss permissions or reversibility, but for a simple transpose operation this is reasonable.
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?
The description is front-loaded with the main purpose, followed by a clear Args section and behavioral note. It is a bit longer than necessary due to the internal mapping mention, but every sentence provides useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameters, selection requirement, and parameter precedence. It doesn't explain return values, but an output schema exists, and the tool is simple enough that this is not a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description compensates fully by explaining each parameter: direction ('up' or 'down'), chromatic (chromatic semitone), and octave (whole octave, with precedence). This adds significant meaning beyond the bare 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?
The description clearly states the tool transposes the current selection up or down, using a specific verb and resource. It distinguishes itself from sibling tools like add_notes or set_key_signature, which handle different operations.
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 provides clear context by stating it operates on whatever is selected in Dorico and explicitly instructs to make a selection first. It doesn't mention when not to use it or alternatives, but the selection requirement gives adequate usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description provides key behavioral details: it exits note-input mode cleanly via NoteInputSession even on error, and clarifies that success only indicates command acceptance, not actual note placement, advising verification through get_status/playback.
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?
The description is moderately sized and well-structured, with a clear first sentence and parameter list. Each sentence provides useful information, though slightly verbose for a short tool description.
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?
The description covers purpose, parameters, error behavior, and success semantics, providing sufficient context for a user. The presence of an output schema reduces the need to describe return values, but the description still hints at the output via 'kOK' and advises verification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully explains each parameter: notes format with examples, duration allowed values, and as_chord behavior. This compensates for the schema's lack of descriptions (0% coverage), adding significant meaning beyond the input 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?
The description clearly states the tool's function: 'Input notes at the caret' with a specific verb and resource. It differentiates from siblings like add_rest and transpose by focusing on note input at the caret position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (adding pitches at the caret) but does not explicitly state when to prefer this over alternatives or exclude other tools. It lacks explicit when/when-not guidance, though the purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It adds valuable behavioral context: that an accepted (kOK) response does not guarantee the rest actually landed, urging verification. It also mentions the mode transition (leaves note input), which is useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action and parameter values, followed by a crucial caveat. Every word earns its place; no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter, the description covers the action, allowed values, the caret position, and the mode change, plus a verification warning. It lacks an explicit prerequisite (e.g., must be in note input mode) but that is implied by 'then leave note input'. Given the output schema exists and the tool is small, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single 'duration' parameter, but the description explicitly lists all accepted values (whole, half, quarter, eighth, sixteenth, 32nd, 64th). This fully compensates for the missing schema descriptions and adds meaning beyond the bare property definition.
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?
The description clearly identifies the action (input a rest), the resource (rest), the location (at the caret), and the mode context (note input). It distinguishes itself from sibling tool add_notes by specifying 'rest' versus notes.
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 implies usage in note input mode and states that after inserting the rest, the tool leaves note input. It does not explicitly contrast with add_notes, but the purpose is clear enough that an agent would know when to use this over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently labels the operation as a 'read' and limits its scope to selection-only pushed deltas, which communicates the read-only nature and potential limitations. It also provides examples of included fields, giving the agent a clear picture of what to expect, though it omits details like error behavior or whether the call is purely local.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the first sentence states the core purpose, and the second adds necessary context about scope and content. Every sentence earns its place, with no redundant information or excessive jargon.
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 status-retrieval tool with no parameters and an output schema, the description is complete. It explains the nature of the data (pushed deltas), what it includes (examples), and what it excludes (arbitrary score queries). The output schema handles return-value documentation, so the description need not go further.
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?
The tool has zero parameters, so the schema fully covers the argument space. The description adds no parameter-specific information, which is appropriate given there are none. The baseline for zero-parameter tools is 4, and there is no reason to deviate.
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?
The description clearly states the tool's function with a specific verb ('Return') and resource ('Dorico's current (pushed) application status snapshot'). It also distinguishes from siblings by explicitly noting that this is not an arbitrary query of the score, which is a key differentiator among the other tools.
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 provides clear context on when to use the tool: it returns the merged status deltas Dorico pushes, such as window mode and note-input state. It also implies when not to use it by stating it is not an arbitrary query of the score, but it does not explicitly name alternative tools for score queries. This is strong guidance though slightly implicit regarding alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses that some commands are destructive and require a 'confirm' parameter to authorize, and that the result includes both registry 'status' and Dorico's response. It stops short of detailing all possible side effects or error handling, but the essentials are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by a concise args breakdown and a one-line result note. Every sentence earns its place: examples, the destructive-confirm behavior, and the discovery resource are all covered without unnecessary padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (so return details aren't the description's job), the description is sufficient for a generic command runner. It explains how to find valid commands and how to confirm destructive actions. It could optionally mention error behavior or the fact that some commands may require prior setup, but overall it's complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema only provides names/types, the description adds critical meaning: command_id gets concrete examples ('Edit.SelectAll', 'NoteInput.SetArticulation'), and params are explained with usage syntax ('{"confirm": true, …}') plus a note that parameter names match the catalog. This goes far beyond the raw schema and actually compensates for the 0% 'schema coverage' signal.
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?
The description clearly states a specific action: 'Run any catalogued Dorico command by id' and positions it as 'the escape hatch for the long tail,' which distinguishes it from the specific-purpose sibling tools like add_notes or transpose. The verb 'run' plus the resource 'catalogued command' makes the purpose unambiguous.
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 phrase 'escape hatch for the long tail' implies this tool is for commands not covered by dedicated sibling tools, providing clear usage context. It also points to a discovery resource ('dorico://commands') for valid ids, but it does not explicitly state when to avoid using it or mention alternative tools by name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![dorico-maestro MCP server](https://glama.ai/mcp/servers/romanstark/dorico-maestro/badges/card.svg)](https://glama.ai/mcp/servers/romanstark/dorico-maestro)

Score Badge

Copy to your README.md:

[![dorico-maestro MCP server](https://glama.ai/mcp/servers/romanstark/dorico-maestro/badges/score.svg)](https://glama.ai/mcp/servers/romanstark/dorico-maestro)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/romanstark/dorico-maestro'

If you have feedback or need assistance with the MCP directory API, please join our Discord server