What Is mpak? The MCP Server Registry Explained

mpak is the open-source registry for MCP servers. If you’re deploying AI agents that need to connect to external systems (CRMs, databases, email platforms, financial APIs, developer tools), mpak is where you find, evaluate, and install the servers that make those connections work. Search the registry, check the trust score, install with one command. Available at mpak.dev.

MCP (Model Context Protocol) is the open standard for connecting AI agents to tools. An MCP server wraps an external system (Salesforce, PostgreSQL, Slack, whatever) and exposes it to agents through a standardized interface. The protocol works. The problem was everything around the protocol: finding servers, evaluating their security, installing them without fighting dependency conflicts, and trusting that they do what they claim. mpak solves all four.

The Discovery Problem

The MCP ecosystem has thousands of servers. GitHub hosts hundreds of repositories tagged with “mcp-server.” Unofficial directories list more. Community forums share recommendations. The protocol is thriving. But the distribution story is a mess.

Try to find an MCP server for your CRM without mpak. Search GitHub. Find six repositories. Three haven’t been updated in months. One has a README with no installation instructions. Two look promising but you can’t tell which MCP protocol version they target, what permissions they require, or whether anyone has reviewed the code for security issues. Pick one. Clone it. Install dependencies. Fix the Python version conflict. Configure environment variables by reading the source code because the documentation doesn’t cover them. Get it running. Test it against your actual CRM instance. Hope the server doesn’t do anything unexpected with your credentials.

That’s one server. A production Deep Agent deployment typically needs five to ten. CRM. Email. Calendar. Database. Document storage. Task management. Each one sourced through the same manual process. Each one an unknown security risk.

This isn’t a developer inconvenience problem. It’s an adoption bottleneck. Enterprise security teams won’t approve agent deployments when the tool layer is sourced ad hoc from unvetted GitHub repos. Developers won’t build agent features when standing up each integration takes hours of manual work. The MCP protocol is ready for production. The distribution ecosystem wasn’t. mpak bridges that gap.

Three Commands to Running

mpak compresses the entire discovery-to-running workflow into three commands.

Search. mpak search salesforce returns every MCP server in the registry that handles Salesforce connections. Each result shows the server name, description, author, trust score, install count, and last update date. No sifting through GitHub search results. No guessing which repository is the real one.

Install. mpak install salesforce-mcp downloads the MCPB bundle, extracts the server code, resolves dependencies from the vendored package (no install-time resolution, no conflicts with your existing environment), and writes the runtime configuration. One command. No manual steps.

Run. mpak run salesforce-mcp starts the server using the configuration declared in the bundle. The correct command, the correct arguments, the correct environment variable mapping. Point your agent client at the running server and the MCP connection is live. Tools, resources, prompts, whatever the server exposes, are available to your agent immediately.

Three commands. Discovery to running in under a minute. Compare that to the two-hour manual process described above, multiplied by every server your deployment requires.

The Security Layer

Speed without security is a liability. Installing MCP servers faster only helps if the servers are trustworthy. An MCP server has broad access by design; it’s the bridge between your agent and your business systems. A compromised or carelessly built server can read your customer data, make unauthorized API calls, cache credentials, or exfiltrate information through undeclared network connections.

Every package published to mpak goes through the MCP Trust Framework (MTF), the security standard published at mpaktrust.org. The scanning pipeline evaluates servers across multiple dimensions:

Permissions. Does the server declare what it accesses? Does the declared scope match the actual code? A calendar server that requests filesystem access beyond its declared scope gets flagged.

Dependencies. Are all dependencies known, versioned, and free of published CVEs? The scanner audits the full dependency tree against vulnerability databases. Unresolved or vulnerable dependencies lower the trust score.

Code analysis. Static analysis scans for malicious patterns: data exfiltration, credential harvesting, unauthorized network access, obfuscated code. The scanner runs on every publish, not just the initial submission.

Behavioral monitoring. The server runs in an instrumented sandbox. Network requests, filesystem access, resource consumption: everything is monitored and compared against the declared capabilities. Servers that deviate from their declarations at runtime get flagged, regardless of what the source code looks like.

The result is a trust score visible on every server listing at mpak.dev. Developers see it before they install. Security teams can set minimum thresholds, like “only servers scoring 70+ deploy to production.” The trust score isn’t a binary pass/fail. It’s a transparent breakdown across each dimension, giving organizations the detail they need to make informed decisions.

Standardized Packaging

mpak distributes servers as MCPB bundles, a standardized packaging format designed for MCP servers. A bundle contains the server code, vendored dependencies, metadata (name, version, description, author, license), and runtime configuration (start command, arguments, environment variables, required permissions). Everything the registry and runtime need in a single artifact.

Vendored dependencies are the key innovation for installation reliability. Traditional package managers resolve dependencies at install time, pulling packages from remote registries and hoping the versions align with your environment. MCPB bundles ship with dependencies included. Install is extraction, not resolution. No network calls to PyPI or npm. No version conflicts with your existing packages. The bundle works the same on every machine because it carries its own dependency tree.

For a detailed walkthrough of the bundle format, see The MCPB Bundle Format.

Enterprise Value

For enterprise security teams evaluating AI agent deployments, mpak answers the question that blocks most approvals: “Where are these tools coming from, and who vetted them?”

The answer shifts from “developers found them on GitHub” to “developers install them from a registry with automated security scanning, trust scores, and transparent evaluation criteria.” That’s a fundamentally different risk profile.

mpak also addresses the “shadow AI” problem, where developers build agent integrations with unvetted tools because there’s no sanctioned alternative. When the official path is faster and safer than the ad hoc path, developers use the official path. mpak makes the right thing the easy thing. Search, check the score, install, run.

Organizations can enforce trust policies across their deployments. Set a minimum trust score. Require permission declarations. Block servers with unresolved CVE findings. These policies are enforceable because the data is structured and machine-readable. The trust evaluation becomes infrastructure, not a manual review process that scales linearly with the number of servers.

Why NimbleBrain Built mpak

We built mpak because we needed it. Every NimbleBrain engagement requires connecting AI agents to business systems: five to ten MCP servers per deployment, across CRMs, databases, communication platforms, and internal tools. We were sourcing servers ad hoc, building custom integrations, and answering the same security questions on every engagement. The distribution problem was our distribution problem.

So we built the infrastructure. The registry. The packaging format. The trust framework. The scanner. And we open-sourced all of it, because MCP distribution infrastructure should be a public good, not a competitive advantage locked behind a paywall. That’s The Anti-Consultancy applied to the tool layer: build what the ecosystem needs, publish it openly, and let the work compound whether NimbleBrain is in the room or not.

The registry is at mpak.dev. The trust framework is at mpaktrust.org. The source code is on GitHub. Install the CLI, search the registry, and start connecting your agents to the tools they need.

For a developer walkthrough of publishing your own servers, see Publishing to mpak. For the security standard in detail, see MCP Trust Framework In Detail.