Skip to main content
Glama
Sign In
doricomcp

doricomcp

by kulbiq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

delete_events

Delete notes, rests, and markings by event ID in a Dorico score. Use IDs returned by read_music or read_markings to remove unwanted events.

Instructions

Delete events by id: notes, rests or markings (dynamics, hairpins, slurs, text, clefs, octave lines...). Ids come from read_music / read_markings.

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": {
      "event_ids": "<event_ids>"
    },
    "name": "delete_events"
  }
}

Input Schema

NameRequiredDescriptionDefault
flowNo
event_idsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

B3/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden. It says nothing about irreversibility, whether adjacent events shift, what happens with unknown ids, or whether the operation is scoped to a single flow — all material for a destructive mutation.

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 short sentences, front-loaded with the action and followed by the id provenance. The parenthetical enumeration is dense and useful rather than wasteful.

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

Completeness2/5

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

For an unannotated destructive tool with two parameters at 0% schema coverage and no output schema, the definition should at minimum explain the flow parameter and state what deletion affects. It leaves both the parameter gap and the return/confirmation behavior unaddressed.

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

Parameters2/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 well on event_ids (source of ids and the kinds of events addressed) but never mentions the 'flow' parameter at all, leaving one of two parameters entirely unexplained in both schema and prose.

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 names a specific verb (delete) and resource (events by id) and even enumerates the event kinds covered — notes, rests, dynamics, hairpins, slurs, text, clefs, octave lines. The phrase 'by id' implicitly separates it from range- or flow-scoped deleters like delete_range and delete_flow, though it does not name them.

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?

'Ids come from read_music / read_markings' gives the agent a concrete prerequisite workflow and points at two sibling read tools as the id source. There is no guidance on when to prefer delete_range or delete_flow instead, and no warning about preconditions such as selecting a flow.

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