What Is the Conway Extension Format? How Anthropic's Proprietary Layer Sits on Top of MCP

The Open Standard Underneath—and the Proprietary Layer on Top

When Anthropic released the Model Context Protocol in late 2024, it was framed as an open standard—a universal connector between AI models and the tools, data sources, and services they need to do useful work. And it is open. Any developer can implement it. Any AI system can speak it.

But open standards rarely stay purely open once a major platform provider gets involved. Enter the Conway Extension Format.

The Conway Extension Format is Anthropic’s proprietary packaging layer that sits on top of MCP. It uses .cnw.zip files to bundle Claude-specific extensions—capabilities, configurations, and behaviors that go beyond what the base MCP spec covers. If MCP is the open road, Conway is Anthropic’s toll lane: faster, more capable for Claude users, but not something any other AI runtime can simply pick up and run.

Understanding the Conway Extension Format matters if you’re building integrations, deploying AI agents, or evaluating what Claude-native development actually looks like at the infrastructure level.

What MCP Actually Does (and What It Doesn’t Cover)

Before getting into Conway, it helps to be clear on what MCP is solving.

MCP defines a standard way for AI models to connect to external resources: files, databases, APIs, tools, and other services. It handles the communication protocol—how a client (an AI model) requests something from a server (a tool or data source), and how that server responds.

The spec covers:

Resources: Exposing data (files, documents, database records) to a model
Tools: Callable functions the model can invoke
Prompts: Reusable prompt templates that servers can offer
Sampling: Letting servers request model completions

What MCP doesn’t specify is how extensions are packaged, distributed, or installed. It’s a protocol, not a packaging system. It tells you how two systems should talk to each other once they’re connected—not how to bundle, sign, version, or deploy the code that makes that connection happen.

That gap is what the Conway Extension Format fills.

What Is the Conway Extension Format?

The Conway Extension Format is Anthropic’s answer to extension packaging for the Claude ecosystem. A .cnw.zip file is an archive that contains everything needed to install and run a Claude extension: the MCP server code, metadata, permission declarations, capability definitions, and configuration schemas.

Think of it as a .vsix file for VS Code, or an .apk for Android. It’s a self-contained unit that Claude (and Claude-integrated platforms) knows how to read, validate, and load.

What’s Inside a .cnw.zip File

A Conway extension package typically contains:

manifest.json: Extension metadata—name, version, author, description, and declared capabilities
server entry point: The MCP server implementation itself (TypeScript or Python, typically)
permission declarations: What the extension can access (file system, network, specific APIs, etc.)
schema files: Typed definitions for the tools and resources the extension exposes
configuration templates: User-facing settings the extension accepts

The format enforces a specific directory structure and schema. Extensions that don’t conform won’t load in Claude-native environments, regardless of whether the underlying MCP server code is technically valid.

Why It’s Called “Conway”

The name references Melvin Conway, the computer scientist behind Conway’s Law: “Any organization that designs a system will produce a design whose structure is a mirror image of that organization’s communication structure.”

Anthropic’s choice of name isn’t accidental. The format reflects how Anthropic thinks about the Claude ecosystem—not just as a protocol layer, but as a structured environment where extensions, capabilities, and behaviors are organized in ways that mirror how the company itself builds and maintains Claude.

The Android Analogy—and Why It Matters

The clearest way to understand what Anthropic has done is the Google Play Services comparison.

Android (AOSP) is open source. Anyone can build on it, fork it, or implement their own Android-compatible operating system. But Google Play Services—the proprietary layer that handles push notifications, location APIs, in-app payments, and most of the core functionality that modern apps depend on—runs exclusively on certified Google-licensed devices.

Apps that use Google Play Services APIs will run on a standard Android device with Google’s stack installed. They will not run on a pure AOSP build without significant modification.

The Conway Extension Format creates the same dynamic:

Layer	Android	Claude / MCP
Open standard	Android Open Source Project (AOSP)	Model Context Protocol (MCP)
Proprietary layer	Google Play Services	Conway Extension Format
Distribution mechanism	Google Play Store	Claude extension registry
What breaks without it	Play-dependent apps	Conway-formatted extensions

