puppyone as an MCP server: one workspace, every MCP-compatible client

TL;DR

• MCP (Model Context Protocol) is the access protocol. It standardises how an LLM client discovers and calls tools and data sources. Anthropic kicked it off; the open spec lives at modelcontextprotocol.io.
• MCP is not, by itself, the storage / memory / version-control / permission / SaaS-ingestion layer. Plugging in 12 separate MCP servers gives you 12 islands. None of them survive across hosts, none version-control writes, few have per-agent identity.
• puppyone exposes a single MCP server that is the workspace, not just a tool. A versioned, multi-tenant file workspace with per-agent Access Points, SaaS connectors, automatic commits — accessible to every MCP-compatible client (Claude Code, Cursor, Continue, your own MCP host) through one config.
• The pattern: MCP is how the agent gets in; puppyone is what's inside.

What changes when puppyone is the MCP server

Most MCP servers expose a specific tool: search Notion, query Postgres, call Linear. Useful, but each is its own island. The agent ends up with a long tool list of disconnected services, no shared state between them, and no place to write durable artefacts.

puppyone exposes something different: a single MCP server that is a workspace. Through one MCP connection your agent gets:

• A real, navigable filesystem. list_directory, read_file, write_file, search — primitives an LLM already understands. Not a custom schema per service.
• All your SaaS data already inside that filesystem. Notion pages under /integrations/notion/, Slack threads under /integrations/slack/, Postgres slices under /integrations/postgres/ — all materialised as files, refreshed on a schedule. The agent doesn't need to know each individual MCP server.
• Per-agent Access Points. Each MCP client connecting to puppyone uses its own token with explicit read/write path scopes. Claude Code reads /specs, writes /scratch/claude-code; Cursor reads /specs, writes /scratch/cursor. Same workspace, different scopes.
• Automatic version history. Every write through MCP is a commit with author, timestamp, diff. Rollback is a tool call.
• The same workspace from every MCP-compatible host. Claude Code, Cursor, Continue, your own MCP host — all see the same files. No per-host memory islands.

You don't have to pick "MCP server for Notion" + "MCP server for Slack" + "MCP server for files" + "MCP server for Postgres". puppyone bundles all of that into one workspace, accessed through one MCP server, while still delegating to upstream sources via connectors.

What stays exactly the same

• MCP itself stays the standard interface. We follow the spec; nothing proprietary.
• Other MCP servers keep working. You can run puppyone alongside any tool-specific MCP server; they're not exclusive.
• Your agent code, host config, and MCP client of choice are unchanged. We're just one of the MCP servers in your config — albeit a fairly central one.

How to wire puppyone's MCP server up

1. Spin up a puppyone workspace. Cloud (try.puppyone.ai) or self-hosted Docker.
2. Create an Access Point with the path scopes the agent should have (e.g. read /specs, read /research, read /integrations, read+write /scratch/<your-agent>).
3. Get the MCP endpoint URL + token for that Access Point. (Stable URL, scoped token, revocable any time.)
4. Add it to your MCP client's config. For Claude Code, Cursor, Continue, or any MCP-compatible host, this is one entry under mcpServers (or equivalent) — a name, a transport (HTTP / stdio depending on host), and the auth token.
5. The agent now has tools like list_directory, read_file, write_file, search, commit_log, rollback. They behave like a filesystem, because that's what they are.

(See the docs for the exact config snippet per host.)

Patterns that actually work well over MCP

1. MCP as the discovery surface, puppyone as the substrate

Use puppyone's MCP for "here is the workspace this agent operates against". Use other (specific-purpose) MCP servers for actions that don't fit a filesystem — e.g. "send a Slack message", "create a GitHub issue". File reads / writes / search go through puppyone; one-shot actions go through their own MCP servers.

2. Per-agent scoping on top of the same workspace

Most teams have multiple agents (Claude Code, Cursor, custom n8n flows). Give each one its own Access Point against the same puppyone workspace. They share canonical context (/specs, /research) but write into their own scratch areas. No collisions, full audit per agent.

3. Connectors do the SaaS work, MCP exposes the result

You don't need a Notion MCP server and a Slack MCP server and a Postgres MCP server in your agent's tool list. puppyone's connectors materialise those sources as files; your agent calls read_file /integrations/notion/spec.md like any other file.

4. Writes through MCP get versioned automatically

Anything an agent writes through write_file (or any other write tool) becomes a commit. You don't have to teach the agent Git semantics. Roll back via a tool call when needed.

5. Audit and rollback as first-class MCP tools

commit_log and rollback are exposed as tools. So an agent that wrote 30 files this morning and one of them broke things can roll back that one file (or the whole branch) without involving you.

Patterns to avoid

• Don't try to build "puppyone but with my own files" by stitching together generic filesystem MCP servers. A vanilla file MCP server doesn't give you per-agent identity, commit history, or SaaS connectors. You'll end up rebuilding puppyone, badly.
• Don't expose your raw production DB through MCP if you can avoid it. Materialise the slices you want as files in puppyone; expose those. Read-only, scoped, auditable.
• Don't give one MCP token broad access just because it's convenient. Per-agent Access Points are cheap. Use them.
• Don't dump every conversation transcript into puppyone via MCP. Let the agent decide what's worth persisting. Most turns are noise.

How this fits with the rest of your stack

• MCP is the protocol. puppyone is one of the things on the other end of that protocol.
• Claude Code / Cursor / Continue / your own host all speak MCP and all see the same puppyone workspace.
• Tool-specific MCP servers (Linear, Jira, Slack-action, GitHub-action) coexist with puppyone — they're for actions, puppyone is for files.
• Frameworks like LangChain, CrewAI, n8n can also connect to puppyone via REST instead of MCP if that's a better fit for their host environment.

The mental model: MCP is the door, puppyone is the room.

FAQ

Does puppyone require MCP? No — MCP is just one of the access methods. puppyone also exposes Bash, SSH, REST, and sandbox mounts. MCP is the right choice for AI clients that already speak it (Claude Code, Cursor, Continue, custom MCP hosts).

Is puppyone an MCP-only product? No. We're a workspace. MCP is one of several front doors. Same workspace, multiple interfaces.

Can I use puppyone with custom MCP hosts I'm building? Yes. The MCP server is spec-compliant; if your host can connect to any MCP server, it can connect to puppyone.

Does puppyone follow the latest MCP spec? Yes — we track upstream changes. If you're on a recent MCP-capable client, the integration should be turnkey.

What happens if MCP itself evolves? We follow the spec. The workspace, version history, and connectors are independent of any particular access protocol — if MCP changes, the workspace doesn't.

Can I run multiple MCP servers in the same agent client alongside puppyone? Yes. They're additive. Your agent can have a Linear MCP, a Slack-action MCP, a puppyone workspace MCP, and any others — all available as tools.

TL;DR (again)

MCP is how agents reach in. puppyone is what they reach into. One MCP connection, one workspace, every MCP-compatible host (Claude Code, Cursor, Continue, custom) sees the same persistent, version-controlled, scoped, SaaS-aware filesystem. That's the integration story.

Make MCP useful: give every agent the same workspace through one server.Get started→