Skip to main content
Glama
wegitor
by wegitor

create_midi_item

Create an empty MIDI item on a REAPER track. Specify its start and length in time or measure terms to prepare a canvas for adding MIDI notes.

Instructions

Create an empty MIDI item on a track.

Important: It is recommended to avoid overlapping MIDI items. Ensure to double-check before creating a new one.

Returns both track_pos_idx and direct_item_id for flexible item referencing:

  • track_pos_idx: 0-based position index within the track (0, 1, 2, etc.)

  • direct_item_id: REAPER's internal item ID (string pointer)

Both can be used interchangeably in subsequent operations like add_midi_note.

Args: track_index: 0-based track index (0 = first track, 1 = second, etc.) Note: REAPER UI shows "Track 1, Track 2" but API uses 0, 1, etc. start_time: Start position in seconds (optional if start_measure is provided) start_measure: Start position as "measure:beat,fraction" (optional if start_time is provided) where fraction is milliseconds (e.g., "1:1,500" = measure 1, beat 1, half beat) length_time: Duration in seconds from start position (from start_time or start_measure)(optional if length_measure is provided). length_measure: Duration as "measure:beat,fraction" from start position (e.g., "2:1,000" = 2 measures from start_time or start_measure)(optional if length_time is provided). The range starts from 0:1,0. The value 0:4,0 equals three beats in a 4/4 time signature. Thus, if you want the length of all beats from one measure, then use 1:1,0; for two measures, use 2:1,0; and for three, use 3:1,0.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
start_timeNo
length_timeNo
track_indexYes
start_measureNo
length_measureNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

With no annotations, the description carries the behavioral burden. It discloses that the tool creates an empty item, returns two referencing mechanisms, and warns about overlapping items. It does not mention undo behavior, auth requirements, or exact behavior if both start_time and start_measure are provided, but the essential side effects are transparent.

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 core purpose, followed by an important warning, return value documentation, and parameter details. It is somewhat long, especially the length_measure explanation, but the complexity of the measure format justifies the length. No content is redundant.

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 five parameters, no annotations, and an output schema, the description covers nearly everything needed: parameter semantics, return values, and a usage caution. A notable gap is that it doesn't state what happens if both start_time and start_measure (or neither) are supplied, since only track_index is required in the schema. Overall, it is complete enough for correct invocation.

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?

Schema description coverage is 0%, so the description must compensate for all parameters. It fully explains track_index (including 0-based vs UI labels), start_time, start_measure (with format 'measure:beat,fraction'), length_time, and length_measure (with detailed examples). This is far beyond what the schema provides.

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 opens with a specific verb and resource: 'Create an empty MIDI item on a track.' This clearly distinguishes the tool from siblings like insert_audio_item, create_track, and add_midi_note, and also explains the returned IDs, reinforcing its 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 usage context: it returns IDs for 'subsequent operations like add_midi_note,' implying this is the first step before adding notes. It also warns against creating overlapping items. However, it does not explicitly name alternatives (e.g., duplicate_item or insert_audio_item) or state when not to use this tool.

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

Install Server

Other Tools

Latest Blog Posts

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/wegitor/reaper-reapy-mcp'

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