Logic Pro MCP Server for Claude, Cursor, and AI Agents

A local Model Context Protocol (MCP) server that lets Claude Code, Claude Desktop, Cursor, VS Code, and custom AI agents control Logic Pro for AI music production: create tracks, write MIDI, operate transport and mixer state, inspect live project data, and verify results.

Install · Watch demo · What it controls

🏆 Selected for Anthropic's Claude for Open Source program

Logic Pro MCP has been officially selected for Anthropic's Claude for Open Source program — recognition from the makers of Claude that this project is open-source work worth supporting. This server is built with Claude, for Claude-powered agents — and is now officially supported by the program.

An 82 BPM D-minor lofi loop composed live in Logic Pro 12.3 by the MCP — tempo, three MIDI parts, a Drummer, and playback, all from prompts.
▶ Watch the 36-sec demo (with sound)

Logic Pro MCP Server gives Claude, Cursor, and custom AI agents a structured way to control Logic Pro without brittle keyboard macros. Logic Pro does not ship a first-party API for agentic composition, session setup, mixer operations, or live project readback, so Logic Pro MCP fills that gap by combining 7 native macOS control channels behind one MCP interface, then wrapping every high-risk operation in explicit state, confirmation, and verification contracts.

The result is not "screen automation with prompts." It is a structured server for DAW agents: tools mutate, resources read, evidence is labeled, and uncertain outcomes stay uncertain instead of being reported as success.

You: "Make a 4-bar techno loop in A minor at 140 BPM"

MCP client → logic_tracks.record_sequence {
  bar: 1, tempo: 140,
  notes: "45,0,95;57,107,95;45,214,95;..."
}
MCP client → logic_tracks.set_instrument {
  index: 0, path: "Electronic Drums/Roland TR-909"
}

Logic Pro MCP: region imported, instrument routed, readback exposed through resources.

At a Glance

If this project helps you make music with Claude, Cursor, or any MCP client, star the repo. It helps the project reach more Logic Pro users and maintainers.

Want to contribute? Start with the Contributing Guide and the open issues. Many docs, examples, validation tests, and CLI-message improvements do not require Logic Pro.

Why It Exists

Most Logic Pro automation attempts fall into one of three traps:

1. Prompt-only recipes that drift away from the real tool surface.
2. Keyboard macro automation that can click the wrong target and still look successful.
3. Single-channel control that can write to Logic but cannot reliably read what Logic actually did.

Logic Pro MCP uses a different model. It routes each operation to the strongest available channel, exposes live state through MCP resources, and forces callers to handle three outcomes: confirmed, uncertain, or failed.

What It Controls

Agent-Grade Surfaces

Tools are for actions and local artifact checks. The public write surface is intentionally small: logic_transport, logic_tracks, logic_mixer, logic_plugins, logic_midi, logic_edit, logic_navigate, logic_project, and logic_system. logic_audio is read-only and verifies exported files after Logic writes them.

Resources are for state. Clients should read logic://transport/state, logic://tracks, logic://mixer, logic://project/info, logic://project/audit, logic://project/cleanup-plan, logic://midi/ports, and related resources instead of burning tool calls on polling.

Evidence is separated from claims. The README points to release evidence, current-main verification, and live media artifacts instead of implying that a successful command equals a verified Logic state.

Trust Model

• Honest Contract envelopes: mutating operations return State A confirmed, State B uncertain with a reason, or State C failure with an error.
• Verified plugin apply-back: logic_plugins.* uses HC v2 (hc_schema: 2) and returns State A only after project identity, target track, physical insert slot, plugin identity, and readback all agree.
• Fail-closed targets: dangerous mixer, marker, track, MIDI import, and plugin operations require explicit targets and validation.
• Confirmation levels: destructive/project and plugin insertion flows require explicit confirmation metadata before execution.
• Provenance labels: read surfaces expose source, freshness, and evidence labels instead of forcing clients to guess.
• Installer hardening: Homebrew pins SHA256; the shell installer refuses to run without explicit hash/team pins unless same-origin provenance is explicitly allowed.
• Release honesty: published v3.13.0 is the current stable install line, and README claims stay tied to shipped artifacts, release-tree tests, or explicitly linked live evidence.

