Skip to main content
The Model Context Protocol (MCP) is an open standard that lets AI clients read from and write to external context sources through one consistent interface. A service implements the protocol once, and any MCP-capable client, such as Cursor or Claude, can discover and use it without custom integration code. ProductOS uses MCP to expose your project as a live context source — and, beyond context, as a full remote development environment. Instead of pasting your PRD into a chat window and hoping it sticks, you connect the tool once, and it works against the actual product context.

​
What ProductOS exposes over MCP

Your ProductOS project context is available in Cursor and Claude over MCP. That context includes: Because both clients read the same source, whatever you open sees the same requirements and the same constraints. The context is live: changes to the product definition surface in the connected tool instead of going stale.

​
Beyond context: the full tool surface

Context is only part of the connection. The ProductOS MCP server also exposes your project’s cloud sandbox — files, a shell, sandbox lifecycle, databases and storage, GitHub sync, deployments, a headless browser, mobile publishing, and multi-surface Product orchestration. That’s 58 tools, each gated behind the scope you grant the connection (project:read, project:write, or project:exec), so a connected agent can go from reading your spec to editing files, running builds, and shipping to production — all remote, with no local clone. Connected clients also get your skills — the reusable playbooks ProductOS ships (cloning a website, an SEO pass) plus any your workspace defines. They arrive as tools, as /slash commands, and as attachable skill:// resources, so an external agent follows the same playbook the in-app agents do. See the MCP tools reference for the complete list, grouped by category with the scope each tool requires.

​
Why a protocol instead of copy-paste

  • Context, not snapshots. A pasted PRD is a stale copy the moment you paste it. Over MCP, the client reads the current state of your project every time.
  • One source of truth. Cursor and Claude both work from the same shared context, so there is no drift between the tool where you plan and the tool where you code.
  • Bidirectional by design. MCP is a two-way channel. Tools can read your product context and write work back into it, so refinements you make in the editor land where the rest of the pipeline can use them.

​
Connecting a client

The connection flow is the same for any MCP client:
1

Open your ProductOS project

Pick the project whose context you want to expose and open its integration settings to reveal the MCP connection.
2

Add the MCP server to your client

Add the ProductOS MCP endpoint to the client’s MCP configuration (Cursor’s MCP configuration, or Claude’s connector settings) and authorize it.
3

Work against live context

The client now treats your ProductOS project as a context source it can read and write.
Client-specific walkthroughs: Cursor and Claude.
The MCP connection is part of the core ProductOS workflow. You can start free; no paid plan is required to connect Cursor or Claude.

​
MCP and code ownership

MCP handles context; GitHub sync handles code. Whatever a connected tool produces is your code, and the full codebase syncs to your own GitHub repository. Together the two integrations mean neither your product context nor your code is trapped inside ProductOS. See Code ownership.