MCPB: One-Click Installation for MCP Servers

Anthropic released MCPB (MCP Bundles), a packaging format that lets you install MCP servers with a single click, similar to how Chrome extensions or VS Code plugins work. No more wrestling with config files or dependency management. It pruports to be a simple way to distribute local MCPs to users.

I recently updated my writing-tools-mcp server to support the format, and the installation experience is genuinely better. But I’m still trying to figure out where this fits in the bigger picture.

What is MCPB?

MCPB is a packaging standard for MCP servers. Think of it like .crx files for Chrome extensions or .vsix files for VS Code. You bundle your server code, dependencies, and a manifest file into a single .mcpb archive. Users double-click to install.

The format has three main components:

Bundle Specification - A manifest.json file that describes your server: name, version, entry point, required configuration, and capabilities. This is the only strictly required component.

CLI Toolchain - Commands like mcpb init and mcpb pack help developers create bundles. The tooling is minimal but functional.

Runtime Code - Implementation used by Claude for macOS and Windows to load, verify, and run bundles.

The archive can include everything your server needs: JavaScript or Python code, bundled dependencies (node_modules, Python packages, compiled binaries), optional assets like icons, and configuration files.

Node.js is the recommended runtime because it ships with Claude Desktop, which means users don’t need to install anything extra. Python servers work too, but require users to have Python installed locally.

My Experience: Adding MCPB Support

I added MCPB packaging to writing-tools-mcp, a server that provides text analysis tools (readability scores, keyword density, spellcheck, AI content detection, etc.). The setup was straightforward.

The build process uses uv to package the Python dependencies and creates a manifest that specifies the entry point and required configuration. Running make build-mcpb generates a writing-tools-mcp.mcpb file that users can install directly into Claude Desktop.

Here’s what the installation looks like:

Once installed, the server shows up in Claude’s MCP configuration automatically:

No editing JSON config files. No hunting for Python paths. No debugging environment variables. It just works.

For developers, this is a significant improvement in distribution. Instead of maintaining installation docs that get out of date, you provide a single file. The host application (Claude Desktop, Cursor, etc.) handles updates, environment variables, and parameter configuration.

Now, I happen to be using uv, so this assumes users already have uv. brew install uv isn’t super hard, but it’s not exactly plug and play.

Where Does This Fit?

The installation experience is clearly better, but I’m not sure I totally understand the use case yet.

In my earlier post about MCP gateways, I argued that enterprise deployments need centralized governance: visibility into which servers are running, what capabilities they expose, and real-time policy enforcement. Gateway architectures make that possible by proxying all MCP traffic through a central point.

MCPB complicates that premise. If users are installing servers with one click directly into their desktop clients, you lose centralized visibility. There’s no gateway to enforce policies, no audit trail of which servers are enabled per agent, no way to classify tools by the [ABC] framework from Meta’s Rule of Two.

For organizations serious about AI governance, remotely hosted MCP servers make more sense. The security team can vet servers once, host them centrally, and control access through authentication and RBAC. MCPB bundles bypass all of that.

On the other end of the spectrum, developers building and testing servers probably want more control than MCPB provides. They’re working from local checkouts, iterating quickly, and don’t need polished packaging.

So who is this for?

The clearest use case is pure utility tools: servers that don’t call external services, don’t access sensitive data, and don’t create security risks. Things like calculators, text analysis, chart generation, data transformation utilities. Tools that are [B] or [C] only in the ABC framework, never [ABC].

For those, one-click installation makes a lot of sense. You get the convenience without the governance headaches. A user installing a readability analyzer or a unit converter into their Claude Desktop isn’t creating enterprise risk.

But for anything that touches external APIs, sensitive data, or can trigger state changes, I think remotely hosted servers with gateway-based governance are still the right answer for most organizations.

The Bottom Line

MCPB is a solid packaging format. It makes distribution dramatically easier for MCP server developers and reduces installation friction for end users. The tooling is simple, the manifest format is reasonable, and the integration with Claude Desktop works well.

For individual users and pure utility tools, this is a clear win. For enterprise deployments or anything security-sensitive, I still think gateway architectures and remotely hosted servers are the way to go.

The MCP ecosystem is evolving quickly. MCPB is another tool in the toolkit, and I’m glad it exists. I just don’t think it replaces the need for centralized governance in most production environments.

If you’re building MCP servers, adding MCPB support is worth the effort. The distribution benefits are real. Just be clear about who you’re targeting and what security model makes sense for your use case.

Links:

• MCPB GitHub Repository
• writing-tools-mcp
• My earlier post on MCP gateways