One-click MCP.

Anthropic's Desktop Extensions format bundles everything — and what that design decision reveals about activation energy, installation gravity, and who gets to participate in an ecosystem.

Anthropic Engineering · Desktop Extensions, June 2025

What this post is really about.

The MCP ecosystem had a distribution problem that had nothing to do with the protocol. Model Context Protocol — the open standard for connecting AI models to local tools, filesystems, calendars, and databases — worked. The servers people had built for it were often impressive. What didn't work was the path between "server exists" and "person is running it." For most of the intended audience, that path ran through a terminal, a JSON editor, and a working knowledge of Node.js version management.

This is the shape of a classic activation energy problem. The capability is there; the barrier to starting the reaction is not. Anthropic's Desktop Extensions format — .mcpb files, a ZIP archive containing everything, installed by double-click — is a direct attack on that barrier. The post announcing it reads like a feature release. Read alongside the Farnam Street canon, it is also an argument about who pays the compatibility cost in a software ecosystem, and whether that accounting has been honest.

Three kinds of models are on offer. Several classics come out amplified — activation energy, margin of safety, separation of concerns. A few get bent — the YAGNI heuristic, open distribution as default, the lean increment. And finally, the format introduces a handful of new models that earn a place in the latticework: capability bundling, installation gravity, and declared dependency. What follows is a structured pass through all three.

Old models, sharper edges.

The post begins with a five-bullet list of installation barriers — developer tools requirement, manual configuration, dependency management, discovery challenges, update difficulties — and this is precisely what activation energy looks like rendered as a product problem. Each item is an abandonment point. The five-step sequence collapses to download, open, install. The design makes the old friction legible by contrast: you can now count how many barriers there were, because they are gone.

The manifest.json is instructive in its minimalism. Only one file is required for a valid extension. Minimum viable complexity applied to developer tooling: the entry point does one thing, and everything else is optional. The npx @anthropic-ai/mcpb init wizard further compresses the energy to start — a single interactive command generates a complete manifest, with a --yes flag for the impatient.

The OS keychain integration is where margin of safety shows up, quietly. A naive spec would store API keys in a plain config file. The Desktop Extensions format routes sensitive values through the operating system's own secret store by default. The margin-of-safety principle is asymmetric cost accounting: the safer option is paid for once, at design time; the unsafe option accrues liability forever. A leaked API key from a plain config file costs far more than the engineering time to wire up the keychain.

Finally, the ZIP archive structure maps cleanly to separation of concerns: manifest, server, dependencies, icon — each layer has one job, each is replaceable independently. The built-in Node.js runtime in Claude Desktop makes the dependencies/ folder fully deterministic. No version negotiation, no host environment pollution. The bundle is atomic: what the developer tested is what the user runs.

Models that do not survive intact.

The Desktop Extensions format makes a large early bet on standardisation. The principle YAGNI — you aren't gonna need it — counsels against building abstractions before you know what you're abstracting over. The team chose the opposite: a full packaging format, a toolchain, an open spec, TypeScript types, and a curated directory, before any of those feel strictly necessary. The implicit reasoning is that the cost of early standardisation is a fixed overhead paid once; the cost of late standardisation is forking — N incompatible packaging schemes that calcify and never converge.

The local-test instruction deserves attention. To preview an extension before submitting, developers drag the .mcpb file into Claude Desktop's Settings window. This is elegant, but it also shows that the format requires a complete bundle — thumbnail, server code, all dependencies — to be functional. There is no "ship a minimal stub and iterate." The package is atomic. This contradicts the lean increment small orthodoxy in an interesting way: sometimes the minimum viable package is the full package. The distribution channel demands completeness, not incrementalism.

The submission process introduces something closer to a platform gate than a pure open ecosystem: security review, cross-platform testing, and a curatorial decision. The instinct toward decentralised distribution as default — publish and let the market decide — is moderated by a real concern. MCP servers can access filesystems, credentials, and external APIs. A curated directory is slower; it is also safer. The format itself is open-sourced; the prominent distribution channel is gated. Both are true simultaneously, and the tension between them is not resolved by the post so much as acknowledged and held.

New entries for the latticework.

The sharpest new model is capability bundling — shifting portability responsibility from user to developer. In the old MCP install flow, users bore the entire compatibility burden: their runtime version, their package conflicts, their JSON syntax errors. The .mcpb format inverts this. One developer pays the packaging cost once; every user gets the correct runtime. The economics are clear: one developer solving compatibility upstream is better than ten thousand users each solving it downstream. This generalises: any ecosystem that moves compatibility work toward the developer and away from the user lowers the effective adoption barrier for the entire platform.

The second new model is installation gravity — the idea that the install path is not a neutral convenience feature but a selection mechanism. A terminal-only install flow selects for developers. A double-click install flow selects for a much larger group: professionals, researchers, and power users who know what MCP does but cannot maintain a Node.js environment. The Desktop Extensions format is a deliberate gravitational shift. The question "who can install this?" is a question about ecosystem participation, and the answer is determined almost entirely by the installation UX.

The third is declared dependency — making an extension's asks auditable at install time, not discoverable at runtime. The user_config schema means users see, before clicking Install, exactly what the extension will request: which API keys, which directory paths, which sensitive flags. This is a form of permission architecture made legible. Compare browser extensions, which typically surface permissions in a modal most users dismiss. Declared dependency forces the disclosure conversation earlier, when the user still has full power to walk away.

Finally, the enterprise section — Group Policy support, MDM deployment, blocklists, private extension directories — reveals a fourth model the post doesn't name: infrastructure-first design. The format was built with IT administrators as a primary user, not an afterthought. When the constraint layer (enterprise policy, MDM) is designed for from the start, the application layer inherits its safety properties. Security is not bolted on; it is load-bearing.

When to reach for which.

The latticework, after Desktop Extensions.

The post reads, at first, like a feature announcement. It is that. But it is also an argument about invisible accounting — where software friction lives, and whose job it is to pay for it. The old MCP install flow was technically correct and practically inaccessible to most of its intended audience. The .mcpb format is a claim that developer tooling and consumer products are not different things; they are the same thing aimed at people with different tolerances for friction.

Package once, run anywhere that supports MCPB. Anthropic Engineering, June 2025

The latticework gains three new models from this reading. Capability bundling is about who pays the compatibility cost. Installation gravity is about who the install path selects for. Declared dependency is about when the trust conversation happens. All three are about invisible costs — costs that are real whether or not anyone has named them — and whether the accounting has been honest about who bears them.