Mozilla.ai introduced mcpd, a tool designed so AI agents don't have to deal with piles of different scripts and configs every time they're deployed. Why does this matter for you if you work with agents, run CI tests, or just want reproducibility across environments? Because mcpd promises to turn what's fragile and scattered today into a single declarative file that tells how an agent's tools run. (blog.mozilla.ai)

What is mcpd

mcpd is a toolchain and runtime created by Mozilla.ai to handle MCP (Model Context Protocol) servers and the "tools" agents use. Think of mcpd as the agents' equivalent of requirements.txt or package.json for apps: a file where you declare, lock versions, and configure the services an agent needs. (blog.mozilla.ai)

And what does that mean in practice? That with a single file you can pin versions, define environment-specific settings, and run everything consistently on your laptop, in CI, and in production. The official post even shows an example .mcpd.toml configuration to illustrate it. (blog.mozilla.ai)

The problem it solves

Today many agent frameworks expect each agent to spin up the servers and tools it needs by itself: using uvx, npx, Docker, or homemade scripts. That works for experiments, but in production it becomes a nightmare: scattered versions, inconsistent secret handling, and drift between local, CI, and production. mcpd proposes to centralize that responsibility. (blog.mozilla.ai)

With mcpd, instead of each agent starting its own servers, there's a single definition of servers and tools that mcpd launches and manages. Agents connect to that service and no longer need to duplicate startup logic. (blog.mozilla.ai)

A short example

The post includes a snippet of .mcpd.toml that shows how servers and packages are declared. For example:

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

This kind of block lets you lock versions and expose the functions your agent can call, all from the same file. (blog.mozilla.ai)

Where mcpd is headed: proxy, plugins and deployment

Mozilla.ai doesn't just see it as a tool launcher. They plan to evolve mcpd so it can act as a proxy layer between agents and tools. What does that open up for you? Centralized monitoring, policies and limits, and places to mitigate risks like prompt injection. Those are practical levers when you run agents at scale. (blog.mozilla.ai)

There will also be a plugin system to extend features without touching the core, and future backend options to scale on real infrastructure, including containers and Kubernetes. The idea is to keep simple compatibility (for example stdio) while adding more robust backends for production. (blog.mozilla.ai)

How to try it today

mcpd has been available since the August 21, 2025 announcement, and Mozilla.ai published a Python SDK along with docs and repos to get started. You can begin with a minimal config, run mcpd daemon, and connect agents with a few lines using the SDK. (blog.mozilla.ai)

If you work on projects where agents call multiple services, or if your CI pipeline breaks because environments differ, trying mcpd will quickly show how much you can simplify. Think of it as spending a few hours now to save weeks of debugging later.

Final thoughts

mcpd isn't just a new tool; it's a discipline proposal for agent builders: declare, lock, and orchestrate tools from a single place. That sounds simple, but it changes day-to-day operations a lot when multiple teams, CI pipelines, and production are involved.

Want to get a messy agents project under control? mcpd looks like a useful piece for that puzzle, and it's worth reviewing and trying the minimal flow with your stack. (blog.mozilla.ai)