Quick Start

Prerequisites: macOS 14+ for the MCP server, Logic Pro (latest release prioritized — currently 12.3, which Apple lists as requiring macOS 15.6+; older Logic versions down to the 12.0.1 floor are best-effort), and an MCP client that can launch a stdio server. Published GitHub Actions/Homebrew assets are universal (arm64 + x86_64) and do not require Xcode. Bounce/export uses the bundled native CGEvent helper with no third-party click binary.

Logic Pro version policy. Logic Pro MCP tracks the latest Logic Pro release as its first-class target and validates against it (the strict live E2E runs on Logic Pro 12.3). When Apple ships a new Logic Pro version, supporting it is the top priority — the Accessibility/UI tree shifts between releases, so the newest version is where fixes land first. Older versions above the 12.0.1 floor remain best-effort and may lose parity as those UI surfaces change.

The package manifest uses Swift tools 6.0 for compatibility. Current source verification uses Xcode 16.4 / Swift 6.2 in CI.

The current published stable release is v3.13.0 (2026-07-22 UTC). It ships ADHOC-signed universal artifacts when Apple Developer ID credentials are absent, plus SHA256SUMS.txt and RELEASE-METADATA.json for pinned installs. The runtime surface becomes 10 tools / 18 resources / 12 resource templates — the generated read-only operation catalog logic://system/operations ships as the 12th template. Headlines: the coordinate-free actuation campaign (mute/solo/arm, app-menu items, region selection use AX actions and key commands with observed-effect verification; the external click-tool fallback is retired), consent-gated record-arm key-command auto-setup (system.setup_arm_key), a locale-neutral modal classifier (localized plugin editors and the Drummer Smart Controls pane no longer block unrelated operations, while genuine modals keep blocking), ADR kernel behavior on by default (session-stable target_ref, operation-contract registry with strict params, verified-mutation saga preflight, operation trace), SecureFD-hardened trace-clear/support-bundle paths with a bounded saga lifecycle deadline, and the Homebrew packaging fix restoring bounce/export (logic_variants.py now ships — #427). It keeps the v3.9.0 MCP capability additions (transport.toggle_autopunch, resource subscriptions, workflow prompts, per-tool outputSchema / structuredContent), the v3.9.2 verified-plugin closed-window fix, and v3.10.0 desktop/Creator Studio targeting. The two v3.9.0 live-only surfaces (MIDI export read-back, Channel EQ verified params) remain honestly deferred with spike evidence.

1. Install

brew tap MongLong0214/logic-pro-mcp https://github.com/MongLong0214/logic-pro-mcp
brew trust monglong0214/logic-pro-mcp   # Homebrew 6.0+ requires trusting third-party taps
brew install logic-pro-mcp

The Homebrew formula pins both the release tarball URL and its SHA256; Homebrew itself is a trusted delivery channel with its own signature chain. This is the hardened path for production installs. (On Homebrew older than 6.0 the brew trust step does not exist — skip it.)

For source-tree development, build locally:

git clone https://github.com/MongLong0214/logic-pro-mcp.git
cd logic-pro-mcp
swift build -c release

2. Register with an MCP client

Claude Code:

claude mcp add --scope user logic-pro -- LogicProMCP

Generic MCP client config:

{
  "mcpServers": {
    "logic-pro": {
      "command": "LogicProMCP"
    }
  }
}

If you built from source, point the command at .build/release/LogicProMCP.

3. Complete Logic Pro setup

Run the local checks:

LogicProMCP --check-permissions

Then complete the two Logic-side setup steps in docs/SETUP.md:

• Register the LogicProMCP-MCU-Internal MCU control surface.
• Add the bundled Scripter insert if you need plugin-parameter writes.

