Tool Development

Build with MPP

Why Build on MPP?

Developers who build AI tools face a distribution problem. There is no standard way to package, sign, and deliver a tool that a host can trust — and there is no mechanism for users to know whether the tool they installed is the same one the author published.

MPP solves this. It gives you a publishing pipeline where your authorship is cryptographically attached to every package you ship, and a registry where teams and individuals can discover and install your tools with confidence.

What You Get as a Tool Author

  • A verified identity. Your tools carry your publisher signature. Users see your name attached to every version of every tool you publish. Impersonation and supply-chain substitution are blocked by the protocol.
  • Security by default. The MPP packaging and permission model means your tools only do what they declare. You don't need to build your own sandboxing or permission infrastructure — it's provided by the runtime every host implements.
  • Broad compatibility. A single MPP package runs on any compatible host — IDEs, agent frameworks, enterprise platforms. You publish once and reach every environment that speaks the protocol.
  • Version management. The registry tracks every version you publish. Users can pin to a specific version, and you can flag old versions as deprecated without breaking existing installs.
  • Trust as a differentiator. In a market where tool quality and safety vary wildly, a signed MPP package signals to enterprise buyers that your tool meets a verifiable standard.

Use Cases

Data Query Tools

A tool that runs read-only queries against a database can declare its access scope explicitly — a specific data source, read permissions only. Users approve this scope once. The tool can never exceed it. This is ideal for analytics, reporting, and data-exploration tools where auditability matters.

Web Research Tools

A tool that fetches and summarises web content can declare the exact domains it accesses. It cannot make requests outside that list, store user data, or pass information to undeclared endpoints. Teams can deploy web research tools to employees without worrying about data leakage.

Document & Content Processing

A tool that reads and analyses documents can be scoped to a specific directory or file type. Combined with privacy filters, it can process sensitive content without risking exposure of PII to the model context.

API Integration Tools

Tools that interact with external services — CRMs, ticketing systems, communication platforms — can declare which endpoints they call and which credentials they need. Users approve the integration once; the tool is bound to those parameters permanently.

Internal Enterprise Tools

MPP is well-suited to tools built and distributed within an organisation. An internal registry gives IT teams visibility into what AI tools are in use, who published them, and which versions are deployed. Governance becomes tractable.

Getting Your Tools into the Ecosystem

To publish on MPP, contact the team to discuss a publisher licence. Once you're set up, you'll have access to the registry, signing infrastructure, and the tooling needed to package and distribute your work.