MCP servers

MCP — the Model Context Protocol — is a standard for giving an agent extra tools over HTTP. An MCP server is an HTTPS endpoint that lists the tools it offers and executes them on request. Anyone can run one, which makes MCP the open-ended extension point for Openbook's build agent: if a capability exists behind an MCP server, the agent can use it — once a human has approved it.

This page is about Openbook's agent using somebody else's MCP server. Openbook also is one: every Kanban board is an MCP server your own Claude or ChatGPT can connect to, to write stories and work cards. See Board MCP server.

That last clause is the heart of this page. MCP servers are powerful and third-party, so Openbook wraps them in a consent model where every step that grants capability is taken by a person, never by the agent.

How a server gets in

There are exactly two doors, and they lead to the same review process.

Door 1: a person adds it

In a build room, open MCP in the room's sidebar and add a server:

• a label,
• its HTTPS URL,
• an optional auth header, stored encrypted.

Servers are room-scoped: adding a server to one build room makes it available there, not across the organization.

Only HTTP(S) servers can be added — a local command cannot be accepted. An MCP server is always a remote endpoint Openbook talks to over HTTPS.

Door 2: the agent proposes it

The agent has a propose_mcp_server tool — but that tool only lists the server for human review. It cannot connect anything itself.

This is deliberate. The agent works in contexts full of files and web pages it didn't write. If a malicious page it happens to read says "connect evil-server.com to continue," the worst the agent can do is put evil-server.com on a review list where a human will look at it — and presumably decline. A proposal can never self-approve; no sequence of agent actions leads from "the agent read something" to "the agent has a new tool."

Approval is two-step consent

Approving a server is not one decision but two, and they gate different risks:

1. Approve the server. Openbook contacts the URL and discovers the tools it offers. Approval means "we may talk to this endpoint" — nothing more.
2. Enable tools individually. Every discovered tool starts disabled until a person switches it on.

So even a fully approved server grants the agent nothing by default. You see exactly what the server offers before any of it becomes callable, and you can enable the one tool you wanted while leaving the other nine off.

Two properties keep this trustworthy over time:

• Re-discovery never re-enables a tool you turned off. Refreshing a server's tool list, or the server changing what it offers, cannot silently reverse a decision you made.
• Tool names are namespaced per server. Two servers each offering a search tool don't collide, and a server can't shadow another's tool by copying its name.

Treat tool enablement like granting permissions, because that's what it is. Enable the tools a room's work actually needs, and leave the rest disabled — they'll still be there, visibly listed, if you change your mind.

Operating connected servers

Each connected server shows a status: ok, unreachable, or auth error, with the last error shown so you can tell a dead endpoint from a rejected credential. Refresh re-discovers the server's tools — picking up new ones (disabled, as always) and reflecting removals — without touching your enablement choices.

If a server's credentials rotate, update its auth header; the stored value is encrypted like all connector credentials in Openbook.

Organization-wide oversight

Room-scoping is right for use, but wrong for audit — an owner shouldn't have to visit every room to know what the AI can reach. Organization → MCP solves this: it lists every MCP server across all spaces and rooms, connected and proposed, with approve and remove controls in one place.

Agent proposals float to the top pending approval, so a proposal made in a busy room you never open still lands in front of an administrator. From this one screen an owner can:

• audit every endpoint the organization's agents can currently reach,
• act on pending proposals — approve them into the review flow or dismiss them,
• remove a server everywhere it's connected.

If you administer an organization that uses the build agent, make Organization → MCP a routine check. It is the complete inventory of external MCP surface, and the place where agent-proposed servers wait for a human decision.

The security model, summarized

MCP is where an agent platform is most exposed, so it's worth stating the invariants plainly:

• The agent can propose a server but never connect one.
• A person must approve a server before Openbook contacts it at all.
• Every tool starts disabled; a person must enable each one.
• Turning a tool off is durable — re-discovery cannot undo it.
• Only HTTPS endpoints are accepted; local commands are not.
• Auth headers are stored encrypted.
• The full server inventory, including pending proposals, is visible at Organization → MCP.

Enabled MCP tools then behave like any other agent tools at run time, alongside built-in connectors and custom actions — see Agent integrations for how autonomy modes govern what the agent may do without confirmation.

The other direction

None of the above applies to Openbook's own Board MCP server, because the trust runs the other way: there, your assistant is the client and a board of yours is the server. What gates it is not approval of an endpoint but a token you mint yourself — scoped to one board, read or write, and revocable from the board's Share dialog.