Skip to main content
Glama
README.md
# Claude_AV_MCP

Sandbox for **audio-visual MCP experiments** aimed at technical artists:
Claude builds instruments and visuals and conducts live AV sets across
Ableton Live, Max/MSP and a visual engine (TBD) — first on a MacBook Pro
M5, later on a cheap Linux laptop with an all-open-source stack.

## How it fits together

| Server | Role | Source |
|---|---|---|
| `ableton` | Edit the Live set: tracks, clips, notes, devices, transport | [ahujasid/ableton-mcp](https://github.com/ahujasid/ableton-mcp) (upstream, unchanged) |
| `maxmsp` | Edit Max patches: add/connect objects, read docs | [tiianhk/MaxMSP-MCP-Server](https://github.com/tiianhk/MaxMSP-MCP-Server) (upstream, unchanged) |
| `av-conductor` | Shared scene (energy, section, palette, cues, ramps) → OSC to every program | **this repo**, `src/av_mcp/` |

Upstream servers *author*; the conductor *directs*; beat-accurate sync and
audio reactivity stay in the realtime plane (Ableton Link, OSC between
programs) where Claude never blocks them. Details:
[docs/ARCHITECTURE.md](docs/ARCHITECTURE.md).

## Quick start (Mac)

```bash
# 1. Python env for the conductor (needs uv: https://docs.astral.sh/uv/)
uv sync --extra dev
uv run pytest

# 2. Upstream servers → vendor/ (or symlink your existing clones there)
scripts/fetch_upstream.sh

# 3. Watch the conductor's output with no apps running
cp config/av.example.toml config/av.toml      # set [targets.monitor] enabled = true
uv run av-osc-monitor --port 7499
```

Then open Claude Code in this folder — `.mcp.json` registers all three
servers. For Claude Desktop, merge
`config/claude_desktop_config.example.json` into its config (absolute paths).

In Max, open `patches/max/av_receiver.maxpat`; in Pd,
`patches/pd/av_receiver.pd`. Try:

> "Set the scene to section intro with energy 0.2, then ramp energy to 1 over 20 seconds."

## Layout

```
src/av_mcp/          av-conductor MCP server (scene, OSC targets, ramps, cues)
config/              av.example.toml (targets/ports/cues), Claude Desktop example
patches/max|pd/      OSC receiver patches → [r av-energy], [r av-section] …
visuals/             visual engine candidates + receiver sketches (TBD)
prompts/             prompt library
docs/                PLAN.md · ARCHITECTURE.md · LINUX_PORT.md
scripts/             fetch_upstream.sh
vendor/              upstream MCP servers (gitignored)
```

## Roadmap

[docs/PLAN.md](docs/PLAN.md): Phase 0 plumbing → 1 audio/control loop →
2 pick the visual engine → 3 performance tooling → 4 Linux port (Pd,
Ardour/SuperCollider, PipeWire, open-source visuals).

## Privacy note

`ableton-mcp` sends anonymous telemetry by default. The configs here set
`ABLETON_MCP_DISABLE_TELEMETRY=true` and `ABLETON_MCP_DISABLE_DATASET=true`.

TDQS

A3.6/5.0

Scored across 7 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: save/recall cues, raw OSC escape, full rebroadcast, state query, scene update, and time-based ramping. No two tools overlap in function or would cause misselection.

Naming Consistency4/5

Names are consistently snake_case and mostly follow a verb_noun pattern (save_cue, recall_cue, send_osc, get_state, set_scene, resend_all). The lone 'ramp' breaks the pattern slightly, but the overall convention is clear.

Tool Count5/5

Seven tools are well-scoped for an AV conductor, covering scene management, cue handling, OSC messaging, and ramping without bloat. Each tool earns its place.

Completeness3/5

Core lifecycle is present (create/read/update for scenes and cues), but notable gaps exist: no tool to delete or overwrite cues explicitly, and no way to cancel or stop an active ramp. These are common AV operations that agents cannot perform directly.

Maintenance

ActivityMaintained
ResponsivenessNo issues