Meet mcpd: requirements.txt for agentic systems

Run your agents, not your infrastructure.

In agentic systems, tools and services often live in different languages, environments, and lifecycle patterns. Managing agents across development, CI, and production often rely on fragile, ad-hoc combinations of startup scripts, environment variables, and process control hacks.

That’s where mcpd comes in.

What Is mcpd?

mcpd is a toolchain and runtime created by Mozilla.ai to make working with Model Context Protocol (MCP) servers seamless across environments: local, development, CI, and production.

At its simplest, mcpd is to agents what requirements.txt or package.json is to applications: a declarative way to list, pin, and configure the tools your agents need, across environments.

With a single config file, you can:

• Pin exact versions of MCP servers and tools
• Define environment-specific settings without polluting source control
• Share reproducible configurations across teams and CI/CD
• Manage secrets separately and securely
• Run everything locally, in CI, or in production with the same command: mcpd daemon

Below is an example of what an mcpd config file (.mcpd.toml) looks like:

[[servers]]
  name = "fetch"
  package = "uvx::mcp-server-fetch@2025.4.7"
  tools = ["fetch"]

[[servers]]
  name = "time"
  package = "uvx::mcp-server-time@2025.8.4"
  tools = ["get_current_time", "convert_time"]

Why We Built mcpd

In most current agentic frameworks, each time you run an agent, the agent itself is responsible for starting the MCP servers it needs, whether that’s via uvx, npx, Docker, or other runtime commands. This means every framework is duplicating the same process management logic, often in slightly different ways.

That approach works for small experiments, but it quickly becomes hard to manage in production:

• Version pinning and updates are manual
• Secrets are handled inconsistently
• Local, CI, and production setups drift apart over time

mcpd changes that model. Instead of every agent spinning up its own MCP servers, mcpd becomes the single place where those servers are defined, versioned, and launched. Agents connect to mcpd, and mcpd takes care of running and managing the tools, consistently across environments.

The Future of mcpd

We’re building mcpd as an open, extensible platform, something that not only manages tools but also helps secure and observe how agents interact with them.

mcpd as a Proxy

One of the directions we’re exploring is evolving mcpd into a proxy layer between agents and their tools. In this model, every request an agent makes to an MCP server would flow through mcpd, creating a single point where we could:

• Monitor usage and reliability
• Add policies or limits
• Build safeguards against prompt injection and other risks

Plugins and Extensibility

Alongside this, we’re working on a plugin system that would allow these kinds of features to be added without modifying the mcpd core. We’ll provide some official plugins and make it easy for the community to build their own—for example, to enforce internal governance or log specific usage metrics.

Future Backends and Deployment Options

mcpd currently uses a simple, reliable pattern: agents communicate with it over HTTP, and mcpd manages tools via stdio. This works well for local setups and CI.

But we’re designing mcpd to scale across real-world infrastructure. In the future, it will support multiple backends, including:

• Containerized tool runtimes
• Kubernetes-managed deployments (via a dedicated operator)
• stdio for simplicity and legacy compatibility

Why This Matters

By centralizing configuration and communication, mcpd makes agent development simpler, safer, and more consistent across environments. Whether you’re experimenting locally, running automated tests in CI, or deploying at scale, you can rely on the same setup and behavior.

Try It Today

mcpd is available now, along with a Python SDK for integrating it directly into your agents.