An MCP server built to the plain open spec will work with any MCP-compatible client—Claude, other AI models, custom agent frameworks. A Conway-formatted .cnw.zip extension, however, is built for Claude specifically. It may expose functionality that only makes sense in Claude’s context window, depend on Claude-specific sampling behaviors, or use permission models that no other AI runtime understands.

This isn’t a conspiracy. It’s product architecture. Anthropic needs to be able to deliver consistent, safe, verifiable extension behavior across Claude deployments—and a shared open protocol alone doesn’t give them enough control to do that at scale.

What Conway Adds That MCP Doesn’t

The practical differences between a raw MCP server and a Conway-packaged extension go beyond packaging format. Conway enables several capabilities that aren’t in the base MCP spec.

Typed Capability Declarations

Conway extensions declare their capabilities in a structured, machine-readable way at the package level—not just at runtime. This lets Claude (and Claude-adjacent tooling) reason about what an extension does before loading it, verify its permissions, and surface accurate descriptions to users.

Raw MCP servers describe themselves through their protocol responses. That works, but it means you don’t know what you’re getting until the server is already running.

Verified Permission Scoping

Conway defines a permission model. When an extension declares it needs file system access, or network access, or access to specific APIs, that declaration is part of the signed package. It can be reviewed, audited, and enforced at install time.

This is important for enterprise deployments and for Anthropic’s own safety evaluation process. Without a packaging format, there’s no standard way to pre-screen what an extension will try to do.

Versioning and Dependency Management

Conway packages include versioning metadata that integrates with Claude’s extension resolution system. If an extension requires a minimum Claude version, or depends on other extensions, those relationships are declared in the manifest.

MCP itself has no native concept of extension versions or dependencies.

Distribution via Claude’s Registry

Conway-formatted extensions can be submitted to Anthropic’s extension registry (similar to a marketplace), where they’re reviewed and made available to Claude users. Plain MCP servers can’t participate in this distribution channel because they don’t carry the metadata the registry requires.

The Developer Trade-Off: Open MCP vs. Conway Extensions

If you’re building integrations for Claude, you have a choice. You can build a plain MCP server, or you can build a Conway-formatted extension. Each path has different trade-offs.

Building a Plain MCP Server

Advantages:

Works with any MCP-compatible AI system, not just Claude
No dependency on Anthropic’s packaging toolchain
Simpler to develop and test
Fully open—your implementation can be audited and forked

Disadvantages:

Not listable in Claude’s extension registry
Harder to distribute to non-technical users who expect a simple install experience
No standardized permission model
Can’t take advantage of Conway-specific Claude capabilities

Building a Conway Extension

Advantages:

First-class experience in Claude Desktop and Claude-integrated products
Distributable via the registry
Clear, auditable permission declarations
Access to Conway-specific APIs and behaviors

Disadvantages:

Only runs in Claude environments
Requires learning and following the Conway packaging spec
Dependency on Anthropic’s toolchain and review process
Creates a lock-in dynamic if your extension becomes widely depended upon

For most developers building Claude-native tools, Conway is the right choice. For developers building general-purpose AI tool integrations, plain MCP gives you more portability.

Implications for the Broader AI Ecosystem

The Conway Extension Format is a sign of how AI platform competition is maturing.

In the early MCP era (late 2024, early 2025), the conversation was almost entirely about the protocol itself: what it could do, how to implement it, which AI systems were supporting it. Now that MCP has achieved meaningful adoption, the competitive layer has shifted up the stack.

Anthropic isn’t competing on protocol anymore—it’s competing on ecosystem. By making Claude the best platform for Conway extensions, Anthropic can build network effects that persist even if another AI system implements MCP equally well. If the best extensions are Conway-formatted, and Conway only runs on Claude, developers and users have a reason to stay in the Claude ecosystem.

This is the same playbook Microsoft ran with Windows APIs, Google ran with Android, and Apple runs with iOS. Open the foundational layer (or let it be open), then create proprietary value-adds that are hard to replicate without your specific platform.

It doesn’t make the open layer meaningless. MCP is still genuinely useful and genuinely open. But it does mean that “MCP support” and “Claude extension support” are increasingly different things, and conflating them creates real confusion for developers deciding where to invest their time.