Logic 12.2+ does not auto-import the legacy Key Commands plist; the bundled preset is staged as a Manual MIDI Learn reference.

4. Test from your agent

Ask the client:

Check Logic Pro MCP health and show all ready channels.

Expected: all 7 channels ready after full setup, or 5 if you intentionally skipped Key Commands and Scripter.

Pinned shell installer

The installer is fail-closed: it refuses to run without explicit LOGIC_PRO_MCP_SHA256 + LOGIC_PRO_MCP_TEAM_ID env pins. It verifies the downloaded LogicProMCP-macOS-universal.tar.gz archive, so copy the SHA from that archive entry in the release's SHA256SUMS.txt:

curl -fsSL https://raw.githubusercontent.com/MongLong0214/logic-pro-mcp/v3.13.0/Scripts/install.sh -o install.sh
# inspect install.sh, then:
LOGIC_PRO_MCP_SHA256=<paste LogicProMCP-macOS-universal.tar.gz SHA256SUMS entry> \
LOGIC_PRO_MCP_TEAM_ID=<paste team_id from RELEASE-METADATA.json> \
bash install.sh

If you knowingly accept same-origin provenance (hash + Team ID fetched from the same release as the binary), opt in explicitly:

LOGIC_PRO_MCP_ALLOW_SAME_ORIGIN=1 \
bash <(curl -fsSL https://raw.githubusercontent.com/MongLong0214/logic-pro-mcp/v3.13.0/Scripts/install.sh)

See SECURITY.md §Installer trust model for the trust tiers and threat model.

Setup Doctor

Getting an agent to reliably drive Logic Pro is mostly a permissions-and-environment problem: TCC grants, the right Logic version, a live document, a registered control surface, no blocking modal. LogicProMCP doctor is a first-class, intent-aware readiness platform built for exactly this — not a boolean "is it installed" check, but a diagnostic that tells you which capabilities are ready, which are blocked, why, and what to do next — and never reports green for something it could not actually verify.

LogicProMCP doctor                 # human-readable report, color when a TTY
LogicProMCP doctor --json          # stable machine contract (schema logic_pro_mcp_doctor.v4)
LogicProMCP doctor --strict        # exit code encodes overall status (CI gate)
LogicProMCP doctor --profile core --client claude-desktop
LogicProMCP doctor --check-updates # opt-in: also checks for a newer release

Intent-aware profiles. You are not forced through checks you'll never use. --profile scopes the required set to how you actually drive Logic — core (transport/tracks/AX), mixer, keycmd, legacy-scripter, or full. --client (claude-code, claude-desktop, cursor, vscode, terminal, custom) adds the registration checks that matter for that host. Aggregate status is scoped to the selected profile's required checks, so an MCU-only workflow isn't marked unhealthy for a Scripter gap it will never hit.

Capability readiness, not just check pass/fail. Every check is mapped to the capabilities it gates (track_management, midi_import, mixer_ax, mixer_mcu, keycmd_only_ops, verified_plugin_applyback, project_lifecycle, …). The report tells you "MIDI import is ready; verified-plugin apply-back is blocked by PostEvent" — the language an agent (or an operator) can act on directly.

Causal chain — fix_plan and blocked_by. Failures are ordered into a fix_plan (the next actions, most-unblocking first), and each downstream check names the upstream check that blocked_by it — so you fix the root, not the symptom. The headline restates the single next action.

Honesty is the whole point. A check that could not run (missing capability, unreadable TCC db) is reported as an explicit skipped with a reason — it is never silently folded into a pass. Intentional skips (--skip-channel <MIDIKeyCommands|Scripter> with an optional --skip-note, e.g. you deliberately didn't register Scripter) are recorded and excluded from readiness without faking green. TCC findings are redacted to service/principal/state summaries — no raw local paths in the report.

Permission surface it verifies. --check-permissions folds the four TCC grants a real agent needs and exits non-zero if any is missing: Accessibility, Automation → Logic Pro, Automation → System Events (a separate target — Logic being granted does not imply it), and PostEvent (Input Monitoring, required by the CGEvent bounce/click fallback). The doctor treats these as distinct capabilities because they fail independently: e.g. a -1743 / errAEEventNotPermitted from System Events is a launcher-permission gap (the process responsible for launching the server is denied Automation → System Events), reported as such with the exact fix — not misattributed to Logic.

Strict exit codes (--strict, for CI/agent gating): 0 ok · 1 failed · 2 manual_action_required · 3 degraded. Codes 2/3 are status codes, not usage errors, and sit below the sysexits.h range.

A real (redacted) run on a box mid-setup:

{
  "schema": "logic_pro_mcp_doctor.v4",
  "doctor_profile": "core",
  "status": "failed",
  "headline": "Next action [permissions.accessibility]: Accessibility permission is not granted",
  "fix_plan": ["permissions.accessibility", "permissions.post_event_access", "install.binary_inventory"],
  "summary": { "total": 26, "passed": 15, "warnings": 1, "failed": 2, "skipped": 8, "manual": 0, "duration_ms": 333 },
  "checks": [ { "id": "binary.path", "status": "pass", "category": "installation", "severity": "info" } /* … */ ]
}

The same run in a terminal prints a grouped, color-coded report with per-check remediation anchors into docs/SETUP.md. Full flag reference and every check's remediation live in docs/SETUP.md; the --json bytes are a stable contract you can assert against in your own onboarding automation.

Architecture at a Glance

MCP clients launch the Swift stdio server. Dispatchers validate tool parameters, ChannelRouter chooses the strongest available macOS channel, resources expose cached/live state, and high-risk writes return explicit confirmed/uncertain/failed envelopes. The core channels are MCU, Accessibility, AppleScript, CoreMIDI, CGEvent, Scripter, and MIDI Key Commands.

Documentation

The public docs tree is intentionally scoped: setup, API, troubleshooting, README media, plus public issue PRDs/tickets that explain active or shipped user-visible remediation. Historical release notes, internal PRDs, private ticket boards, spike notes, and local live-evidence work files are kept out of docs/; public release history belongs in CHANGELOG.md, GitHub Releases, merged PRs, and issue history.

Status

Published stable: v3.13.0 is available as a GitHub Release and Homebrew install. It carries the accumulated v3.6.0 -> v3.11.0 set, restores Homebrew bounce/export by packaging logic_variants.py with an import-closure release gate (#427), ships the coordinate-free actuation campaign and consent-gated arm auto-setup (#413), fixes localized-editor/Smart-Controls modal misclassification (#381, #405), and turns the ADR-002/003/004/005 kernel behavior on by default with SecureFD/saga hardening (#417, #412). Published metadata remains team_id:"ADHOC" / signing:"adhoc" when Developer ID credentials are absent, with universal x86_64 + arm64 artifacts produced by GitHub Actions.

Previous stable: v3.10.0 remains available as the Creator Studio support release; v3.9.2 remains available as the verified plugin parameter write fix release; v3.9.1 and earlier remain available for pinned installs.

Verification

Live E2E defaults to the release binary. Protocol/security assertions run on any host; Logic/CoreMIDI-dependent checks skip unless a real Logic Pro session is visible. Strict mode converts live-gated skips to failures, treats missing project state as a failed cycle roundtrip precondition, and launches the MCP server under a trusted shell/tmux parent so macOS TCC evaluates the same parent context used by live client flows.

API Contracts That Matter

• Honest Contract envelope — every mutating op returns State A confirmed, State B uncertain with reason, or State C hard failure with error. See docs/API.md.
• HC v2 plugin apply-back — logic_plugins.get_inventory, set_param_verified, and insert_verified add state + hc_schema: 2; State C always carries verified:false, write_attempted, retry safety, and target identity where relevant.
• Fail-closed mutation targets — mixer faders, plugin params, marker delete/rename, track delete/duplicate, and MIDI imports require explicit target parameters.
• Exact-slot plugin insertion — logic_plugins.insert_verified targets the physical insert index returned by get_inventory, verifies the popup is anchored to that slot, and confirms success only by post-write inventory diff.
• Target-faithful navigation — goto_marker returns element_not_found on a cold cache instead of advancing to the next marker.
• 1-based MIDI channel — send_note, send_cc, and record_sequence ch values accept 1..16 to match Logic's UI.
• Bounded raw SysEx — send_sysex rejects payloads over 1024 bytes before CoreMIDI routing.
• Audible-bounce guardrails — record_sequence refuses unverified GM Device / External MIDI imports, logic://project/audit marks External MIDI tracks with MIDI regions as export blockers, and logic_project.bounce refuses those blockers before opening the Bounce dialog.
• Audit phase split — audit logs distinguish rejected calls, confirmation prompts, and executed route invocations.
• Verified project saves — project.save_as verifies the target .logicx package exists and that existing packages advance modification time.
• Live project metadata — logic://project/info promotes live transport tempo/sample-rate when available and falls back per-field to saved project metadata.
• Side-effect-free reads — resources expose state, metadata, and cached inventory without mutating Logic.

Release & Distribution

Stable production tags use the GitHub Actions release workflow. RELEASE-METADATA.json records the exact signing mode, Team ID, and architectures for each artifact. When Developer ID credentials are absent, releases publish ADHOC artifacts with SHA256 metadata and install validation rather than pretending to be notarized.

Per-release detail lives in CHANGELOG.md. Security and installer trust tiers are documented in SECURITY.md.

Registry Metadata

The repository ships server.json for the official MCP Registry metadata path. It is pinned to the current stable release (v3.13.0) and carries discovery tags for Logic Pro, DAW automation, MIDI, Claude/Cursor MCP clients, and music-production agents. The record is metadata-only because the registry package schema does not yet model Homebrew formulas or GitHub release tarballs as first-class package types. The install authority remains the pinned GitHub Release/Homebrew path above.

Known Limitations

• Tempo typing: transport.set_tempo uses bounded coarse and exact AX slider fallbacks when Logic's inline tempo input does not commit, and fails closed if exact readback still cannot be verified.
• MIDI region padding: record_sequence regions start at bar 1 and extend to the target bar using inaudible padding; note timing inside the region is exact, but the region can look longer than the phrase.
• External MIDI bounce readiness: MIDI regions on GM Device / External MIDI tracks are not accepted as audible-bounce evidence by project audit or logic_project.bounce. Move or recreate the material on Software Instrument tracks before claiming a verified Logic Bounce.
• MIDI Key Commands: Logic 12.2 does not accept the legacy .plist Key Commands import; manual MIDI Learn remains required for keycmd-only operations.
• Markers: marker creation uses Logic's native Navigate menu and verifies the Marker List when it is readable. A closed/unreadable Marker List is reported as unreadable or served from the last readable cache instead of being promoted to a verified empty list. rename_marker remains not_implemented.
• Plugin parameter readback: logic_plugins.set_param_verified opens the target insert's plugin window when needed and live-verifies Compressor threshold through that window; arbitrary plugin parameters remain future work and fail closed with unsupported_param_readback.

Development

Source builds require Xcode 16.4+ / Swift 6.2 for the current verified toolchain.

swift test --no-parallel
swift build -c release
python3 -m py_compile Scripts/live-e2e-test.py

For live attestation on a configured Logic Pro host:

LOGIC_PRO_MCP_STRICT_LIVE=1 Scripts/live-e2e-test.sh

License

MIT. See LICENSE.

Contributing

Bug reports, PRs, and feature discussions are welcome. See CONTRIBUTING.md and the open issues for the dev workflow.

Security vulnerabilities: please do not open a public issue. See SECURITY.md for the private disclosure process.