Skip to main content
Glama
Sign In
doricomcp

doricomcp

by kulbiq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

run_command

Executes any catalogued Dorico command with parameter validation, optionally selecting an event first so the edit stays in one undo step.

Instructions

Escape hatch: run any catalogued Dorico command ("Namespace.Command?Param=value&..."), validated against the catalogue. With select_event_id the event is selected first in the same undo step.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "command": "<command>"
    },
    "name": "run_command"
  }
}

Input Schema

NameRequiredDescriptionDefault
flowNo
commandYes
select_event_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations supplied, the description carries the full disclosure burden and does add real value: commands are 'validated against the catalogue' (invalid input is rejected) and select_event_id folds selection into 'the same undo step' (a concrete undo-semantics guarantee). It is silent on whether commands may be read-only vs mutating, whether execution can be rolled back, error behavior, and what is returned, which leaves significant gaps for an unannotated execution tool.

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?

Two tight sentences, the escape-hatch framing and command format front-loaded, with the select_event_id caveat appended only after the core purpose. No redundant restatement of the name or schema.

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?

There is no output schema and no annotations, so the description is the only behavioral source; it covers the essential invocation contract (command syntax, validation, event-selection/undo coupling) but omits the third parameter and any statement of side effects or return values. Adequate to call the tool, not complete for an unannotated mutation-capable executor.

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

Parameters3/5

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

Schema coverage is 0%, so the description must compensate. It does explain the most important parameter by giving the command string grammar and the select_event_id undo-step semantics, but the 'flow' parameter (default 0) is never mentioned and no parameter is described beyond those two behaviors.

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

Purpose5/5

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

States a specific verb and resource ('run any catalogued Dorico command') and frames the tool's role as an 'escape hatch', which tells an agent this is the generic fallback distinct from the many dedicated add_*/delete_* siblings. The inline command format example ('Namespace.Command?Param=value&...') makes the resource concrete rather than abstract.

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?

'Escape hatch' clearly signals fallback usage when no purpose-built tool covers the operation, which is meaningful guidance for a 40+ sibling catalog. It does not, however, name an alternative (e.g. describe_commands) or state an explicit when-not-to-use rule, so the routing is implied rather than spelled out.

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

Deploy Server

Other Tools