In 2008, the iPhone App Store launched with 500 apps. By 2012, it had 700,000. By 2024, it had over 1.8 million. The App Store did not succeed because Apple built better apps. It succeeded because Apple built the infrastructure that made a marketplace possible: identity verification for developers, code signing for integrity, sandboxing for safety, a review process for quality, and a distribution mechanism that worked globally.
The AI tool ecosystem is approaching its App Store moment. The number of tools available to AI agents is growing exponentially. Every major framework — LangChain, CrewAI, AutoGen, Semantic Kernel — has tool integration. Every major LLM provider supports tool use. The demand side is established.
What's missing is the supply-side infrastructure. There is no standard way for tool publishers to establish their identity. There is no mechanism for verifying that a tool is what it claims to be. There is no sandbox to limit what a tool can do. There is no audit trail to record what a tool did. There is no privacy protection to prevent a tool from exposing sensitive data.
Without this infrastructure, there is no marketplace. There is only a directory of unverified code that agents download and run on blind trust.
What a Marketplace Requires
A functioning marketplace is not a list of things for sale. It is a trust system. Buyers trust that what they purchase is genuine. Sellers trust that they will be credited for their work. The platform operator trusts that neither side is acting maliciously. And everyone trusts that disputes can be resolved.
For an AI tool marketplace, this translates to five infrastructure requirements:
1. Publisher Identity
The problem: Anyone can publish a tool. There is no mechanism to verify that "Acme Database Tools" is actually Acme, or that the tool attributed to a well-known developer was actually published by them.
What a marketplace needs: Publisher identity verification that ties a cryptographic key to a verified entity. When a consumer installs a tool from "Acme Database Tools," they can verify — cryptographically, not just visually — that the package was signed by Acme's private key and that Acme's key is registered with the registry.
MPP provides: Ed25519 keypair-based publisher identity. Publishers register with proof-of-key-ownership (they sign a challenge with their private key). The registry stores the verified mapping between publisher name and public key. Every package carries the publisher's public key and signature.
{
"publisher": {
"name": "Acme Database Tools",
"url": "https://acme-db-tools.com",
"verified_key_id": "pub_a1b2c3d4e5f67890"
}
}
The verified_key_id is not a self-reported field. It is the SHA-256 fingerprint of the publisher's public key, verified by the registry during registration.
2. Package Integrity
The problem: A tool downloaded from a registry might have been modified — by an attacker who compromised the registry's storage, by a man-in-the-middle who intercepted the download, or by a supply-chain attack that substituted a malicious version.
What a marketplace needs: Cryptographic proof that the package the consumer received is identical to the package the publisher published. Not "probably the same." Identical — down to every byte.
MPP provides: SHA-256 content hashing over every file in the package (sorted, deterministic), bound to an Ed25519 signature. The Gatekeeper verifies the signature and content hash before execution. A modified package — even a single changed byte — fails verification and is refused.
3. Capability Transparency
The problem: A consumer evaluating a tool in a marketplace has no way to know what the tool will do once installed. Will it access the network? Which endpoints? Will it read files? Which directories? Will it access credentials? The tool description might say "formats SQL queries," but the code might also phone home to an analytics server.
What a marketplace needs: A structured, machine-readable declaration of what the tool requires, visible to the consumer before installation and enforced by the runtime during execution.
MPP provides: The manifest's capabilities block is a complete declaration of the tool's resource requirements:
{
"capabilities": {
"network": ["api.github.com"],
"filesystem": {
"read": ["/data/repos"],
"write": []
},
"env_vars": ["GITHUB_TOKEN"]
}
}
A marketplace UI can display these capabilities prominently: "This tool accesses api.github.com, reads /data/repos, and uses the GITHUB_TOKEN environment variable." The consumer can evaluate whether these capabilities are appropriate before installation.
More importantly, these capabilities are enforced. A tool that declares access to api.github.com cannot access api.stripe.com. The declaration is not advisory — it is the boundary of the tool's sandbox.
4. Safety Infrastructure
The problem: Even a well-intentioned tool can have bugs. A tool that misconstructs an API request might send sensitive data to the wrong endpoint. A tool with a regex vulnerability might enter an infinite loop and consume all system resources. A tool that doesn't handle errors might crash the host process.
What a marketplace needs: Runtime isolation that prevents a tool's bugs from affecting the host system, other tools, or data that the tool shouldn't access.
MPP provides: WASM sandboxing with per-invocation isolation. Each tool invocation gets:
- A fresh WASM instance. No state persists between invocations (unless explicitly using the KV store).
- Isolated linear memory. The tool cannot read or write the host's memory.
- Resource limits. Memory caps and execution timeouts prevent denial-of-service.
- Restricted I/O. Only declared network, filesystem, and environment access is available.
A tool that crashes, loops, or misbehaves affects only itself. The host, other tools, and the user's system are unaffected.
5. Accountability
The problem: When something goes wrong — a tool produces incorrect results, accesses unexpected resources, or behaves differently than described — there is no record of what happened. Debugging is guesswork. Incident response is incomplete. Accountability is impossible.
What a marketplace needs: A tamper-evident audit trail that records every tool invocation with enough detail to reconstruct what happened, when, and why.
MPP provides: Hash-chained audit logs recording package identity, capabilities requested and granted, permission decisions (including HITL approvals), privacy filter actions, execution metrics, and input/output hashes. The hash chain makes the log tamper-evident — modifying any entry is detectable.
Marketplace Dynamics
With the infrastructure requirements met, the AI tool marketplace can develop the dynamics that make all successful marketplaces work:
Discovery
Consumers need to find tools. A registry with full-text search, categorisation, and publisher metadata enables discovery. Federation extends discovery across multiple registries, so a consumer connected to their enterprise registry can discover tools from the public ecosystem (subject to federation policy).
MPP registries provide:
- Full-text search via PostgreSQL GIN indexes
- Package metadata (description, publisher, version history, capabilities)
- Scope-based organisation (
@acme/sql-analyzer) - Cross-registry resolution via federation
Evaluation
Before installing a tool, a consumer evaluates it. In a traditional app store, evaluation happens through screenshots, descriptions, and reviews. In an AI tool marketplace, evaluation is more technical:
| Evaluation Criterion | What MPP Provides | |---------------------|-------------------| | Who published this? | Verified publisher identity and key ID | | What does it access? | Manifest capabilities (network, filesystem, env vars) | | How sensitive is it? | Security level and computed sensitivity score | | Is it trustworthy? | Ed25519 signature from a verified publisher | | What data does it protect? | Privacy filter configuration | | How popular is it? | Download counts and version history |
A marketplace UI built on the MPP registry API can display all of this information in a structured format. The consumer sees not just "what this tool does" but "what this tool can access, who published it, and how it's secured."
Trust Building
Trust in a marketplace is earned over time. A new publisher starts with zero trust. As they publish tools, accumulate downloads, maintain clean audit records, and respond to issues, trust builds.
MPP supports this through:
- Publisher history. The registry maintains a complete record of a publisher's packages, versions, and activity.
- Audit transparency. Host operators can share aggregate audit data (anonymised invocation counts, error rates, privacy filter hit rates) to inform marketplace ratings.
- Key continuity. A publisher that consistently signs with the same key demonstrates stability. A publisher that rotates keys or changes signing identity triggers flags.
- Version hygiene. A publisher with regular, incremental version updates demonstrates active maintenance. A publisher that goes from 1.0 to 2.0 with a complete code rewrite warrants closer scrutiny.
Quality Signals
Without runtime data, a marketplace relies on superficial quality signals. With MPP's audit infrastructure, the marketplace can develop data-driven quality signals:
- Execution success rate. What percentage of invocations complete successfully?
- Privacy filter hit rate. Does the tool frequently return data that triggers PII redaction? (May indicate the tool handles sensitive data that should be filtered at the source.)
- Capability utilisation. Does the tool actually use all the capabilities it declares? A tool that declares network access but never makes a network call may have an inflated capability declaration.
- Resource efficiency. How much memory and time does the tool use relative to its limits? Efficient tools respect constraints; wasteful tools may indicate quality issues.
These signals are available from the audit log — no additional instrumentation required.
The Publisher Economy
A marketplace is not just a distribution mechanism. It is an economic system. Publishers invest time and expertise in building tools. The marketplace must provide a return on that investment.
Revenue Models
| Model | Description | Fit | |-------|-------------|-----| | Free / open-source | Publisher distributes tools freely for reputation and community benefit | Individual developers, open-source projects | | Freemium | Basic tool is free; advanced features require a paid tier | Tool companies, SaaS providers | | Paid | Tool requires purchase or subscription | Enterprise tool vendors, specialised capabilities | | Enterprise license | Bulk licensing for organisations | Tool vendors serving enterprise customers |
MPP's registry and package format support all of these models. Access control can be implemented at the registry level (authenticated download for paid packages), at the publisher level (different packages for free and paid tiers), or at the host level (license keys checked during execution).
Publisher Incentives
A marketplace that attracts high-quality publishers needs to provide:
- Low friction publishing.
mpp build,mpp sign,mpp publish— three commands to go from code to marketplace. - Security as a selling point. Tools published as MPP packages carry a verifiable security guarantee that ad-hoc scripts do not. This is a competitive advantage in enterprise sales.
- Cross-platform reach. A single MPP package runs on every conforming host. The publisher's addressable market is the entire MPP ecosystem, not a single framework.
- Clear attribution. Publisher identity is cryptographically verified. No one can impersonate a publisher or claim credit for their work.
What the Marketplace Looks Like
Imagine the near-future experience:
A developer building an AI-powered application browses the MPP marketplace. They search for "database analysis" and find 15 tools from 8 publishers. Each listing shows the tool's capabilities (network access to specific database endpoints, no filesystem), security level (medium), publisher identity (verified), and community ratings. They install the top-rated one with mpp install org.dbtools.sql-analyzer.
An enterprise team evaluates the same tools through their private registry. The registry relays the search to the public marketplace, but filters results through the organisation's security policy: only tools from publishers whose keys are in the trusted keystore, only tools that declare privacy filters for email and phone, only tools with security level medium or below. The team sees 6 tools (9 were filtered by policy). They install 3 to evaluate.
A tool publisher releases a new version of their SQL analysis tool. They run mpp build, mpp sign, mpp publish. The new version is available immediately on the public registry. Federated enterprise registries pick it up on their next sync. Within hours, agents across hundreds of organisations are using the new version — verified, sandboxed, and audited.
An incident responder receives an alert: a tool from a publisher whose key has been compromised. They query the audit log for all invocations of packages signed by that key. In minutes, they have a complete list of every invocation, what capabilities were granted, what data was accessed, and which agents were affected. They yank the affected versions with one API call. Agents that try to install the yanked versions receive a clear error.
The Window
The AI tool marketplace is inevitable. The demand for specialised AI capabilities is growing exponentially. The economic incentives for tool publishers are clear. The enterprises that need AI tools are actively looking for them.
What is not inevitable is which marketplace wins. The marketplace that establishes the trust infrastructure first — identity, integrity, permissions, auditing, privacy — will set the standard. Marketplaces built on weaker foundations will struggle to attract enterprise buyers who require governance controls.
The lesson from every previous software marketplace is the same: trust infrastructure is not a feature. It is the foundation. The App Store succeeded because users trusted that apps were reviewed, signed, and sandboxed. npm succeeded because developers trusted (mostly) that packages were what they claimed to be — and when that trust was violated, the resulting crisis drove significant investment in signing and verification.
MPP provides the trust infrastructure for the AI tool marketplace. Publisher identity, cryptographic signing, capability-based sandboxing, privacy filtering, and tamper-evident audit logging — built into the protocol from day one, not bolted on after the first supply-chain attack.
The marketplace is coming. The question is whether it arrives on a foundation of verified trust or on a foundation of hope.
For the registry API that underpins the marketplace, see the Registry API Reference. For how federation connects multiple registries into a unified ecosystem, read MPP Registry Federation. For the supply-chain security that protects the marketplace, read Securing the AI Tool Supply Chain.