The Model Context Protocol shipped in November 2024. Within six months, every workspace tool you've heard of had an MCP server. Notion shipped one. Linear shipped one. Airtable shipped one. Asana shipped one. Even Google Workspace got the treatment.
If you ranked them by feature parity, they all look pretty similar. List workspaces. Read rows. Append a row. Search. Standard CRUD over JSON-RPC.
If you rank them by what an agent actually needs to do real work without breaking your trust in your data, the differences are enormous. And they all share one root cause: every one of those products was a human-first workspace before it was an agent-readable one. The MCP server was bolted on later, on top of an access model that had no concept of an agent as a first-class actor.
Dock was built MCP-first from day one. This piece is about what that actually means and the four places it shows up in practice.
What "MCP-first" actually means
The shorthand is easy. The substance is in four design decisions that you make differently when an agent is the primary user instead of a courtesy add-on.
Decision one: who can do what. In a human-first workspace, the access grid is people. Editor, commenter, viewer. When you bolt MCP on, the agent borrows a human's identity (usually the human who installed the connector). Every action the agent takes attributes to that human. The audit trail says "Govind deleted 47 rows" when actually Argus did. There is no mechanism to say "this agent can read but not delete" because the role grid was designed for humans who don't accidentally delete 47 rows when given the chance.
In Dock, agents are first-class principals. Each agent has its own identity (Agent row in the schema, with a required ownerUserId for accountability). Each agent gets its own API keys. Each agent has its own role on each workspace, drawn from the same role grid as humans. When Argus deletes 47 rows, the audit log says Argus deleted 47 rows, with full attribution from row-creation event to undo trail.
Decision two: dangerous operations. The MCP-bolted-on model treats every tool call the same. Listing rows and upgrading the org's plan from Pro to Scale are both just tools/call invocations. The first call wins; there is no checkpoint. If the agent decides to call upgrade_plan because it misread your intent, you find out from the Stripe email an hour later.
In Dock, tools that move money or widen access permanently are gated through a two-call confirmation handshake. The first call returns a confirm_token plus a human-readable summary. The agent surfaces the summary to its user. The user says yes. The agent calls a second time with the token. Single-use, 60-second TTL, bound to the exact parameters. We didn't invent this pattern; it's how OAuth's authorization-code flow works for the same reason. We made it the standard for MCP tools that touch billing or expand permissions, then we built the canonical implementation as a library other tools can call into (src/lib/billing-consent.ts).
Decision three: agents reacting to humans, not just the other way around. Most workspace MCPs are read-write tool surfaces. An agent calls in, the agent gets a response. There is no path for an agent to react to a human edit in real time.
Dock ships webhooks for every state change: row.created, row.updated, row.deleted, doc.updated, comment.added, member.invited, workspace.archived. Plus an SSE stream for in-process agents that want push updates without webhook plumbing. The result is that Dock is the first workspace where the agent doesn't have to poll. When a human leaves a comment on a doc paragraph, the agent gets a webhook with the comment + the surrounding context, and can reply or take action immediately. We use this internally to wire up agents that respond to @mention notifications in real time, without the agent ever opening a polling loop.
Decision four: the protocol shape itself. A workspace that bolted MCP on top of an existing REST API tends to expose the REST shape one-to-one as MCP tools. That gets you ~15 tools that look like wrapped REST handlers.
We started with the question "what does an agent need to do an end-to-end job in a Dock workspace" and worked backward to a tool catalog. Today there are 43 tools, including ones the REST API doesn't have a direct equivalent for: move_rows for atomic batch moves across surfaces, validate_doc_markdown for preflight checks before writes, request_revoke_agent_key for cross-agent escalation when an agent spots another misbehaving. The MCP tool catalog isn't a wrapper around REST; it's a separate contract designed for agent-shaped intent.
Why this matters once your agent count goes past one
For one agent on one workspace, none of this is super visible. You install the MCP, the agent reads + writes, things mostly work. The cracks appear at three points.
Two agents on the same workspace. With borrowed-human-identity MCPs, both agents attribute to the same human. You can't tell which agent did what. With Dock, each agent has its own principal id; the activity feed renders an orb-and-name per write so you can see "Argus did the research, Flint drafted the post, Scout pushed the launch." Multi-agent coordination is legible because the shared state is annotated.
Agents in production where money or access is on the line. With ungated MCPs, you eventually have an incident where an agent did something irreversible. The post-mortem is awful because the audit trail is ambiguous. With Dock, dangerous operations are confirmed before they fire, and even then they're attributed cleanly. The post-mortem traces to the specific tool call, the specific principal, the specific consent token.
Cross-org collaboration. When you invite a contractor (or an open-source maintainer, or a partner team) to a workspace and they bring their own agents, MCP-bolted-on tools ask you to either share a credential or do nothing. Dock has signed-agent inheritance: invite the contractor as a workspace member, and their agents in their own org auto-inherit at the contractor's role. Trust flows from the human; the agents follow. When you remove the contractor, their agents lose access in the same atomic transaction.
What this looks like for an agent builder
If you're building an agent today, MCP-first vs MCP-bolted-on changes a few practical things.
You don't have to write a separate "give your agent its own database" layer on top of the workspace tool. The workspace IS the database, with structured rows + rich text + comments + attribution + real-time updates. Most of what teams build into a custom Postgres + Supabase stack to give Claude Code persistent state, you get for free in a Dock workspace.
You don't need to design your own approval flow for dangerous tool calls. The dangerous-ops handshake is already in the protocol. Wrap your money-moving or destructive tools the same way Dock wraps upgrade_plan and you get human-in-the-loop for free without writing a UI.
You don't need to invent your own audit trail. Every write your agent makes carries principalId + principalType. Pull the activity feed, filter by your agent's principal id, and you have the post-hoc accountability story your security team will eventually ask for.
You don't have to teach your agent to poll. Subscribe to the relevant webhooks at registration time and your agent reacts to the workspace's state changes the same way a human teammate sees them in their inbox.
The next thing this enables
The interesting part of MCP-first as a posture isn't what we ship today. It's what becomes obvious as the next thing once the foundation is right.
When agents are first-class principals with their own identities, you can have agents that own workspaces (not just write to them). When dangerous ops are gated by protocol, you can extend the gate to cover any tool a partner ships against the workspace. When webhooks fire on every change, you can have agents that watch each other and report on each other (which is starting to look more important than agents that operate alone).
Every one of those follows from getting the foundation right. None of them is reachable from a human-first workspace with an MCP server bolted on, because the foundation is wrong.
That's what MCP-first means. We made the bet early that if agents were going to be the primary writers in workspaces (and they are), the workspace should be designed around their needs and reuse the human flows on top of that, not the other way around. Two years in, that bet's looking right.