In the early days of mobile apps, developers built for one platform. An iOS app required a complete rewrite for Android. An Android app was useless on iOS. The same business logic, the same user experience, the same value proposition — implemented twice, maintained twice, debugged twice.
The waste was staggering. And it didn't just hurt developers. It hurt users (who couldn't access tools on their preferred platform), businesses (who paid double for the same functionality), and the ecosystem (which fragmented into competing silos that slowed overall progress).
AI tools are in the same place today.
The Fragmentation Problem
A tool built for one AI agent framework typically cannot run in another. The reasons vary:
Framework-Specific Integrations
A LangChain tool is a Python class that inherits from BaseTool and implements a _run method. A CrewAI tool inherits from CrewAI's base class. An AutoGen tool follows yet another interface. A Semantic Kernel tool is a C# class with specific attributes.
The business logic is the same — call an API, process data, return results — but the glue code is framework-specific. Porting a tool from LangChain to CrewAI means rewriting the integration layer. Porting to Semantic Kernel means rewriting it again, in a different language.
Runtime-Specific Dependencies
An MCP tool running as a Node.js server requires Node.js on the host. A Python MCP server requires Python. A Go server requires a Go runtime (or a compiled binary for the specific OS and architecture). Each tool brings its own runtime dependency, and the host must satisfy all of them.
In enterprise environments, "install Node.js 18, Python 3.11, and Go 1.22 on the agent host" is not a request that operations teams receive happily. Each runtime is a maintenance burden, a security surface, and a version-compatibility headache.
Host-Specific Packaging
A VS Code extension expects tools in one format. A CLI agent expects them in another. A web-based agent platform might expect a REST API. There is no standard format for "a tool that any host can run."
Tool authors who want to reach all platforms must maintain multiple packaging targets: an npm package for Node.js hosts, a pip package for Python hosts, a Docker image for containerised environments, and custom integrations for proprietary platforms. Each target is a separate build artifact with its own distribution, versioning, and support lifecycle.
The Cost of Non-Portability
This fragmentation imposes costs at every level of the ecosystem:
For Tool Authors
Multiplied maintenance. Supporting N platforms means maintaining N integration layers. A bug fix in the business logic must be ported to every platform's codebase. A new feature must be implemented N times.
Limited reach. Most tool authors choose one or two platforms and ignore the rest. A brilliant database analysis tool that only works in LangChain is invisible to CrewAI users. The author's potential market is artificially limited.
Framework lock-in. Once a tool is deeply integrated with one framework's APIs, moving to another framework is a major undertaking. Tool authors are locked to the framework they started with, even if the ecosystem shifts.
For Enterprise Teams
Vendor dependency. If your agent framework vendor changes direction, raises prices, or is acquired, your entire tool library is tied to their platform. Switching frameworks means re-evaluating every tool.
Inconsistent security posture. Tools deployed via different mechanisms (npm, pip, Docker, custom scripts) have different security properties. There is no unified verification, sandboxing, or auditing across the tool portfolio.
Integration friction. Every new tool requires evaluating which runtime it needs, which framework it targets, and how it connects to the existing infrastructure. This friction slows tool adoption and increases the evaluation burden on platform teams.
For the Ecosystem
Slow market development. A healthy marketplace requires that tools work everywhere. If every tool works on only one platform, the marketplace fragments into incompatible silos, each too small to sustain a vibrant ecosystem.
Duplicated effort. The same tool concept is implemented independently for every major framework. The community collectively builds the same functionality N times instead of once.
Innovation bottleneck. New agent frameworks struggle to attract users because they launch with no tool library. Established frameworks accumulate tool libraries that create switching costs. The ecosystem calcifies around incumbents.
What Portability Means in Practice
True tool portability requires solving three problems simultaneously:
1. A Universal Execution Format
The tool must be compiled to a format that any host can execute, regardless of the host's operating system, CPU architecture, or programming language. This is the problem WebAssembly solves.
A tool compiled to wasm32-wasip1 runs on:
- Windows, macOS, Linux — WASM runtimes are available for all major operating systems.
- x86, ARM, RISC-V — WASM is architecture-independent. The runtime compiles WASM to native code on the target architecture.
- Rust, Go, Python, C# host applications — WASM runtimes (Wasmtime, Wasmer, WasmEdge) have bindings for every major language.
The tool author compiles once. The resulting .wasm binary runs on every conforming host. There is no "Node.js version" and "Python version" and "Go version" of the same tool. There is one artifact.
2. A Standard Package Format
The execution format solves "how to run." The package format solves "what to distribute." A portable tool needs more than a WASM binary — it needs metadata, capability declarations, privacy configuration, and a signature.
MPP's .mpp package format is a standard ZIP archive containing:
package.mpp (ZIP)
├── manifest.json # Identity, capabilities, tool definitions
├── bin/main.wasm # The WASM binary
├── resources/ # Optional static assets
└── certs/ # Ed25519 signature and public key
Any host that understands this format can:
- Verify the package's signature
- Read the tool's capabilities
- Configure the sandbox
- Execute the tool
- Apply privacy filters
The format is simple enough that implementing a conforming host is not a multi-month project. The reference implementation's host integration is roughly 50 lines of Rust. The format is documented, open, and does not depend on any specific vendor's infrastructure.
3. A Common Invocation Protocol
The tool must speak a protocol that any host can interact with. MPP uses JSON-RPC 2.0 over stdin/stdout: the same protocol as MCP. The tool reads a JSON-RPC request from stdin and writes a JSON-RPC response to stdout.
This means:
- The host doesn't need framework-specific bindings. It writes JSON to a pipe and reads JSON from a pipe.
- The tool doesn't need host-specific adapters. It reads from stdin and writes to stdout.
- Any language that can read/write JSON can participate, on either side.
Where This Leads
With all three problems solved — universal format, standard packaging, common protocol — a new set of possibilities opens up:
Build Once, Run Anywhere
A tool author writes one implementation, compiles to WASM, packages as .mpp, and publishes to a registry. The same package runs on:
| Host Environment | How It Runs | |-----------------|-------------| | VS Code extension | Extension embeds MPP runtime, executes tools in sidebar | | JetBrains IDE plugin | Plugin embeds MPP runtime, executes tools natively | | CLI agent | Agent binary includes MPP runtime, runs tools from terminal | | Web-based platform | Server-side WASM runtime executes tools via API | | Custom enterprise platform | Platform integrates MPP crates, runs tools in managed environment | | Edge device | Lightweight WASM runtime executes tools offline |
The tool author doesn't need to know about any of these host environments. They build to the MPP spec, and the spec guarantees compatibility.
Framework Independence
An enterprise team can switch from LangChain to CrewAI — or to a custom agent framework — without re-evaluating their tool library. The tools are MPP packages. Any agent framework that integrates the MPP runtime can use them.
This eliminates framework lock-in for tools. The agent framework is a replaceable component. The tool library is a persistent asset.
Consistent Security Across Platforms
Every host that runs MPP tools gets the same security properties: Gatekeeper verification, capability-based sandboxing, HITL approval, privacy filtering, and audit logging. A tool running in VS Code has the same security posture as the same tool running in a CLI agent or a web platform.
Compare this to the current state: a Node.js MCP server has different security properties than a Python MCP server, which has different properties than a Docker-wrapped tool, which has different properties than a custom integration. There is no baseline.
Offline and Edge Deployment
Because MPP tools are self-contained WASM packages, they work fully offline after installation. There is no live server to connect to. There is no runtime to download on first use. The tool is a signed binary on disk, ready to execute.
This enables deployment in environments where traditional tool architectures fail:
- Air-gapped networks — classified environments, regulated infrastructure
- Edge devices — IoT, embedded systems, field equipment
- Unreliable connectivity — remote offices, mobile environments, aircraft
- Low-bandwidth environments — metered connections, satellite links
The tool is installed once (a single .mpp file download), verified once (Gatekeeper checks the signature), and available indefinitely.
The Economic Argument
Portability is not just a technical convenience. It is an economic enabler.
For tool authors: Portability expands the addressable market from "users of one framework" to "users of any conforming host." A tool published as an MPP package can be installed by anyone. The author's effort is amortised across the entire ecosystem.
For enterprises: Portability reduces the cost of tool adoption. Instead of evaluating "does this tool work with our specific framework, runtime, and deployment model," the evaluation is "does this tool solve our problem?" The integration cost is absorbed by the host runtime, not by the evaluation process.
For the ecosystem: Portability enables a marketplace. A functioning marketplace requires that buyers and sellers meet on common ground. If every tool only works on one platform, the marketplace fragments into incompatible islands. If every tool works everywhere, the marketplace can scale.
The mobile ecosystem didn't mature until cross-platform frameworks (React Native, Flutter) and progressive web apps reduced the cost of multi-platform distribution. The AI tool ecosystem will follow the same pattern — and the faster it gets there, the faster the ecosystem develops.
What This Is Not
Portability is not a promise that every tool works equally well on every platform. Host environments have different capabilities:
- A VS Code extension can display rich UI for HITL dialogs. A CLI agent uses terminal prompts.
- A web platform may not support filesystem access. An edge device may not support network access.
- A high-memory server can run tools with 4 GB memory limits. A constrained device cannot.
Portability means that the tool can run on any conforming host. How the host presents the HITL dialog, how it provisions the sandbox, and what resources it allocates are host-specific. The tool itself is portable. The user experience adapts to the host.
This is the same model as the web platform: HTML and JavaScript run in every browser. But the rendering, the screen size, and the available APIs vary by device. The content is portable. The presentation is adaptive.
For the package format specification, see the Package Format documentation. For how to package an existing tool, read From MCP Server to MPP Package. For how portability enables the marketplace vision, read The AI Tool Marketplace is Coming.