Skip to main content
Glama
Turik1

Morningstar MIDI MCP Server

by Turik1
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Morningstar MIDI MCP Server

A Model Context Protocol (MCP) server for configuring Morningstar Engineering MIDI foot controllers using natural language.

"I have an MC8 Pro and a Quad Cortex Mini. Put the tuner on long press bottom-left."

The server resolves the switch position, looks up the correct MIDI CC from the OpenMIDI database, checks for conflicts, and programs your controller via USB.

Features

  • Configure Morningstar controllers using natural language through Claude

  • 545+ device profiles from OpenMIDI — knows the MIDI implementation of hundreds of pedals, amps, and synths

  • Physical layout mapping — say "bottom-left" instead of memorizing switch letters

  • Conflict detection — warns before overwriting existing presets

  • Supports MC3, MC6 MKII, MC6 Pro, MC8, and MC8 Pro

Related MCP server: rc505mk2-mcp

Tools

  • connect — Find and connect to a Morningstar controller via USB-MIDI

    • port_name (string, optional): MIDI port name. Auto-detects if omitted.

  • get_controller_info — Query controller model, firmware version, and capabilities

  • get_preset — Read the current state of a preset

    • preset (string, required): Switch letter (A–H) or position (top-left, bottom-right, etc.)

  • set_preset_message — Program a MIDI message onto a preset

    • preset (string, required): Switch letter or position

    • action (string, required): press, release, long_press, double_tap, etc.

    • type (string, required): CC or PC

    • cc_number / cc_value (number, optional): CC parameters

    • pc_number (number, optional): Program Change number

    • channel (number, required): MIDI channel (0–15, where 0 = channel 1)

    • slot (number, optional): Message slot 0–15. Auto-assigns if omitted.

    • force (boolean, optional): Overwrite existing message in slot

  • set_preset_name — Rename a preset

    • preset (string, required): Switch letter or position

    • name (string, required): New name

    • name_type (string, optional): short, toggle, or long (default: short)

  • get_bank_name / set_bank_name — Read or rename the current bank

  • lookup_device — Search the OpenMIDI database for a device's MIDI implementation

    • device_name (string, required): Device name (e.g., "Quad Cortex", "Timeline", "HX Stomp")

  • display_message — Show text on the controller's LCD

    • text (string, required): Up to 20 characters

    • duration_ms (number, optional): Display duration in ms (default: 2000)

Installation

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "morningstar": {
      "command": "npx",
      "args": ["-y", "morningstar-midi-mcp"]
    }
  }
}

Claude Code

claude mcp add morningstar-midi-mcp -- npx -y morningstar-midi-mcp

Build from source

git clone --recurse-submodules https://github.com/Turik1/morningstar-midi-mcp.git
cd morningstar-midi-mcp
npm install
npm run build

Setup

1. Connect your controller

Connect your Morningstar controller to your computer via USB. The server auto-detects Morningstar devices.

2. Configure your rig (optional)

Create ~/.config/morningstar-mcp/setup.yaml to save your device setup:

controller: MC8 Pro

devices:
  - name: Quad Cortex Mini
    midi_channel: 1
  - name: Strymon Timeline
    midi_channel: 2

Without this file, you can tell Claude your setup in conversation.

Supported Controllers

Model

Presets

Layout

MC3

3

A B C

MC6 MKII

6

A B C / D E F

MC6 Pro

6

A B C / D E F

MC8

8

A B C D / E F G H

MC8 Pro

8

A B C D / E F G H

How It Works

The server communicates with Morningstar controllers using the SysEx protocol over USB-MIDI. It bundles the OpenMIDI database (maintained by Morningstar Engineering) containing MIDI CC/PC mappings for 545+ devices.

Since the SysEx protocol cannot read preset messages back from the controller, the server maintains a local shadow state at ~/.config/morningstar-mcp/state.json to track what has been written. Changes made outside this tool (e.g., via the Morningstar Web Editor) are not visible.

Development

npm install
npm test          # Run tests (60 tests)
npm run build     # Compile TypeScript

License

MIT

Available Tools

9 tools
connectD
ParametersJSON Schema
NameRequiredDescriptionDefault
port_nameNoMIDI port name. Auto-detects Morningstar if omitted.

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.

display_messageD
ParametersJSON Schema
NameRequiredDescriptionDefault
textYesText to display (max 20 chars)
duration_msNoDuration in ms (default 2000)

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.

get_bank_nameD
ParametersJSON Schema
NameRequiredDescriptionDefault
bankNoBank number (uses current if omitted)

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.

get_controller_infoD
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.

get_presetD
ParametersJSON Schema
NameRequiredDescriptionDefault
presetYesPreset: switch letter (A-H) or position (top-left, bottom-right)

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.

lookup_deviceD
ParametersJSON Schema
NameRequiredDescriptionDefault
device_nameYesDevice name to search (e.g., "Quad Cortex", "Timeline")

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.

set_bank_nameD
ParametersJSON Schema
NameRequiredDescriptionDefault
bankNoBank number (uses current if omitted)
nameYesNew bank name

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.

set_preset_messageD
ParametersJSON Schema
NameRequiredDescriptionDefault
slotNoMessage slot (0-15, auto if omitted)
typeYesMessage type
forceNoOverwrite existing slot
actionYesAction: press, release, long_press, double_tap, etc.
presetYesPreset: switch letter (A-H) or position
toggleNoToggle: pos_1, pos_2, both (default), shift
channelYesMIDI channel (0=ch1)
cc_valueNoCC value (required if type=CC)
cc_numberNoCC number (required if type=CC)
pc_numberNoPC number (required if type=PC)
descriptionNoHuman-readable description

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.

set_preset_nameD
ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesNew name
presetYesPreset identifier
name_typeNoName type (default: short)

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. 9 tool updatesv0.1.0
    • First observedconnect
    • First observeddisplay_message
    • First observedget_bank_name
    • First observedget_controller_info
    • First observedget_preset
    • First observedlookup_device
    • First observedset_bank_name
    • First observedset_preset_message
    • First observedset_preset_name
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.1/5.0

Scored across 9 tools

Disambiguation5/5

Each tool targets a distinct aspect of MIDI control: connection, display, bank/preset manipulation, device lookup, and controller info. Names clearly differentiate their purposes, leaving no ambiguity.

Naming Consistency5/5

All tools follow a consistent snake_case verb_noun pattern (e.g., get_bank_name, set_preset_name). No mixing of styles or irregular naming.

Tool Count5/5

With 9 tools, the set covers core MIDI operations without being bloated. Each tool serves a clear function, appropriate for a dedicated MIDI server.

Completeness4/5

The tool surface covers connection, display, bank/preset CRUD, and device lookup. Minor gaps like listing all presets or deleting presets may exist, but core workflows are complete.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers