The Model Context Protocol servers repository has 87,417 GitHub stars and 11,026 forks. The maintainers explicitly warn that these are “reference implementations” and “not production-ready solutions.” This gap between popularity and deployment readiness exposes the fundamental infrastructure problem in agent tooling: nobody has built the package manager, security model, or standard deployment pattern that makes third-party agent tools safe and repeatable.
The MCP Registry exists at registry.modelcontextprotocol.io, but it only houses a small number of reference servers maintained by the steering group. The community has built servers across 10+ languages (C#, Go, Java, Kotlin, PHP, Python, Ruby, Rust, Swift, TypeScript), but there is no clear path from “I published a server” to “an agent can safely discover, install, version, and trust this tool.”
This is the npm moment for agent tooling, except nobody has built npm yet.
What MCP Servers Actually Are
An MCP server exposes tools, prompts, and resources to agents through a standardized protocol. The reference implementations include:
- Fetch: Web content retrieval and conversion
- Filesystem: File operations with access controls
- Git: Repository read, search, and manipulation
- Memory: Knowledge graph-based persistence
- Sequential Thinking: Multi-step reasoning scaffolding
Each server runs as a separate process. The agent communicates over stdio or HTTP. The server declares its capabilities (tool signatures, resource schemas, prompt templates) and the agent decides which to invoke.
The protocol itself is well-defined. The distribution problem is not.
The Missing Infrastructure Layer
Discovery Without a Registry
The MCP Registry is a static list. There is no API for agents to query “show me all filesystem servers” or “find a Git server that supports branch diffing.” Agents cannot discover tools dynamically. Developers must manually configure which servers to load.
This works for reference implementations. It does not scale when you have 500 community servers and an agent that needs to assemble a toolchain on the fly.
Installation Without a Package Manager
There is no mcp install git-server@1.2.3. Developers clone repositories, install dependencies, and configure startup scripts. Each server has its own runtime requirements (Node.js, Python, Go binary). There is no dependency resolver, no lock file, no reproducible build.
When an agent needs a tool, a human must:
- Find the server repository
- Read the README
- Install the runtime
- Configure environment variables
- Start the server process
- Point the agent at the server
This is not automation. This is manual IT work.
Versioning Without Semver Enforcement
MCP servers declare tool signatures. If a server changes a tool’s parameters or return type, agents that depend on the old signature break. There is no version negotiation. There is no deprecation policy. There is no way for an agent to say “I need git-server >=1.0.0 <2.0.0.”
The protocol supports capability negotiation (the server tells the agent what it can do), but it does not support version constraints or compatibility guarantees.
Security Without a Trust Model
MCP servers run with the same privileges as the agent process. A filesystem server can read any file the agent can read. A Git server can push to any repository the agent can access. There is no sandboxing, no permission model, no capability-based security.
The reference implementations include warnings like “evaluate your own security requirements” and “implement appropriate safeguards based on your threat model.” This is not a security model. This is a disclaimer.
What a Real Distribution System Needs
| Component | Current State | What’s Missing |
|---|---|---|
| Discovery | Static registry, manual configuration | Queryable API, capability search, dependency graph |
| Installation | Clone repo, install deps, run script | Package manager, dependency resolver, reproducible builds |
| Versioning | No version constraints, breaking changes break agents | Semver enforcement, compatibility matrix, deprecation policy |
| Security | Same privileges as agent, no sandboxing | Permission model, capability tokens, process isolation |
| Hosting | Self-hosted, no SLA, no availability guarantees | Managed hosting, health checks, failover |
| Observability | Logs to stdout, no structured telemetry | Distributed tracing, error aggregation, performance metrics |
Architecture: What a Solution Might Look Like
A real MCP distribution system would need:
Registry Service: A queryable API that indexes servers by capability, language, version, and security profile. Agents query “find me a Git server that supports branch diffing and has been security-audited” and get back a ranked list.
Package Manager: A CLI and library that resolves dependencies, installs runtimes, and manages server lifecycles. mcp install git-server@1.2.3 downloads the server, installs dependencies, and starts the process. mcp update checks for new versions and handles migrations.
Security Boundary: A capability-based permission model. The agent grants the server specific permissions (read this directory, access this API key, call this webhook). The server runs in a sandbox (container, VM, or WASM runtime) with no access to the host system beyond what the agent explicitly grants.
Version Negotiation: The agent declares version constraints. The registry returns compatible servers. The package manager installs the highest compatible version. Breaking changes trigger explicit migration workflows.
Observability Layer: Structured logs, distributed tracing, and error aggregation. The agent knows when a server is slow, failing, or misbehaving. The registry tracks server reliability and surfaces it in search results.
Code Snippet: What Installation Could Look Like
This is speculative. No implementation exists.
import { MCPClient, ServerRegistry } from '@mcp/client';
const client = new MCPClient({
registry: 'https://registry.modelcontextprotocol.io',
sandboxMode: 'container',
permissions: {
filesystem: { read: ['/workspace'], write: ['/workspace/output'] },
network: { allowedDomains: ['api.github.com'] }
}
});
// Agent queries registry for compatible servers
const gitServer = await client.install({
capability: 'git',
version: '^1.2.0',
securityProfile: 'audited'
});
// Server runs in isolated container with granted permissions
const result = await gitServer.call('git_diff', {
repo: '/workspace/myproject',
base: 'main',
head: 'feature-branch'
});
// Client tracks telemetry and handles failures
if (result.error) {
console.error('Server failed:', result.error);
await client.rollback(gitServer);
}The key pieces:
- Registry query: Agent specifies capability, version constraint, and security requirements
- Sandboxing: Server runs in a container with explicit permission grants
- Lifecycle management: Client installs, starts, monitors, and rolls back servers
- Telemetry: Failures are logged and surfaced to the agent
Failure Modes Nobody Has Addressed
Server Disappears: A community server is unpublished or the repository is deleted. Agents that depend on it break. There is no mirror, no archive, no fallback.
Breaking Change: A server updates its tool signatures. Agents that depend on the old signature fail silently or produce incorrect results. There is no version pinning, no compatibility check, no migration path.
Malicious Server: A server is published with a backdoor. It exfiltrates data or executes arbitrary code. There is no code signing, no security audit, no trust chain.
Resource Exhaustion: A server leaks memory or consumes CPU. The agent process slows down or crashes. There is no resource limit, no health check, no automatic restart.
Dependency Hell: Two servers depend on incompatible versions of the same library. The agent cannot load both. There is no dependency isolation, no virtual environment, no conflict resolution.
What the Reference Implementations Teach Us
The MCP servers repository is valuable because it exposes the problem clearly. The protocol works. The SDK works. The servers work. But the infrastructure layer between “here’s a tool” and “agents can use this tool safely” does not exist.
The maintainers are explicit about this. The servers are reference implementations, not production solutions. They demonstrate the protocol, not the deployment model.
The community has responded by building hundreds of servers. But without a distribution system, each server is an island. Agents cannot discover them. Developers cannot install them reliably. Security teams cannot audit them. Operations teams cannot monitor them.
Technical Verdict
Use MCP servers when:
- You are building a single-agent system with a fixed set of tools
- You control the deployment environment and can manually configure servers
- You are prototyping and do not need production-grade security or reliability
- You want to learn the protocol and contribute reference implementations
Avoid MCP servers when:
- You need agents to discover and install tools dynamically
- You have security requirements beyond “trust the server completely”
- You need version pinning, dependency resolution, or rollback capabilities
- You are building a multi-tenant system where different agents need different tool sets
- You need observability, health checks, or SLA guarantees
The MCP protocol is solid. The distribution infrastructure is missing. If you are building agent tooling, the opportunity is not in writing more servers. The opportunity is in building the package manager, security model, and hosting layer that makes those servers usable at scale.