OpenWork's MCP Sharing Model: How One Agent Connection Becomes a Team-Wide Capability Library

OpenWork positions itself as an open-source alternative to Claude Cowork. The core idea is straightforward: you add one MCP server URL to your agent (Claude Code, Cursor, Codex, or any MCP client), and that connection surfaces every skill, plugin, and service integration your team has provisioned. No per-agent configuration. No credential duplication. One endpoint, many capabilities.

The plumbing question is how a single MCP server multiplexes capabilities, manages per-user versus shared credentials, and enforces access control without forcing each agent to re-authenticate or re-configure.

Architecture: Server-Side MCP with OAuth-Gated Capability Routing

Most MCP servers run locally and expose tools directly to a single agent. OpenWork flips this: the MCP server runs remotely at https://api.openworklabs.com/mcp/agent, and it acts as a capability router rather than a tool executor.

When you add the OpenWork MCP to your agent, the server initiates an OAuth flow. The agent opens a browser window, you sign in, and you select your OpenWork organization. The server issues a token that ties your agent session to your user identity and team memberships.

From that point forward, every MCP tool call includes that token. The server uses it to:

Filter which capabilities appear in search_capabilities results
Enforce team-level access policies when you call execute_capability
Route execution to the correct backend service (a local MCP server, a cloud API, or a shared plugin)

This is multi-tenant MCP. The server does not expose raw tools. It exposes two meta-tools that query and invoke a capability catalog.

Two Tools, Infinite Capabilities

OpenWork’s MCP server exposes exactly two tools:

search_capabilities: Returns a list of capabilities you can use, filtered by your team memberships and access policies.
execute_capability: Runs a specific capability by ID, passing through arguments and returning results.

A capability is a server-side record that points to an execution backend. It might be:

A local MCP server that OpenWork federates (for example, a Postgres MCP running on your machine)
A cloud API with team-shared credentials (Google Workspace, Microsoft 365)
A custom skill or workflow defined in the OpenWork admin interface

When you call execute_capability, the server looks up the capability, checks your permissions, injects the appropriate credentials (user-specific or shared), and forwards the request to the backend. The response flows back through the MCP protocol to your agent.

This indirection layer is the entire value proposition. You define a capability once in the admin interface, assign it to a team, and every agent connected to that team sees it immediately.

OAuth Flow and Token Management

The OAuth flow happens once per agent, not once per capability. Here is the sequence:

Agent connects to https://api.openworklabs.com/mcp/agent
Server responds with an OAuth challenge (a URL and a session ID)
Agent opens the URL in a browser
User signs in and selects an organization
Browser redirects back to the server with an authorization code
Server exchanges the code for a token and associates it with the agent session
Agent stores the token and includes it in every subsequent MCP request

The token encodes user identity, organization ID, and team memberships. The server validates it on every tool call and uses it to filter capabilities and inject credentials.

For shared credentials (like a team Google Workspace service account), the server stores them encrypted and injects them at execution time. For user-specific credentials (like a personal GitHub token), the server prompts the user to authorize the first time they use a capability that requires it.

Admin Interface: Provisioning Capabilities and Policies

OpenWork Den is the control plane. It is a web interface where admins:

Create capabilities by pointing to MCP servers, APIs, or custom workflows
Assign capabilities to teams or individual users
Configure credential sources (shared service accounts, per-user OAuth, API keys)
Set desktop policies (which models members can use, rate limits, audit logging)

When you create a capability, you define:

Name and description: What the capability does
Execution backend: Local MCP server URL, cloud API endpoint, or internal workflow ID
Credential strategy: Shared, per-user, or none
Access control: Which teams or users can see and execute it

The server stores this as a capability record. When an agent calls search_capabilities, the server queries the database, filters by the token’s team memberships, and returns a list of capability IDs, names, and descriptions.

Comparison: Local MCP vs. Federated MCP vs. OpenWork

Dimension	Local MCP	Federated MCP	OpenWork
Configuration	Per-agent JSON file	Shared config repo	Server-side admin UI
Credential management	Local environment variables	Shared secrets manager	OAuth + server-side injection
Access control	None (all tools visible)	Manual (edit config per user)	Team-based policies
Capability discovery	Static tool list	Static tool list	Dynamic, filtered by permissions
Multi-agent consistency	Manual sync	Manual sync	Automatic (single source of truth)

