Skip to main content
Glama
deenesjakoruzh
dschuler36

Reaper MCP Server

by dschuler36
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Reaper MCP Server

Dies ist ein MCP-Server, der Reaper-Projekte mit einem MCP-Client wie Claude Desktop verbindet. Damit kannst du Fragen zu deinen Projekten stellen und erhältst eine umfassende Audio-Analyse als Mixing-Feedback.

Dieser Server ist von Grund auf schreibgeschützt. Er stellt keine Werkzeuge bereit, mit denen eine KI dein Projekt verändern könnte. Er ist dazu da, zu verstehen, was du bereits erstellt hast, und zu lernen, wie du es verbessern kannst. Lass dir von der KI Ideen vorschlagen – du kannst dann selbst an den Reglern drehen und durch Ausprobieren verstehen, wie sich das auf deine Musik auswirkt.

Tools

Projekterkennung & Parsing

  • find_reaper_projects: Findet alle Reaper-Projekte in dem Verzeichnis, das du in der Konfiguration angegeben hast.

  • parse_reaper_project: Parst eine Reaper-Projektdatei (.RPP) und liefert detaillierte Informationen, darunter Tempo, Tracks, FX-Ketten und Audio-Items.

    Jeder Track enthält seine Position und Identität (track_number entsprechend Reapers Anzeigereihenfolge, guid), sein Routing (is_folder/folder_depth, main_send, receives, num_channels, midi_hardware_out) sowie seinen Mixer-Status (volume, pan, mute, solo). Jedes Item enthält position, length, start_offset, playrate, mute, Fades und jeden Take – wobei der aktive Take markiert ist, da dieser abgespielt wird.

    receives-Einträge benennen den Quell-Track per Index und per Namen – genau das unterscheidet einen aktiven Signalweg von einem übrig gebliebenen Track: Ein Track mit main_send: false erreicht den Master nicht, und sein Audio ist nur über das zu hören, was von ihm empfängt.

Diese Werkzeuge arbeiten Hand in Hand. Wenn du Claude eine Frage zu einem bestimmten Reaper-Projekt stellst, verwendet es das Werkzeug find_reaper_projects, um das Projekt zu finden, und anschließend das Werkzeug parse_reaper_project, um das Projekt zu parsen und deine Frage zu beantworten.

Ermittlung installierter FX

  • list_installed_fx(plugin_type=None, search_query=None): Listet alle installierten FX/Plugins auf, die in Reaper verfügbar sind.

    Parameter:

    • plugin_type (optional): Nach Plugin-Typ filtern (VST2, VST3, AU, JS, CLAP)

    • search_query (optional): Plugins nach Name, Hersteller oder Typ durchsuchen

    Rückgabe: Liste der installierten Plugins, einschließlich:

    • Plugin-Name

    • Plugin-Typ (VST2, VST3, AU, JS, CLAP)

    • Dateipfad

    • Hersteller (sofern verfügbar)

    Beispielfragen:

    • „Welche Synth-Plugins habe ich installiert?“

    • „Zeig mir alle meine Waves-Plugins“

    • „Ich suche einen wummernden Synthesizer. Welche Möglichkeiten habe ich mit meinen bereits installierten Plugins?“

    • „Liste alle meine VST3-Plugins auf“

    • „Habe ich irgendwelche Reverb-Plugins?“

    • „Welche iZotope-Plugins habe ich?“

    • „Zeig mir alle meine Audio-Unit-Plugins“

    Hinweis: Dieses Werkzeug durchsucht deine Reaper-Plugin-Cache-Dateien. Wenn du kürzlich neue Plugins installiert und sie in Reaper noch nicht hast scannen lassen, erscheinen sie nicht in den Ergebnissen. Öffne Reaper also zuerst und lass es nach neuen Plugins scannen.