How MindStudio Fits Into This Landscape

Building production-grade integrations on top of MCP—with or without Conway packaging—means dealing with the infrastructure layer: authentication, rate limiting, retry logic, connection management, and keeping up with spec updates as both MCP and Conway continue to evolve.

MindStudio handles that infrastructure layer for you. When you build AI agents in MindStudio, MCP connections are managed at the platform level—you don’t need to manually implement MCP clients or worry about Conway compatibility for the 1,000+ pre-built integrations MindStudio ships.

More relevant for developers: MindStudio agents can be exposed as agentic MCP servers themselves, meaning other AI systems—including Claude—can call MindStudio-built agents the same way they’d call any MCP tool. You get the composability of MCP without having to build and maintain the server yourself.

If you’re evaluating how to build Claude integrations without getting deep into Conway packaging, MindStudio’s no-code agent builder is worth looking at. The average agent build takes 15 minutes to an hour, and you get access to Claude alongside 200+ other AI models without managing separate API keys or integration infrastructure.

You can try MindStudio free at mindstudio.ai.

Frequently Asked Questions

What is the Conway Extension Format?

The Conway Extension Format is Anthropic’s proprietary packaging standard for Claude extensions. It uses .cnw.zip archive files to bundle MCP server code with metadata, permission declarations, and configuration schemas. Conway extensions can be distributed through Anthropic’s extension registry and load natively in Claude Desktop and other Claude-integrated environments.

Is Conway the same as MCP?

No. MCP (Model Context Protocol) is an open communication protocol that defines how AI models connect to external tools and data sources. The Conway Extension Format is a proprietary packaging layer that sits on top of MCP—it specifies how Claude-specific extensions are bundled, signed, and distributed. You can implement MCP without using Conway, but Conway extensions depend on MCP as their underlying protocol.

Can Conway extensions run on non-Claude AI systems?

Generally, no. Conway extensions are designed specifically for Claude’s runtime environment. They may use Claude-specific capabilities, permission models, or sampling behaviors that other AI systems don’t support. An MCP server built to the open spec, however, can run on any MCP-compatible client.

Why did Anthropic create a proprietary layer on top of an open standard?

Several reasons. The open MCP spec covers communication protocol but doesn’t define how extensions are packaged, versioned, or distributed. Anthropic needed a structured format to support an extension marketplace, enforce permission models, and ensure consistent behavior across Claude deployments. The proprietary layer also creates ecosystem lock-in—valuable for Anthropic’s competitive position even as MCP remains open.

Do I need to use Conway format to integrate with Claude?

Not necessarily. If you’re building an integration for your own use or for developers comfortable running MCP servers manually, plain MCP works fine with Claude. Conway packaging is most valuable if you want to distribute through Anthropic’s extension registry, provide a one-click install experience, or access Conway-specific permission and capability features.

How does this affect developers choosing between Claude and other AI platforms?

It means the level of investment required to build Claude-native extensions is higher than building generic MCP integrations—but the experience you can deliver to Claude users is also richer. For developers targeting Claude specifically, Conway is worth learning. For developers building cross-platform AI tools, plain MCP keeps your options open.

Key Takeaways

The Conway Extension Format is Anthropic’s proprietary packaging layer for Claude extensions, distinct from (but built on top of) the open MCP standard.
.cnw.zip files bundle MCP server code with metadata, permission declarations, versioning, and configuration schemas into a self-contained extension package.
The relationship mirrors Google Play Services on Android: MCP is the open foundation, Conway is the proprietary value-add that creates ecosystem advantages for Claude specifically.
Conway enables capabilities MCP doesn’t cover: typed capability declarations, verified permission scoping, versioning, and distribution through Claude’s extension registry.
Developers must choose between plain MCP (more portable, works across AI systems) and Conway extensions (Claude-native, richer experience, registry distribution).
As AI platforms mature, competition increasingly happens at the ecosystem layer, not the protocol layer—Conway is Anthropic’s move in that direction.

If you’re building AI agents and want to skip the infrastructure complexity of MCP and Conway entirely, MindStudio handles the protocol layer so you can focus on what your agent actually does.