Connect your agent (MCP)

Midstream speaks the Model Context Protocol, so the coding agent you already use can work with your scenes directly — list what a branch captured, launch an instance, read why a deploy failed — without you copying ids between windows.

ConnectCopy Anchor Link

The server is at https://midstream.studio/api/mcp. Add it and your client walks you through signing in:

claude mcp add --transport http midstream https://midstream.studio/api/mcp

Cursor, VS Code and Claude Desktop take the same URL in their own MCP settings.

The first time a client connects, a browser window opens asking you to approve it. Read that screen: it names the app, lists exactly what it will be able to do, and shows where approving sends the app back. If you do not recognise the app or the address, decline — nothing is issued.

You do not need an API key. MCP uses its own sign-in, and the connection carries only the permissions you approved.

What it can doCopy Anchor Link

Two permissions, and you see both on the approval screen.

Read covers your workspaces, projects and scenes; instances and their deploy history; deploy logs and typed errors; comment threads; scene proposals; the audit log; and your webhook endpoints. Signing secrets are never returned.

Write covers the things you would otherwise click: create and deploy an instance, retry a failed deploy, reset an instance, favourite a scene, comment and resolve threads, propose a scene, create and rename a project, re-send a webhook delivery, and change your own notification settings.

What it will ask you about firstCopy Anchor Link

Every tool tells your client what calling it will do — whether it only reads, whether it can be safely repeated, and whether it reaches outside Midstream. Clients use that to decide when to stop and check with you, and these are the ones we mark as worth checking:

• Deploying an instance, and retrying a deploy. Each one boots a real machine and runs your install and start commands. It takes minutes and it costs money.
• Renaming a project. A project's slug is part of the address of every instance link for it, so changing it breaks the links you have already shared — including the ones in old pull requests.
• Resetting an instance. Anyone looking at it right now loses what they were doing.
• Editing a comment. We keep no edit history, so the old text is gone.

Whether your client actually prompts is the client's choice, not ours. Treat it as a seatbelt, not a lock: the real limit on an agent is the permissions you approved, and those are enforced on every call.

Some things you can do in the dashboard are deliberately not available to an agent:

• Creating or revoking API keys, and creating or rotating webhook secrets. Your agent reads text other people wrote — scene names, deploy logs, comment bodies. A tool that mints a credential would turn a malicious string in any of that into a leaked key.
• Deleting anything — folders, comments, scene proposals, webhook endpoints. Nothing on the agent's side can undo a delete.
• Creating or renaming a workspace, and changing who is in it. That is a decision about who can see your data.
• Renaming a folder. A folder's name is the folder path your test passes to midstreamScene(). Renaming it here would be undone by your next CI run, so the name changes in the test file instead.

What it can seeCopy Anchor Link

Exactly what you can see, and nothing else. Every tool runs the same permission checks the dashboard does, so an agent connected as you cannot read a workspace you are not a member of.

The connection is scoped to MCP alone: the credential your client holds does not work against the REST API, so approving "read my scenes" cannot become write access somewhere else.

DisconnectCopy Anchor Link

Remove the connection from your account settings, or from the client:

claude mcp remove midstream

Revoking takes effect on the agent's next call, not when the token would have expired.