Audio-Analyse

  • analyze_audio_files(project_path, track_filter=None, whole_file=False): Analysiert das Audio in einem Reaper-Projekt, um Mixing-Feedback zu liefern.

    Parameter:

    • project_path (erforderlich): Pfad zur .RPP-Projektdatei

    • track_filter (optional): Tracks nach Namen filtern (z. B. „Vocal“, um nur Gesangs-Tracks zu analysieren)

    • whole_file (optional): Statt nur der Region, die jedes Item abspielt, die gesamten Quelldateien analysieren. Standardmäßig deaktiviert.

    Rückgabe: Umfassende Audio-Analyse, einschließlich:

    • Pegelanalyse: Spitzenpegel, RMS, Clipping-Erkennung, DC-Offset

    • Frequenzanalyse: Spektraler Schwerpunkt und der Anteil jedes Bands an der Gesamtenergie

    • Stereo-Imaging: Stereo-Breite, Phasenkohärenz, Monokompatibilität

    • Dynamikumfang & Lautheit: LUFS (Lautheitsstandards), True Peak, Crestfaktor

    Beispielfragen:

    • „Analysiere das gesamte Audio in meinem Projekt ‚Rock Song‘“

    • „Überprüfe die Gesangs-Tracks auf Clipping“

    • „Ist mein Mix zu laut für Streaming-Plattformen?“

    • „Gibt es Phasenprobleme in meinen Drum-Tracks?“

    Was gemessen wird: Standardmäßig wird jedes Item genau über die Region analysiert, die es abspielt – über seinen Start-Offset in der Quelle, seine Länge und seine Playrate – und nicht über seine gesamte Quelldatei. Unterschiedliche Regionen werden einmal analysiert und wiederverwendet, sodass ein im Arrangement wiederholtes Item nur eine Messung kostet. MIDI-Items haben keine Audioquelle und werden unter skipped aufgeführt, statt als Fehler gemeldet zu werden.

    Frequenzwerte sind relativ. Jedes Band wird als Anteil an der gesamten spektralen Leistung der jeweiligen Region angegeben (derselbe Anteil auch in dB). Die absolute Bandenergie skaliert mit der Cliplänge, wodurch eine lange Datei um dutzende dB „heißer“ wirkt als eine kurze Datei mit identischem Material und ein Vergleich zwischen Dateien sinnlos wird.

    Diese Zahlen stammen aus dem Pre-FX-Signal. Die Analyse liest die Quelldateien von der Festplatte und spiegelt daher weder die FX-Kette des Tracks noch seinen Fader wider. Bei einem Track mit Amp-Simulation oder starkem EQ beschreibt die Analyse das rohe DI-Signal und nicht das, was du hörst. Jede Antwort ist mit signal_stage: pre-fx gekennzeichnet.

    Warnschwellen:

    • Peak > -0.3 dBFS: Clipping-Risiko

    • Clipping erkannt: Digitale Verzerrung vorhanden

    • 200–500 Hz mehr als 10 dB über 500–2000 Hz: Boxige tiefe Mitten. Dass diese beiden Bänder miteinander verglichen werden und nicht ein Band gegen das gesamte Spektrum, verhindert, dass eine Bass-Spur nur deshalb markiert wird, weil sie ein Bass ist.

    • Mittlerer Sample-Wert > 0.001: DC-Offset

    • Phasenkohärenz < 0.5: Probleme durch Phasenauslöschung

    • LUFS > -8: Zu laut für Streaming (Spotify-Zielwert: -14 LUFS)

    • Crestfaktor < 6 dB: Möglicherweise überkomprimiert

    Kann die Lautheit nicht gemessen werden (Regionen kürzer als 400 ms), wird sie als null ausgegeben, anstatt einen Ersatzwert zu verwenden. Regionen unter 50 ms werden zwar gemessen, aber nicht mit Warnungen belegt.

Um alle aus Projekten geparsten Datenstrukturen zu sehen, wirf einen Blick in die Datei src/reaper_mcp_server/reaper_dataclasses.py.

Related MCP server: AbletonMCP

Einrichtung

  1. Abhängigkeiten installieren

    uv venv
source .venv/bin/activate

uv pip install .

  2. Claude Desktop konfigurieren

    • Folge der Anleitung zur Konfiguration von Claude Desktop für die Verwendung mit einem eigenen MCP-Server

    • Die Beispielkonfiguration findest du in setup/claude_desktop_config.json

    • Aktualisiere die folgenden Pfade in der Konfiguration:

      • Den Pfad deiner uv-Installation

      • Dein Reaper-Projektverzeichnis

      • Das Verzeichnis dieses Servers

  3. Starten und Konfigurieren

    • Öffne Claude Desktop

    • Klicke im Chatfeld auf das „+“-Symbol

    • Klicke auf „Connectors“, und du solltest den Connector „reaper“ aktiviert sehen

    Claude Desktop Connectors

  4. Frag drauflos!

    • Stelle Fragen zu deinem Reaper-Projekt

    • Gib immer den Namen des konkreten Reaper-Projekts an, über das du fragst

    • Du kannst die Tool-Boxen aufklappen, um die rohen Projektdaten zu sehen, die an Claude übergeben werden Claude Desktop Tools

Available Tools

4 tools
analyze_audio_filesA

Analyze audio in a Reaper project for mixing feedback.

    Measurements are taken from the source files on disk, so they are
    pre-FX and pre-fader: a track running an amp sim or EQ will sound
    nothing like its analysis.

    Args:
        project_path: Path to .RPP file
        track_filter: Optional substring to filter track names
        whole_file: Analyze entire source files instead of only the region
            each item actually plays. Off by default.

    Returns:
        JSON with per-item analysis, warnings, and skipped items