OpenWork trades local control for centralized management. If you run one agent on one machine, local MCP is simpler. If you run multiple agents across a team, OpenWork eliminates configuration drift.

Execution Flow: From Agent to Backend

Here is what happens when an agent executes a capability:

Agent calls search_capabilities with a query string
Server filters capabilities by token, returns matching IDs and metadata
Agent calls execute_capability with a capability ID and arguments
Server validates the token and checks team-level access policies
Server looks up the capability record and retrieves the execution backend
Server injects credentials (shared or per-user) based on the capability’s credential strategy
Server forwards the request to the backend (local MCP, cloud API, or internal workflow)
Backend executes and returns a result
Server forwards the result back to the agent via MCP protocol

The server acts as a reverse proxy with authentication, authorization, and credential injection. The agent never sees the backend URL or credentials. It only sees the capability ID and the result.

Security Boundaries and Failure Modes

OpenWork introduces new security boundaries:

Token leakage: If an agent token leaks, an attacker can execute any capability the token’s user can access. The server should enforce short token lifetimes and refresh flows.
Credential injection bugs: If the server injects the wrong credentials (for example, user A’s token but team B’s service account), you get privilege escalation. The server must validate token-to-credential mappings on every request.
Backend trust: The server trusts execution backends to return safe results. If a federated MCP server is compromised, it can return malicious data that the agent will execute.

Failure modes:

Server downtime: If api.openworklabs.com is unreachable, no agent can execute capabilities. Local MCP servers continue to work, but OpenWork-managed capabilities are unavailable.
OAuth expiration: If the OAuth token expires and the server does not refresh it, the agent loses access. The server should handle refresh flows transparently or prompt the user to re-authenticate.
Capability misconfiguration: If an admin assigns the wrong backend URL or credential strategy, the capability fails at execution time. The server should validate configurations before saving them.

Code Snippet: Adding OpenWork MCP to an Agent

For Claude Code:

claude mcp add --transport http openwork https://api.openworklabs.com/mcp/agent

For OpenCode (add to opencode.json):

{
  "mcp": {
    "openwork": {
      "type": "remote",
      "enabled": true,
      "url": "https://api.openworklabs.com/mcp/agent",
      "oauth": {}
    }
  }
}

For any MCP client that supports remote servers, use the URL https://api.openworklabs.com/mcp/agent. The server handles OAuth negotiation automatically.

Observability and Debugging

OpenWork’s server-side architecture makes observability easier and harder:

Easier:

Centralized logs for all capability executions
Audit trail of who executed what, when
Metrics on capability usage, latency, and error rates

Harder:

Agent-side debugging is opaque (you only see capability IDs, not backend details)
Network failures between server and backend are invisible to the agent
Credential injection bugs are hard to reproduce locally

The admin interface should expose execution logs and error traces. Without them, debugging capability failures requires server access.

Deployment Shape

OpenWork runs as:

Desktop app: Optional. Provides a dedicated workspace UI but is not required to use capabilities.
MCP server: Hosted at api.openworklabs.com. Handles OAuth, capability routing, and credential injection.
Admin interface (Den): Web UI for provisioning capabilities, managing teams, and setting policies.

For self-hosting, you would need to run:

The MCP server (likely a Node.js or Python service)
A database for capability records, user identities, and team memberships
An OAuth provider (or integrate with an existing one)
The admin UI (likely a React or Next.js app)

The repository does not yet include deployment documentation, so self-hosting is speculative. The hosted version is the primary deployment target.

Technical Verdict

Use OpenWork when:

You run multiple agents (Claude Code, Cursor, Codex) across a team and want consistent tool access without duplicating MCP configs.
You need team-level access control and credential management for shared services (Google Workspace, Microsoft 365, internal APIs).
You want a centralized audit trail of agent tool usage.

Avoid OpenWork when:

You run a single agent on a single machine and local MCP configuration is simpler.
You cannot tolerate a dependency on a hosted service (the MCP server is a single point of failure).
You need fine-grained control over credential injection and cannot trust a third-party server to handle it.

OpenWork is the first multi-tenant MCP server architecture I have seen. It solves a real problem (configuration drift across agents and teams) but introduces new operational complexity (server uptime, OAuth flows, credential security). If you are building a team of agents, it is worth evaluating. If you are building a single-user automation, local MCP is still the simpler path.

Agentic AI, minus the noise.