Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@reaper-dev-mcp What does the ReaScript function reaper.TrackFX_GetParam do?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP (Model Context Protocol) server providing reference documentation for REAPER development, ReaScript API, JSFX programming, and ReaWrap API.
This server provides static reference documentation that serves as a lookup reference for factual information about REAPER development. It helps prevent "token burn" by avoiding the need to rediscover common patterns and pitfalls in every session.
Related MCP server: SJ RedM MCP Server
Queryable API Documentation: Use tools to search and get detailed function information
JSFX Fundamentals: Core concepts and gotchas
ReaScript API: Complete function reference with signatures and parameters (2,282 functions across C, EEL2, Lua, Python)
ReaWrap API: Object-oriented wrapper documentation (14 classes, 736 methods)
Choose your IDE and follow the instructions:
Claude Code CLI - Recommended, easiest setup
Cursor IDE - Works with stdio or HTTP
Claude Desktop - Requires HTTP server
Prerequisites: Node.js v18+
Installation (one command):
claude mcp add --transport stdio --scope user reaper-dev -- npx -y reaper-dev-mcpVerify it's working:
claude mcp listYou should see: reaper-dev: npx -y reaper-dev-mcp - ✓ Connected
That's it! The server will automatically start when Claude Code needs it. Restart your Claude Code session to use the tools.
Cursor supports both stdio and HTTP transports. Stdio is recommended (no background process needed).
Prerequisites: Node.js v18+
Open Cursor settings:
macOS/Linux: ~/.cursor/mcp.json
Windows: %APPDATA%\Cursor\mcp.json
Add this configuration:
{
"mcpServers": {
"reaper-dev": {
"command": "npx",
"args": ["-y", "reaper-dev-mcp"]
}
}
}Restart Cursor
That's it! Cursor will spawn the server automatically when needed.
If you prefer HTTP (or stdio doesn't work), use this method:
Start the server in a terminal (keep it running):
npx -y reaper-dev-mcpThe server will start on http://localhost:3000. For a custom port:
PORT=8080 npx -y reaper-dev-mcpOpen Cursor settings and add:
{
"mcpServers": {
"reaper-dev": {
"type": "sse",
"url": "http://localhost:3000"
}
}
}Restart Cursor
Note: The server must be running before Cursor starts.
Claude Desktop requires HTTP/SSE transport.
Prerequisites: Node.js v18+
Start the server in a terminal (keep it running):
npx -y reaper-dev-mcpThe server will start on http://localhost:3000. For a custom port:
PORT=8080 npx -y reaper-dev-mcpConfigure Claude Desktop:
Locate your config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
Add this configuration:
{
"mcpServers": {
"reaper-dev": {
"type": "sse",
"url": "http://localhost:3000"
}
}
}Restart Claude Desktop
Note: The server must be running before Claude Desktop starts.
If you want to modify the server or contribute:
git clone https://github.com/Conceptual-Machines/reaper-dev-mcp.git
cd reaper-dev-mcp
npm install
npm run buildRun in development mode:
npm run devRun tests:
npm run testget_function_infoGet detailed information about a function from JSFX, ReaScript, or ReaWrap API.
Parameters:
api (string): One of "jsfx", "reascript", "reawrap"
function_name (string): Name of the function to look up
class_name (string, optional): Required for ReaWrap API queries
Examples:
// JSFX
{
"api": "jsfx",
"function_name": "sin"
}
// ReaScript
{
"api": "reascript",
"function_name": "TrackFX_GetParam"
}
// ReaWrap
{
"api": "reawrap",
"class_name": "track",
"function_name": "add_fx_by_name"
}search_functionsSearch for functions across JSFX, ReaScript, or ReaWrap APIs.
Parameters:
api (string): One of "jsfx", "reascript", "reawrap"
query (string): Search query (function name, description, etc.)
limit (number, optional): Maximum number of results (default: 10)
Examples:
{
"api": "reawrap",
"query": "create",
"limit": 5
}All documentation is available as MCP resources:
reascript://jsfx-fundamentals - Core JSFX concepts
reascript://parameter-system - REAPER parameter system
reascript://parameter-modulation - Parameter linking (plink API)
reascript://fx-containers - FX container system
reascript://reawrap-api - ReaWrap API reference
The MCP server provides access to:
JSFX API: 110 functions from official REAPER documentation
ReaScript API: 2,282 functions organized by language (C, EEL2, Lua, Python)
ReaWrap API: 14 classes with 736 methods
✅ No More Token Burn: Stop rediscovering JSFX parameter indexing every session
✅ Fast Problem Solving: Quick lookup for plink API, container indices
✅ Prevent Regressions: Document all bugs so they're never repeated
✅ Reusable Knowledge: Can be used across all REAPER projects
MIT
Get detailed information about a function from JSFX, ReaScript, or ReaWrap API
| Name | Required | Description | Default |
|---|---|---|---|
| api | Yes | Which API to query | |
| class_name | No | Class name (required for ReaWrap) | |
| function_name | Yes | Name of the function to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get detailed information' without defining what information is returned, whether this is a safe read-only operation, or any requirements or error conditions. It does not contradict any annotations, but it adds essentially no behavioral context beyond the tool's name.
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 a single sentence with no filler. It front-loads the verb and object, then scopes the API set. Every word contributes meaning, and there is no redundant information.
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?
With no annotations and no output schema, the description is too vague to be fully useful. 'Detailed information' does not say what details are returned (signatures, docs, examples, etc.), and the class_name condition is left to the schema. The description also fails to explain how this tool relates to search_functions, leaving an agent to infer the correct choice.
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?
Schema description coverage is 100%, so the baseline is 3. The description echoes the api enum values by naming JSFX, ReaScript, and ReaWrap, but it adds nothing about function_name or class_name beyond what the schema already provides. No extra semantic detail is offered for any parameter.
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 states a specific verb ('Get detailed information') and resource ('a function'), scoped to three explicitly named APIs: JSFX, ReaScript, and ReaWrap. This clearly identifies the operation and distinguishes it from the sibling tool search_functions, which implies searching rather than retrieving details for a known function.
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?
There is no guidance on when to use this tool versus search_functions. The description does not say 'use this when you already know the function name' or mention that class_name is required for ReaWrap. These important conditions are only present in the schema, and no exclusions or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for functions across JSFX, ReaScript, or ReaWrap APIs
| Name | Required | Description | Default |
|---|---|---|---|
| api | Yes | Which API to search | |
| limit | No | Maximum number of results (default: 10) | |
| query | Yes | Search query (function name, description, etc.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It only states the action and does not mention return format, result limits, ordering, or whether results are aggregated or API-specific. This is a minimal disclosure.
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 a single short sentence that front-loads the verb and object with no filler. It earns its place as a purpose statement, though it sacrifices informative richness for brevity.
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 simple three-parameter search tool, the description leaves notable gaps: no distinction from get_function_info, no mention of what the results look like, and no indication of whether it searches one API at a time (per the schema) or across all simultaneously. The missing return-value information is especially relevant since there is no output schema.
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?
Schema description coverage is 100%, so the baseline is 3. The description's mention of the API names merely restates the schema enum and adds no additional semantic meaning beyond what the parameter descriptions already provide.
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 states a clear verb ('Search') and resource ('functions') across three named APIs that match the schema enum. It is unambiguous about what the tool does, though it does not explicitly contrast itself with the sibling get_function_info, so it stops short of a 5.
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 given on when to use this tool versus get_function_info, nor are there exclusions or alternative suggestions. The only implied usage is that it searches broadly across APIs, which is insufficient for routing an agent to the correct sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.6get_function_infosearch_functionsScored across 2 tools
The two tools have clearly distinct purposes: search_functions is for discovery/listing matching functions, while get_function_info retrieves detailed information about a specific known function. There is no overlapping functionality or ambiguity.
Both tool names follow the same verb_noun pattern: search_functions and get_function_info. The naming is predictable and consistent, making the tool surface easy to understand.
With only 2 tools, the server feels slightly thin, but it is focused on a narrow read-only domain (API function reference lookup). The count is borderline but not unreasonable for the stated purpose.
The domain is a read-only API reference for REAPER development. Search and get-info provide a complete workflow: discover functions through search, then retrieve detailed info. There are no missing CRUD operations or obvious dead ends.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
The documentation, as a tool your agent can call: 950+ AI-dev guides. Search + fetch tools.
Doc search, intent & cross-chain swaps, limit orders, portfolio, spot prices, gas & all APIs.
Versioned documentation registry and semantic search for AI tools and coding assistants.
