MCP servers are the new integrations layer. Every AI agent platform needs them. Every enterprise is asking about them. And deploying them consistently across environments is surprisingly hard.

The root cause is distribution. MCP servers ship as source code or package manager references. Every deployment means fetching dependencies, resolving versions, hoping nothing changed since you last tested. That’s fine for local development. It’s a problem for production.

We spent months building infrastructure to fix this. The solution is MCPB (MCP Bundles): self-contained packages with server code, all dependencies, and a manifest describing how to run it. No network calls at startup. No version drift. Deploy the same artifact everywhere.

When we analyzed the MCP ecosystem, the first question was: can this server be bundled?

The State of MCP Servers

We wrote a script to analyze the official MCP registry and categorize every server by whether it can be packaged for deployment. Here’s what we found:

Category	Count	Percentage
Total servers	3,454	100%
Bundleable (has source repo)	2,739	79.3%
Remote-only (no source code)	457	13.2%
No source (invalid/missing URL)	258	7.5%

Over 700 servers (20.7%) can’t be packaged for local or on-prem deployment. They’re either hosted services with no source code, or have broken/missing repository links. If the vendor goes down or the link rots, the integration breaks.

The 80% with source repos sounds promising, but that’s just the first hurdle. When we actually tried to build and run these servers, we hit:

Build failures: Missing dependencies, outdated lockfiles, broken scripts
Runtime failures: Servers that build but don’t start
Protocol issues: Servers that start but don’t respond correctly to MCP requests
Missing transports: stdio-only servers that can’t run remotely

MCP is young. Most servers were built for experimentation, not production deployment.

Enterprises want to deploy these servers. Platforms want to offer them. The gap between “source exists” and “actually works” matters.

The analysis script is available in our mcp-registry-analysis repo if you want to run it yourself.

Our Approach: Curated, Not Comprehensive

registry.nimbletools.ai takes a different approach. We don’t list everything. We list what works.

Every server in our registry:

Has been tested end-to-end - We deploy it, send MCP requests, verify responses
Starts fast - Cold start under 5 seconds for MCPB bundles
Includes deployment metadata - Resource limits, health checks, scaling policies
Has verified artifacts - SHA256 checksums, deterministic builds where possible

This means we have fewer servers. Currently close to 50. But every one of them works.

The _meta Schema: Registry Sugar for Production

The official MCP registry schema defines what a server is: name, version, description, packages, environment variables. It doesn’t define how to run it.

We extend the schema with a _meta block that carries everything a runtime needs. Think of it as registry sugar, additional metadata that makes servers production-ready without breaking compatibility.

Here’s a real example:

{
  "$schema": "https://registry.nimbletools.ai/schemas/2025-12-11/nimbletools-server.schema.json",
  "name": "ai.nimbletools/echo",
  "version": "0.1.3",
  "title": "Echo",
  "packages": [
    {
      "registryType": "mcpb",
      "identifier": "https://api.mpak.dev/internal/packages/@nimblebraininc/echo/versions/0.1.3/download",
      "version": "0.1.3",
      "fileSha256": "d09a1aee581d764411d5f902b842f4daddad1e21b8fb9d84fa2da73b7f022cf9",
      "transport": { "type": "streamable-http", "url": "http://localhost:8000/mcp" }
    }
  ],
  "_meta": {
    "ai.nimbletools.mcp/v1": {
      "runtime": "python:3.13",
      "status": "active",
      "container": {
        "healthCheck": {
          "enabled": true,
          "path": "/health",
          "port": 8000,
          "interval": 10
        },
        "startupProbe": {
          "initialDelaySeconds": 5
        }
      },
      "resources": {
        "requests": { "cpu": "250m", "memory": "256Mi" },
        "limits": { "cpu": "1000m", "memory": "512Mi" }
      },
      "scaling": {
        "enabled": true,
        "minReplicas": 1,
        "maxReplicas": 3,
        "targetCPUUtilizationPercentage": 80
      },
      "deployment": {
        "protocol": "http",
        "port": 8000,
        "mcpPath": "/mcp"
      },
      "capabilities": {
        "tools": true,
        "resources": false,
        "prompts": false
      }
    }
  }
}

The _meta block is namespaced (ai.nimbletools.mcp/v1) so it doesn’t conflict with other extensions. Every field maps directly to infrastructure:

Field	Maps To
`runtime`	Container base image
`container.healthCheck`	Kubernetes liveness probe
`container.startupProbe`	Kubernetes startup probe
`resources.requests/limits`	Pod resource quotas
`scaling`	Horizontal Pod Autoscaler config
`deployment`	Service port and path configuration
`capabilities`	Feature flags for client optimization

When a runtime reads this schema, it knows exactly how to deploy the server. No guessing. No manual configuration.

The key insight: extend, don’t replace. We stay compatible with the official schema. Tools that don’t understand _meta simply ignore it. Tools that do get production-ready deployment metadata.

Fast Cold Starts

When an agent needs a tool, waiting 60 seconds for cold-start kills the experience.

Our target: under 5 seconds from deploy to ready.

Pre-built Bundles

MCPB bundles include all dependencies. No npm install at deploy time. No pip install. The bundle extracts and runs.

Minimal Base Images

