Skip to main content
Glama

mcp_opendaw_reorder_sections

Reorders song sections on the timeline by taking a list of section boundaries and arranging them in a new order, preserving lengths and repositioning notes automatically.

Instructions

Reorder song sections — rearrange blocks on the timeline.

Takes a list of section boundaries and rearranges them into a new order. Each section is defined by its start and end beat. The tool collects all note content from each section, then places them in the specified new order, back-to-back, starting from the first section's original start position.

This is the full song structure editor: instead of swapping two sections (swap_sections), you can completely rearrange the form. Turn verse-chorus-verse-chorus-bridge-chorus into chorus-verse-bridge-chorus-verse-chorus in one call.

section_order: JSON array of section objects, each with "start" and "end" beat positions, listed in the NEW desired order. Example: '[{"start":0,"end":8},{"start":16,"end":24},{"start":8,"end":16}]' This takes sections at [0-8], [16-24], [8-16] and places them in that order, starting at beat 0.

Sections can overlap in the original but not in the output — they are placed sequentially. Section lengths are preserved.

unit_indices: Comma-separated unit indices to process ("" = all units).

Returns sections reordered, notes moved per unit, new section layout.

Example:

Move chorus to front

reorder_sections('[{"start":16,"end":32},{"start":0,"end":8},{"start":8,"end":16}]')

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
unit_indicesNo
section_orderYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations, the description carries the full burden and does an excellent job. It explains the algorithm (collects note content, places in new order, back-to-back, from original start), handles edge cases (overlapping sections are allowed but placed sequentially), and states what is returned. This is far beyond a basic 'reorders sections' statement.

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?

Though the description is longer than typical, every sentence adds value: a one-line summary, behavioral details, parameter explanation with example, and return information. It is well-organized and front-loaded, making it easy for an agent to grasp the essential information quickly.

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?

Despite having an output schema, the description still mentions the return values, and it fully covers the parameter semantics, behavioral rules, and usage context. For a tool with this complexity (full song structure rearrangement), the description is comprehensive and self-sufficient.

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 coverage is 0%, so the description fully compensates by explaining both parameters in detail. It defines section_order as a JSON array with start/end beats, gives an example, and clarifies ordering semantics (sections placed sequentially). It also explains unit_indices and its default behavior ("" = all units).

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 and resource: 'Reorder song sections — rearrange blocks on the timeline.' It also explicitly distinguishes itself from the sibling tool swap_sections, making it clear this is the full structure editor versus a simple swap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance on when to use this tool: 'This is the full song structure editor: instead of swapping two sections (swap_sections), you can completely rearrange the form.' It also includes a concrete example of transforming a song structure, giving the agent clear usage context.

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/ameobius-ai/opendaw-mcp'

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