Skip to main content
Glama
wegitor
by wegitor

add_midi_note

Insert a MIDI note into a specific track and item in REAPER, with precise control over pitch, start position (time or measure), length, and velocity. Supports absolute or item-relative timing.

Instructions

Add a MIDI note to a MIDI item. Reaper format 2.1.00 should be converted to 2:1,000.

Important: Please check MIDI item length in which you want to add the note. If the note extends beyond the item bounds, create another one or resize existing before note adding. Double-check the item's starting position before adding it. Notes positioned before the item's position won't be added.

Item Identification - TWO ways to specify which item:

  1. Using track_pos_idx (integer):

    • Pass the simple index number from create_midi_item response

    • Example: item=track_pos_idx=0 for first item, item=track_pos_idx=1 for second item

    • Fast and easy but may change if items are reordered

  2. Using direct_item_id (string):

    • Pass the exact string ID from create_midi_item or get_items_in_time_range

    • Example: item=direct_item_id="MediaItem*0x000001234567890A"

    • Stable and reliable, won't change even if items move

The system automatically detects which type you're using.

Note about positioning:

  • start_time and start_measure specify ABSOLUTE position in the project timeline

  • The note will be placed at this absolute position, regardless of item location

  • Example: start_measure="5:1,000" means measure 5 in the project, not 5 measures into the item

Args: track_index: 0-based track index (0 = first track, 1 = second, etc.) Important: REAPER UI displays "Track 1" but API uses index 0. item: EITHER an integer track_pos_idx (0, 1, 2...) OR a string direct_item_id pitch: MIDI note pitch (0-127) start_time: ABSOLUTE start position in seconds in the project timeline (optional if start_measure is provided) start_measure: ABSOLUTE start position as "measure:beat,fraction" in the project timeline (optional if start_time is provided) length_time: Duration in seconds from note start (from start_time or start_measure)(optional if length_measure is provided) length_measure: Duration as "measure:beat,fraction" from note start (e.g., "0:2,000" = 2 beats from start_time or start_measure)(optional if length_time is provided). Also remember 2:0,0 is not end of 2 measure and 3:1,0 should be. velocity: Note velocity (0-127, default: 96) relative_start: If True, start_time/start_measure are interpreted as offsets from the item's start (i.e. relative to item.start). If False (default), they are treated as absolute project positions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemYes
pitchYes
velocityNo
start_timeNo
length_timeNo
track_indexYes
start_measureNo
length_measureNo
relative_startNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations provided, the description fully carries the burden of behavioral disclosure. It explains important nuances: REAPER format conversion, notes positioned before the item won't be added, and the critical distinction between absolute and relative positioning. It also documents that item identification can be unstable with track_pos_idx but stable with direct_item_id, providing essential behavioral expectations.

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 long but well-structured with sections, headers, and bullet points. It uses clear formatting to separate the item identification method from positioning notes. While some sentences could be tightened (e.g., the 'Important' paragraph repeats some content), the detail is mostly necessary given the complexity of the tool. It is appropriately front-loaded with the core purpose and critical warnings.

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 tool with 9 parameters, no schema descriptions, and no annotations, the description is remarkably complete. It covers all parameters, edge cases like item bounds, position validation, and format conversion. It even explains the output schema indirectly via the item identification examples. There is no missing information needed for an agent to invoke this tool correctly.

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 input schema has 0% description coverage, so the description must compensate. It does so thoroughly by explaining every parameter: track_index (with UI vs API indexing note), item (both forms), pitch, start_time/start_measure (absolute positioning), length_time/length_measure (with nuance on measure format), velocity, and relative_start. It gives concrete examples for ambiguous parameters, making the tool highly usable.

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: 'Add a MIDI note to a MIDI item.' It distinguishes itself from the sibling 'add_midi_notes' (plural) by focusing on adding a single note. The specific verb 'add' and resource 'MIDI note' provide clear 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 gives detailed usage guidance, such as checking item length, ensuring the note doesn't extend beyond item bounds, and verifying item position. It also explains the two methods for identifying the item (track_pos_idx vs direct_item_id). However, it does not explicitly contrast with the sibling tool add_midi_notes, which could create ambiguity about when to use the singular vs plural version.

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