We build purpose-built runtime images for each server type:

mcpb-python - Python servers (FastMCP, etc.)
mcpb-node - Node.js servers
mcpb-binary - Compiled binaries (Go, Rust)
mcpb-supergateway-python - stdio servers via HTTP gateway

Optimized for fast startup, minimal footprint.

Health Check Optimization

The _meta schema includes startup probe configuration:

"startupProbe": {
  "initialDelaySeconds": 5
}

This tells the runtime: “Don’t bother checking health for the first 5 seconds. The server is starting.” Avoids premature failure detection.

Measured Results

Current cold start times for our bundled servers:

Runtime	Cold Start
Python (FastMCP)	~5 seconds
Node.js	~4 seconds
Go (binary)	~2 seconds

Health check timing is configurable via _meta startup probe settings.

Security: Why Bundles Beat Package Managers

Most MCP servers install dependencies at runtime. Every startup is a supply chain risk.

A typical MCP server startup looks like this:

# What happens when you run a Python MCP server
uv run mcp-server-postgres
# → Connects to PyPI
# → Downloads dozens of packages
# → Resolves dependencies dynamically
# → Finally starts the server

PyPI could be compromised. A dependency could be hijacked. The package you audited last month could be different today.

MCPB bundles eliminate this.

Inert Packages, No Network on Startup

A bundle is a ZIP file containing:

The server code
All dependencies, pre-installed
A manifest describing how to run it

When you deploy a bundle:

# What happens when you run an MCPB bundle
unzip bundle.mcpb
python -m server
# → No network calls
# → No package resolution
# → Runs exactly what's in the ZIP

The bundle is inert. It doesn’t phone home. It doesn’t check for updates. It runs what you shipped.

This matters for:

Air-gapped environments: Bundles work offline
Audit requirements: What you tested is what runs
Incident response: No “but the dependency changed” mysteries

Integrity Verification

Every MCPB bundle in our registry includes a SHA256 hash:

{
  "identifier": "https://api.mpak.dev/internal/packages/@nimblebraininc/echo/versions/0.1.3/download",
  "fileSha256": "d09a1aee581d764411d5f902b842f4daddad1e21b8fb9d84fa2da73b7f022cf9"
}

Before deployment, the runtime verifies the hash matches. If someone tampers with the bundle, deployment fails.

For enterprises needing more control, we support private registries with internal audit workflows and custom signing.

We’re working toward reproducible builds and signed build provenance.

Verification Testing

Schema validation isn’t enough. A server can have a valid manifest and still not work.

We run verification tests that actually talk MCP:

Extract the bundle to a temp directory
Start the server process
Send MCP initialize request
Send tools/list request
Validate the response matches expected schema
Kill the process, clean up

This catches “looks valid but doesn’t work” before the bundle reaches users.

For each server in our registry, we also define E2E test fixtures:

{
  "environment": { "API_KEY": "${API_KEY}" },
  "tests": [{
    "name": "Query IP info",
    "tool": "lookup_ip",
    "arguments": { "ip": "8.8.8.8" },
    "expect": { "type": "text", "contains": "Google" }
  }]
}

The test runner deploys the server, sets secrets, calls tools, and validates responses. This runs in CI on every change to the registry.

If a test fails, the server doesn’t ship.

The API

The registry implements the MCP Registry API v0.1 specification:

# List all servers
curl https://registry.nimbletools.ai/v0.1/servers

# Search
curl "https://registry.nimbletools.ai/v0.1/servers?search=weather"

# Get specific version
curl https://registry.nimbletools.ai/v0.1/servers/ai.nimbletools%2Ffinnhub/versions/latest

# Health check
curl https://registry.nimbletools.ai/v0.1/health

Interactive API docs: registry.nimbletools.ai/docs

We’re compatible with any client that speaks the official spec. The _meta extension is additive, clients that don’t need it can ignore it.

FAQ

How many MCP servers can actually be deployed to production?

We analyzed 3,454 servers in the official MCP registry. Only 79.3% have source code available for bundling. Of those, many fail to build or run correctly. Our curated registry includes ~50 servers that have been tested end-to-end.

What is MCPB?

MCPB (MCP Bundles) is a packaging format for MCP servers. A bundle contains the server code, all dependencies, and a manifest describing how to run it. No package manager calls at startup. Deploy the same artifact everywhere.

How fast do MCP servers start?

With MCPB bundles and our optimized runtime images, cold starts are under 5 seconds. Python servers start in ~5 seconds, Node.js in ~4 seconds, and Go binaries in ~2 seconds.

Can I run MCP servers in air-gapped environments?

Yes. MCPB bundles are inert ZIP files with no network dependencies. They don’t phone home or check for updates. Extract and run.

Is your registry compatible with the official MCP registry spec?

Yes. We implement the MCP Registry API v0.1 specification. Our _meta extension is additive. Clients that don’t understand it simply ignore it.

Get Started

Browse the registry at registry.nimbletools.ai.

Deploy with NimbleTools:

ntcli srv deploy ai.nimbletools/ipinfo

Or use the API directly in your own tooling.

Need a specific server? Email hello@nimblebrain.ai or request on Discord.

The bet: curated, tested, fast-starting servers become the standard. The registry is how we get there.