Public MCP and workspace MCP solve different problems

“We have an MCP server” does not say enough.

An agent reading public API documentation and an agent preparing a change inside a private workspace have different identities, permissions, risks, and expected outcomes. Combining both jobs behind one vague endpoint makes the product harder to understand and the security boundary harder to defend.

Doctorine separates them into a public portal MCP surface for published content and an authenticated workspace MCP server for documentation and release changes.

Public MCP reads the published portal

The public portal already contains information a developer may need: authored guides, operation reference, examples, and release-specific context. A public MCP server gives compatible clients a structured way to read that published material.

Its trust model follows the portal. If a page is public, an agent can discover it without receiving access to the private workspace that produced it.

When enabled, the public server can also accept feedback. That creates a reviewable report; it does not edit published content or grant workspace access.

That boundary matters. Public MCP should not:

• edit pages;
• create workspace branches;
• inspect private drafts;
• activate a release;
• inherit an administrator’s platform permissions.

It is a machine-readable doorway into the published product, not a remote control.

Workspace MCP is an authenticated collaborator

The workspace server exists for a different workflow. It uses OAuth and the same project authorization model as the rest of Doctorine. Tools are scoped to documentation and release-change work rather than presented as unrestricted platform administration.

The default change flow looks like this:

1. Resolve the approved project and current branch.
2. Read the page and its revision.
3. Create or select a change branch.
4. Stage the page update against its base revision.
5. Preview and inspect the change.
6. Hand the candidate to the normal review and publication process.

A project can allow selected roles to apply or publish directly. Those calls still recheck authorization, project policy, and the base revision, and record the outcome.

The base revision is not incidental metadata. It gives the publish preflight a merge point and helps the system detect when the page changed underneath an agent’s work.

This is the difference between “an agent can call a write tool” and “an agent can participate in the product’s change model.”

Authentication is only one part of control

OAuth proves who is connecting and which authorization grant applies. It does not remove the need for:

• tenant isolation;
• project-scoped permissions;
• explicit read and write capabilities;
• protected release operations;
• reviewable change state;
• clear tool descriptions and error responses.

The client also matters. Doctorine CLI setup covers Claude Code, Cursor, Windsurf, Gemini CLI, Codex CLI, VS Code/Copilot, Zed, Cline, OpenCode, Grok CLI, and Kimi. Claude Desktop uses its connector interface. Client behavior and OAuth remain client-owned.

MCP does not replace the CLI

There is overlap between tools exposed to an agent and commands exposed to an operator, but the interfaces serve different users.

The Doctorine CLI is designed for explicit local and CI automation. It can authenticate a person or service token, return JSON, use stable exit codes, and operate across the versioned platform API.

Workspace MCP is designed for an approved agent conversation. Its tool surface should be narrower and its context descriptive. Its mutations follow the project’s live edit policy: propose-only by default, with direct apply or publish available only to authorized roles when enabled.

If an automation must run unattended and deterministically in CI, the CLI or API is usually the clearer choice. If a developer wants an agent to understand a guide and prepare an edit under review, MCP is the better fit.

Agent Skills add durable instructions

MCP provides live tools and context. An Agent Skill provides inspectable files that can travel with a repository or agent configuration.

A Doctorine skill package can include:

• SKILL.md as the entry point;
• references for API concepts and workflows;
• recipes for common integration tasks;
• API and provenance material tied to the generated package.

The two products complement each other. The skill teaches a durable method; MCP connects the agent to current published or workspace state.

The test is the boundary

When evaluating an MCP implementation, do not stop at a client screenshot. Ask:

• Can a public visitor read documentation without gaining workspace access?
• Which identity and scopes protect private tools?
• Does a write create reviewable change state or mutate production directly?
• How are concurrent edits detected?
• Which jobs remain better suited to the CLI or API?
• Can the server explain its limits to both the user and the agent?

MCP becomes useful when the boundary is as deliberate as the tool.

Explore public and workspace MCP in Doctorine.