The JavaScript ecosystem learned this lesson the hard way: a great package registry and a great runtime security model are two different problems, and solving one doesn't solve the other. npm made sharing code trivial. It took years of supply-chain incidents — and the introduction of package signing, lock files, and audit tooling — before the runtime side caught up.
AI agent tooling is at exactly the same fork in the road, and MCP is in the npm seat.
That's not a criticism. It's a recognition that MCP solved a genuinely hard problem first — and that a second, complementary layer is now needed to make the ecosystem production-ready. MPP is that layer.
What MCP Gets Right
The Model Context Protocol is a wire protocol: a standardized way for an AI model to discover what tools are available, describe their interfaces, and invoke them over a connection. Before MCP, every agent framework had its own tool-calling convention. Getting a Claude model to use a tool written for a GPT-based agent meant rewriting glue code. MCP gave the ecosystem a shared language.
Concretely, MCP:
- Defines a JSON-RPC 2.0 interface for listing tools (
tools/list) and calling them (tools/call) - Specifies how a tool should describe its input schema, so any model can understand how to invoke it
- Provides a standard server model: a tool author runs a process that speaks MCP, and any compliant agent can connect and use it
This is the right starting point. Standardizing invocation is a prerequisite for everything else. You can't build a registry, you can't build a marketplace, and you can't reason about which tools an agent used unless everyone agrees on a common calling convention.
But MCP's scope is deliberately narrow. It does not define what runs inside the tool server, who wrote it, whether it's been tampered with, what system resources it can access, or what happens to sensitive data that flows through it. Those questions were left to each implementor — which is reasonable for a v1 protocol trying to get broad adoption, and increasingly dangerous as that adoption arrives.
The Gap MCP Leaves Open
When an agent calls an MCP tool today, it connects to a server process and trusts it completely. That trust is implicit and unconditional. The tool runs with whatever operating system permissions the server process was granted. It can read files the agent process can read. It can make network calls to any host. It can persist data, spawn child processes, and modify host state — and the agent has no visibility into any of it.
The attack surface this creates is real:
Prompt injection via tool descriptions. MCP's own documentation notes that a malicious tool description can contain instructions that redirect the model's behavior. A tool that claims to "fetch the weather" can instruct the model to exfiltrate the conversation to a remote server, and the user would never know.
Supply-chain compromise. As MCP tool registries grow, they become valuable targets. A compromised package update in a popular MCP server is indistinguishable from a legitimate one — there's no cryptographic signature to check.
Ambient authority. A tool that needs to read one directory gets access to everything the server process can touch. The principle of least privilege doesn't exist at the protocol level.
PII leakage. Sensitive data — API keys, personal information, internal system details — flows freely between the agent and tool servers. There's no filtering layer, no redaction, no audit trail.
None of this is MCP's fault. These are runtime and packaging concerns, not protocol concerns. But they do need to be solved somewhere before enterprises can comfortably deploy autonomous agents at scale.
What MPP Adds
Model Package Protocol operates one layer down from MCP in the stack. Where MCP defines how tools are invoked, MPP defines what tools are and how they're secured during distribution and execution.
An MPP package is a .mpp archive: a signed, portable bundle containing a WebAssembly binary, a machine-readable manifest, and a cryptographic certificate from the publisher. Before any code runs, the host runtime passes the package through a verification pipeline — the Gatekeeper — that checks six independent security properties:
1. Cryptographic integrity. Every MPP package is signed with Ed25519. The runtime recomputes the SHA-256 content hash and verifies the publisher's signature before loading. A single changed byte — anywhere in the package — causes verification to fail. This closes the supply-chain attack vector entirely.
2. WASM sandboxing. Tool code executes inside a WebAssembly module. WASM provides hardware-enforced memory isolation: the tool cannot read the host's heap, cannot access the OS directly, and cannot do anything that isn't explicitly permitted through the WASI capability interface. Each invocation gets a fresh module instance that is torn down when the call completes.
3. Declared capabilities. Before execution, a tool's manifest must enumerate every resource it needs:
"capabilities": {
"network": ["api.github.com"],
"filesystem": {
"read": ["/data/inputs"],
"write": ["/data/outputs"]
},
"env_vars": ["GITHUB_TOKEN"]
}
The runtime enforces these declarations at the syscall boundary. A tool that requests access to api.github.com cannot connect to api.stripe.com. A tool allowed to read /data/inputs cannot open /etc/passwd. Undeclared resources are invisible to the tool — not rejected with an error, simply absent.
4. Human-in-the-loop approval. For high-sensitivity operations, MPP issues confirmation dialogs before execution. The user sees exactly what the tool is asking to do — not a vague "this tool may access the network" banner, but the specific domains, paths, and environment variables it will touch.
5. PII redaction. MPP's privacy filter layer sits between the tool and the agent, scanning all response data against a library of configurable patterns — credit card numbers, email addresses, API key formats, SSNs — and redacting matches before they reach the model context.
6. Append-only audit logs. Every invocation writes a hash-chained record: which package ran, which capabilities it used, what input it received, and what output it returned. Entries cannot be modified or deleted without breaking the chain, providing a tamper-evident history for compliance and incident response.
How They Work Together
MPP and MCP aren't competing for the same space. Think of it this way:
- MCP is the calling convention — like function signatures and JSON-RPC semantics.
- MPP is the execution environment — like containers plus image signing plus a capability OS.
A practical deployment uses both. An agent discovers available tools through a MCP-compatible registry. Those tools are distributed as MPP packages. When the agent calls a tool, the host runtime validates the MPP package, enforces its capability declarations, executes the WASM binary in a sandbox, filters the output through PII redaction, and writes the invocation to the audit log — all before the result reaches the model.
The wire format for the actual tool call remains JSON-RPC 2.0, compatible with any MCP-aware model or framework. Migrating existing MCP tool logic to MPP is mostly a packaging step: compile the business logic to WASM, write a manifest, sign the package. The core functionality doesn't change.
For tool authors, this means you can write once and reach any MPP-compliant host — VS Code, JetBrains, a CLI agent, or a custom enterprise deployment — without rewriting adapters. For host developers, it means you can give users cryptographic guarantees about every tool in the system without auditing each tool manually.
The Right Frame
Calling MPP and MCP competitors misreads what each one is for. MCP standardized the conversation. MPP is building the trust infrastructure that makes that conversation safe to have at scale.
If you're already building with MCP, MPP isn't a reason to stop. It's a reason to keep going, with a security model that can actually stand up to production.
The specification, Gatekeeper reference implementation, and SDK documentation are available in the MPP technical docs. Start there.