mpak

The open source package registry for MCP (Model Context Protocol) servers. Every bundle scanned, every install scored.

mpak provides three things:

1. MCPB (MCP Bundle), a standardized package format for MCP servers with declared dependencies, locked versions, and reproducible installs.
2. MTF (mpak Trust Framework), a security scanner that scores every bundle across supply chain, code quality, artifact integrity, and provenance controls.
3. A self-hostable registry that stores, serves, and scores MCPB bundles. Use the public instance at mpak.dev or run your own.

Why this exists

MCP is the open protocol that lets AI agents call external tools. An MCP server exposes capabilities (API calls, file access, database queries) that agents invoke at runtime. That means MCP servers get privileged access to AI agent execution environments. A compromised server means arbitrary code execution inside your workflow.

The MCP ecosystem has no standardized supply chain security. Servers are distributed as loose scripts, GitHub repos, npm packages, and Docker images with no consistent packaging and no verification of what they contain before they run. The official MCP Registry indexes thousands of servers but makes no claims about their safety.

Discovery is solved. Trust is not. mpak handles what comes after discovery: packaging, verification, distribution, and governance.

Concepts

Bundles

A bundle is a .mcpb file (a ZIP archive) that contains everything needed to run an MCP server:

my-server.mcpb
├── manifest.json     # Metadata: name, version, server_type, how to run it
├── src/              # Server source code
└── deps/             # All dependencies, vendored

manifest.json is the required entry point. It declares the package name, version, server type (node, python, or binary), platform-specific run commands, and the tools/prompts/resources the server exposes. The schema is defined in packages/schemas.

Trust levels

Every bundle receives a trust score from the MTF scanner. The score has two parts: a level (L1 through L4) and a numeric score (0 to 100) representing how many controls passed within that level. See the full framework at mpaktrust.org.

Level	Name	Controls	What it means
L1	Basic	5	SBOM generated, no secrets or malware detected, valid manifest, tools declared
L2	Standard	15	Adds vulnerability scanning, dependency pinning, static analysis, author identity
L3	Verified	22	Adds bundle signatures, build attestation, input validation, repo health checks
L4	Attested	25	Adds behavioral analysis, reproducible builds, commit linkage

In the CLI output, L3 87 means the bundle reached Level 3 and passed 87% of L3 controls.

Publishing

Bundles are published through GitHub Actions, not the CLI. A GitHub Actions workflow calls POST /v1/bundles/announce with a GitHub OIDC token. The registry verifies the token, downloads the release artifact from GitHub, validates the SHA256 hash, stores the bundle, and triggers an MTF security scan. This design ensures every published bundle has a verifiable link back to a source repository and CI run.

Claiming

Claiming lets a maintainer prove they own a package. To claim @scope/my-server, add a mpak.json file to your GitHub repo: