Creates a new REAPER project, providing a blank session to start music production, recording, or mixing tasks.
Create a new REAPER project.
Note: REAPER has no API to name a project that has never been saved, so this server
has no way to name one either. The removed name parameter never took effect.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.7.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a useful behavioral note about the inability to name unsaved projects, which goes beyond the destructiveHint annotation. However, it does not explain the destructive nature of creating a new project (e.g., whether it replaces the current project), leaving important side effects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the core action in the first sentence and providing a helpful clarifying note in the second. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool marked destructive, the description does not explain the side effects of creating a new project (e.g., discarding the current one). The absence of an output schema also leaves return behavior unspecified. This is a significant gap for an agent to call it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema is empty, and the description explains why there is no name parameter, adding meaningful context about the parameter's absence. This exceeds the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and resource 'new REAPER project', distinguishing it from sibling tools like create_bus or create_midi_item. The note about naming adds precision without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The only note about the removed name parameter is not usage guidance, and no exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.