MCP setup

barline’s AI collaborator is external by design. There is no in-app chat: the agent is the MCP client you already use, connected to the same project and audio engine as the Studio.

Connect

The production endpoint is https://barline.dev/mcp.

Codex

codex mcp add barline --url https://barline.dev/mcp
codex mcp login barline

The login command opens the normal barline OAuth consent flow in your browser.

Claude Code

claude mcp add --transport http barline https://barline.dev/mcp

For local development through the Studio worker:

codex mcp add barline --url http://localhost:3000/mcp
codex mcp login barline
claude mcp add --transport http barline http://localhost:3000/mcp

The transport is stateless Streamable HTTP. Every request creates a fresh MCP server, so it does not depend on Worker session affinity.

Inside a saved song, click the MCP light in the Studio header to see these commands and the endpoint for the current origin. A blue light means the Studio tab is ready to receive commands. It does not mean an agent has a permanent connection: MCP is stateless. The panel reports the last command when actual agent activity arrives.

Authentication and scopes

Production uses OAuth 2.1 with dynamic client registration and a browser authorization flow. A call acts as the signed-in user; there is no shared token to paste.

Scopes are independent:

song:read: published source/status, plus member drafts.
song:write: member-only source, project, transport, mixer, history, branch, and publication changes.
asset:read: the caller’s managed asset metadata and library.
asset:write: metadata, pins, derivations, renders, and deletion.

Organization membership remains an additional gate for drafts and mutations. The same rules protect the Studio UI, HTTP API, and MCP tools.

What the client receives

On connection, the server supplies a dense collaborator guide that covers:

the read -> edit -> compile -> hear -> measure loop;
current song structure and authoring conventions;
Source Lens context, Change Request review, and Production Proof;
instruments, effects, presets, packages, regions, assets, vocals, and audio diagnostics;
permission and human-gesture boundaries.

The client can also read:

barline://capabilities for the generated capability contract;
barline://devices and barline://presets for exact production-device truth;
barline://assets for the authenticated production library;
barline://vocal-notebook-schema for lyric/take source conventions;
song://{org}/{slug}/status and song://{org}/{slug}/{+path} for song telemetry and source.

See the complete tool and resource reference.

Browser audio boundary

The browser is the Web Audio engine. Transport, mixer commands, offline measurement, managed renders, freeze, and other audio operations need an open Studio tab for the target song. Tool responses report when no tab received a command instead of pretending it ran.

Local file selection, microphone and device permission, output choice, calibration, monitoring approval, recording arming, and external-return arming stay explicit human gestures. The agent can work with the resulting managed assets and source afterward.

Situated collaboration

get_status.studio tells the agent which canvas is open, which file is active, whether Compose is source-focused, the exact selected range, the primary active playback source, and every simultaneous output-clock playback range. The resolver reports the most specific identity it can prove: note literal, pattern, then section. That lets prompts such as “change this effect” or “what is playing now?” resolve to the same stable source identities used by the editor and visual projections.

Source context is revision-aware. When compiledContextStale is true, the agent must treat semantic metadata as last-good compile evidence and read the current files before editing.