ParametersJSON Schema
NameRequiredDescriptionDefault
whole_fileNo
project_pathYes
track_filterNo

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description must carry the behavioral burden. It does so by explaining that measurements are taken from source files on disk, hence pre-FX and pre-fader, and that the whole_file parameter changes the analysis scope. It also indicates the return shape (JSON with per-item analysis, warnings, skipped items). This gives an agent a clear sense of what happens when the tool runs, beyond a simple read operation.

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?

The description is well-structured: a one-sentence purpose, a short paragraph clarifying the measurement source, a bulleted Args list, and a Returns line. Every part earns its place, and the most important scoping caveat (pre-FX) is front-loaded. It is detailed without being verbose.

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?

For a moderately complex analysis tool with no output schema, the description covers the purpose, all parameters, and the essential behavioral context. It hints at the return structure but does not specify the exact fields within the per-item analysis (e.g., peak, RMS). This is a minor gap; the description is otherwise sufficient for an agent to call it 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?

Schema description coverage is 0%, but the description's Args section fully compensates. It explains each parameter: project_path ('Path to .RPP file'), track_filter ('Optional substring to filter track names'), and whole_file ('Analyze entire source files instead of only the region each item actually plays. Off by default.'). This is thorough, clear, and adds semantic meaning the schema lacks.

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 clear verb-resource combination: 'Analyze audio in a Reaper project for mixing feedback.' This directly distinguishes it from siblings like find_reaper_projects (finding projects), parse_reaper_project (parsing structure), and list_installed_fx (listing FX). The purpose is specific and actionable.

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

Usage Guidelines2/5

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

The description provides no explicit when-to-use guidance or alternative routing. It does not mention that for project structure one should use parse_reaper_project, or that for finding projects one should use find_reaper_projects. The pre-FX note implies a constraint but does not state 'use this when you need pre-FX analysis' or list alternatives. This leaves the agent to infer when to select this tool.

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

find_reaper_projectsD
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list_installed_fxA

List all installed FX/plugins available in Reaper.

    Args:
        plugin_type: Optional filter by plugin type (VST2, VST3, AU, JS, CLAP)
        search_query: Optional search query to filter by name, manufacturer, or type

    Returns:
        JSON with list of installed plugins including name, type, path, and manufacturer
ParametersJSON Schema
NameRequiredDescriptionDefault
plugin_typeNo
search_queryNo

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the return JSON structure (name, type, path, manufacturer), which is useful, but it does not state that the operation is read-only, nor does it mention any potential side effects, prerequisites (e.g., Reaper must be running), or error conditions. For a simple list operation, this is acceptable, but the description could have explicitly stated non-destructiveness and any environment assumptions.

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?

The description is concise and well-structured with a Google-style docstring. The purpose is front-loaded, followed by parameter explanations and return format. Every sentence adds value; there is no fluff or redundancy. It is easy to scan and parse.

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 simple read-only list tool with no output schema and no annotations, the description is complete. It covers the purpose, both parameters with their allowable values, and the return JSON fields. It does not over-explain or omit essential details. The tool's context (installed plugins in Reaper) is adequately covered.

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 schema provides only titles and nullability, with 0% description coverage. The description fully compensates by explaining each parameter: plugin_type restricts to specific types (VST2, VST3, AU, JS, CLAP) and search_query filters by name, manufacturer, or type. This adds clear meaning beyond the raw schema and gives the agent actionable guidance.

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 a specific verb ('List') and resource ('all installed FX/plugins in Reaper'). It is unambiguous and distinct from the sibling tools (find_reaper_projects, parse_reaper_project, analyze_audio_files), which deal with projects and audio analysis rather than plugin discovery. No further clarification needed.

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?

The description implies usage by demonstrating filter options (plugin_type, search_query), but does not explicitly state when to use this tool versus alternatives. Since there are no closely related sibling tools, the lack of explicit routing is not critical, but it still does not offer clear context on when one would invoke this function (e.g., 'Use this to discover available plugins before processing'). It is adequate but not explicit.

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

parse_reaper_projectD
ParametersJSON Schema
NameRequiredDescriptionDefault
project_pathYes

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv0.1.0
    • First observedanalyze_audio_files
    • First observedfind_reaper_projects
    • First observedlist_installed_fx
    • First observedparse_reaper_project
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

C2.8/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: finding projects, parsing a project file, analyzing audio content, and listing installed plugins. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (find_reaper_projects, parse_reaper_project, analyze_audio_files, list_installed_fx). The naming is predictable and uniform.

Tool Count5/5

With only 4 tools, the server is tightly scoped to its apparent focus on Reaper project analysis and audio inspection. Each tool earns its place and the count feels appropriately minimal for the purpose.

Completeness4/5

The tool surface covers the core analysis workflow well: discovering projects, parsing their structure, analyzing audio files, and listing available FX. Minor gaps exist (e.g., no direct tool for editing or rendering), but for an analysis-oriented server the coverage is solid.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches