I’ve been building MCP servers for the better part of a year. Packaging them, deploying them, debugging why they break in environments that aren’t my laptop. And the whole time, one thing kept nagging at me: nobody is checking what’s inside these things.
MCP servers are the integration layer for AI agents. They connect your models to your databases, APIs, file systems, and credentials. When you give an AI agent an MCP server, you’re handing it privileged access to your infrastructure.
And right now, the way most people distribute MCP servers is to paste a GitHub URL into a config file and hope for the best.
The MCP Server Security Problem Nobody’s Talking About
MCP is growing fast. Thousands of servers exist. Most of them ship as loose scripts, npm packages, or Docker images without verification or scanning, and there’s no way to know if the code you’re running today is the same code the author published last week.
We’ve already seen what happens when this goes wrong.
In January 2026, Clawdbot exposed 1,862 MCP servers with zero authentication. Anyone could connect. In late 2025, a path traversal vulnerability in Smithery.ai compromised over 3,000 hosted MCP servers and leaked thousands of API keys. Even Anthropic’s own Git MCP server shipped with CVEs that allowed argument injection.
These aren’t hypotheticals. They happened. And MCP servers carry risks that traditional packages don’t.
When a malicious npm package runs, it can access your file system. When a malicious MCP server runs, it can access every tool and credential your AI agent has access to. It can poison tool descriptions to redirect the model’s behavior, or exfiltrate data through tool responses the user never sees. The blast radius is bigger because there’s more trust to exploit.
The same patterns that made npm and PyPI supply chains vulnerable are repeating with MCP. Except the stakes are higher and the governance is nonexistent.
What mpak Does: Bundles, Security Scanning, and a Registry
mpak is an open-source MCP package manager and registry with built-in security scanning.
1. MCPB bundles — a standardized packaging format for MCP servers. Every bundle is a self-contained archive with the server code, all dependencies vendored, and a manifest describing exactly how to run it. No npm install at startup. No network calls. No version drift between what you tested and what you deployed. Extract and run.
2. The mpak Trust Framework (MTF) — an open security standard with 25+ automated controls across five domains: supply chain integrity, code quality, artifact integrity, provenance, and capability declaration. Every bundle published to mpak gets scanned automatically and receives a trust score. It’s a transparency label, not a gate. You see exactly what was checked and what passed.
A real trust score on mpak.dev — every bundle shows its certification level, controls passed, and scan date.
3. A registry with CLI, web UI, and API — browse and search at mpak.dev, install and run from your terminal, or integrate programmatically. A full package registry, built specifically for MCP servers.
We wrote about the technical architecture behind the registry in How We Built a Production MCP Registry.
What Is MCPB?
MCPB (MCP Bundles) is an open packaging standard for MCP servers. A .mcpb file is a ZIP archive containing three things:
manifest.json— metadata declaring the server name, version, platform, runtime, and every tool, prompt, and resource the server exposessrc/— the server source codedeps/— all dependencies, vendored and locked
When you run a MCPB bundle, there’s no install step and no fetching packages from the internet. The bundle extracts and starts. The same artifact runs on your laptop, in CI, and in production.
This matters because traditional MCP server distribution depends on npm install or pip install at startup. Every install is a roll of the dice: did a dependency get yanked? Did a new version introduce a bug? Did someone push a malicious update between your last test and your deploy? MCPB eliminates that entire category of risk.
Bundles also carry platform information (linux-x64, darwin-arm64, etc.), so the registry automatically serves the right artifact for your OS and architecture.
How to Install and Run MCP Servers with mpak
Install the CLI:
npm install -g @nimblebrain/mpak
Search for a server:
mpak search postgres
Run it:
mpak bundle run @nimblebraininc/postgres
mpak downloads the bundle, caches it locally, and starts the server. Dependencies are already inside the bundle. Second run is instant from cache.
Need to store credentials? Config is local and permission-locked:
mpak config set @nimblebraininc/ipinfo api_key=your_token
mpak bundle run @nimblebraininc/ipinfo
Hook it into Claude Desktop:
{
"mcpServers": {
"postgres": {
"command": "mpak",
"args": ["bundle", "run", "@nimblebraininc/postgres"],
"env": {
"DB_CONNECTION_STRING": "postgresql://..."
}
}
}
}
Or Claude Code:
claude mcp add postgres -- mpak bundle run @nimblebraininc/postgres
Every server in the registry has been tested end-to-end. We deploy it, send MCP requests, verify responses. Cold starts are under 5 seconds. If it’s listed, it works. See how to deploy an MCP server with mpak in under 2 minutes for a full walkthrough.
Publish MCP Servers Without Passwords
Publishing to mpak requires no API keys, no account setup, no secrets to manage. We use GitHub Actions OIDC for zero-friction, cryptographically verified publishing.
Add a workflow to your repo:
name: Release
on:
release:
types: [published]
permissions:
contents: write
id-token: write
jobs:
publish:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: NimbleBrainInc/mcpb-pack@v2
Create a GitHub release. The action vendors your dependencies, builds the MCPB bundle, and announces it to the registry. GitHub’s OIDC token provides cryptographic proof of which repository, commit, and workflow produced the bundle. Nothing shared, nothing to leak.
The registry verifies the token, stores the bundle metadata, and kicks off the MTF scanner automatically. Your trust score appears on mpak.dev within minutes.
Self-Hosted by Default
mpak isn’t a SaaS product with a self-hosted “enterprise tier.” Self-hosting is the primary deployment model.
Three containers (API, web, Postgres), pluggable storage (local disk, S3, GCS, Azure), and a Helm chart for Kubernetes. Organizations running private registries get full control over which MCP servers are approved for their environment. No data leaves your network.
This was a deliberate design choice. MCP servers touch sensitive systems. The registry that governs them should run where you control it.
Why Open Source, Why Open Standard
mpak is Apache 2.0. The trust framework is CC BY 4.0. We made these choices intentionally.
A security standard only works if people trust it. Proprietary scoring systems create the same lock-in problem we’re trying to solve. If you can’t read the controls, audit the scanner, or run it yourself, you’re just trading one trust gap for another.
We want other registries to adopt MTF. We want security teams to extend it. We want the MCP community to treat supply chain security as shared infrastructure, not a competitive advantage.
The trust framework covers MCP security controls that traditional tools miss entirely: tool description poisoning (hidden instructions in MCP tool metadata that redirect AI model behavior), credential scope analysis (over-permissioned OAuth tokens aggregated across services), and slopsquatting (attackers registering package names that AI coding assistants hallucinate). These are MCP-specific threats that need MCP-specific scanning. I’ll be writing a dedicated post on the trust framework and these attack vectors soon.
Where We Are
mpak is live at mpak.dev. The CLI is published. The registry API has interactive docs at docs.mpak.dev. The trust framework spec is published at mpaktrust.org. Everything is open source.
We’re early. The catalog is growing, the scanner is getting sharper with every bundle we analyze, and we’re actively working with MCP server authors to get their packages bundled and scanned.
If you’re building MCP servers, publish to mpak. Running them in production? Spin up a private registry. CISOs trying to govern AI agent tooling should start with the trust framework.
MCP adoption is accelerating. The question is whether supply chain security grows with it, or catches up later after something truly bad happens.
I’d rather not wait to find out.
Check out mpak.dev, star the repo, or come talk to us in Slack.
FAQ
What is mpak?
mpak is an open-source MCP server package manager and registry. It lets you search, install, run, and publish MCP servers as self-contained MCPB bundles with built-in security scanning via the mpak Trust Framework (MTF).
What is MCPB?
MCPB (MCP Bundle) is an open packaging format for MCP servers. A .mcpb file contains the server code, all dependencies, and a manifest. No install step, no network calls at startup. Read the spec on GitHub.
How do I install an MCP server with mpak?
Install the CLI with npm install -g @nimblebrain/mpak, then run mpak bundle run @scope/server-name. mpak handles downloading, caching, and starting the server.
Is mpak free?
Yes. mpak is open source under the Apache 2.0 license. The trust framework (MTF) is published under CC BY 4.0. You can self-host a private registry at no cost.
How is mpak different from the official MCP registry?
The official MCP registry lists server metadata. mpak hosts tested, bundled servers with security scanning, trust scores, a CLI for one-command installs, and support for private self-hosted registries.