mcpd-proxy: Centralized Tool Access for AI agents in VS Code, Cursor, and Beyond

With mcpd-proxy, teams no longer juggle multiple MCP configs. Run all servers behind one proxy and give every developer the same zero-config access inside their IDE.

Peter Wilson

Peter Wilson

— 6 min read
mcpd-proxy: Centralized Tool Access for AI agents in VS Code, Cursor, and Beyond

A few weeks ago, we were speaking with a Principal Data Scientist leading engineering teams at Microsoft’s AI Consulting Practice, a group that works closely with enterprise clients deploying real-world AI agents. 

They’d been experimenting with mcpd, our ‘requirements.txt for agentic systems’, and saw clear potential for helping internal DevOps teams.  When we asked what would make mcpd even more useful for their daily workflows, they said something that instantly clarified the next step for us:

I need a way to provide a URL and an integration to my team, so they can use all the tools they need in their daily development workflows via VS Code.

That single line validated a direction we had discussed internally, but hadn’t prioritized yet. Hearing it from someone who sees dozens of real-world agent setups every year made it obvious: we needed a shared entry point for MCP tools across developer IDEs.

And so mcpd-proxy was born.

Conversations like this are shaping how we evolve the any-suite. It’s one thing to design for flexibility, it’s another to ensure it fits how teams actually build, test, and ship AI applications in production. We're grateful to see peers at companies like Microsoft validate and challenge our direction.

First, what is mcpd?

mcpd is a tool to declaratively manage Model Context Protocol (MCP) servers, providing a consistent interface to define and run tools across environments, from local development to containerized cloud deployments. The goal of mcpd is to eliminate the ‘faff’ of connecting AI agents to external tools (like databases, private APIs, etc.) by abstracting away the complexities of their configuration.

In its current form, mcpd is a simple server you run alongside your application (e.g., as a sidecar in a container). Instead of your application’s code having to configure 10 different clients for 10 or more different tools, it just points to an mcpd instance via a URL. mcpd handles all the configuration, versioning and endpoint management for those tools.

Here’s a simplified look at this sidecar model:

mcpd Sidecar Model: Your application container talks to one mcpd instance, which in turn orchestrates multiple MCP servers. With mcpd-proxy, developers can access all of them through a single config entry.

This is powerful for a single app, but the person we were talking to had a ‘team’ problem. Their question of ‘how do I give my team a URL’ suggests a different model.

They didn't want every developer to run their own mcpd instance. They wanted to run mcpd centrally, as a shared service, and have one entrypoint to it.

This exposed a gap in the ecosystem, which led us right to...

The Problem Nobody Talks About

Imagine this: You've set up a central mcpd with version control safe configs, pinned server versions, and allowed tools. It's running in your shared dev environment. Great!

Now your developers open Visual Studio Code or Cursor. What happens next?

They still have to connect their IDEs to every individual server. 

Here’s what it looks like in practice:

Option A: Manually add and update each MCP server individually in your IDE’s settings or mcp.json. Keep a track of your environment variables and secrets for each MCP server.  Remember to update configs when new servers are added or old ones change. Hope everyone’s IDEs stay in sync.

Option B: Well… there wasn’t really an option B.

That's the “last mile”. The gap between ‘we manage MCP servers centrally’ and ‘developers have seamless, zero-config access to MCP servers inside their IDEs.’

Introducing mcpd-proxy: One config entry for all your tools

We built mcpd-proxy to solve this. It's an MCP server that connects to your mcpd instance and exposes all your managed MCP servers through a single endpoint.

Your developers configure it once in their IDE settings (e.g. in their mcp.json):

{
  "servers": {
    "mcpd": {
      "type": "stdio",
      "command": "npx",
      "args": "@mozilla-ai/mcpd-proxy",
      "env": {
        "MCPD_ADDR": "https://<your-mcpd-instance.com>",
        "MCPD_API_KEY": "<your-key>"
      }
    }
  }
}

That's it. Your developers now have access to every tool from every server you've provisioned. If the platform operator adds a new server to mcpd, that change is reflected in every developer’s IDE when they start the mcpd-proxy MCP server.

What It Actually Looks Like

Using a minimal sample .mcpd.toml configuration file to limit available tools to just what we needed in the running remote mcpd instance:

[[servers]]
  name = "github"
  package = "docker::ghcr.io/github/github-mcp-server@latest"
  tools = ["list_pull_requests", "pull_request_read"]
  required_env = ["GITHUB_PERSONAL_ACCESS_TOKEN"]
[[servers]]
  name = "slack-mcp"
  package = "npx::@zencoderai/slack-mcp-server@0.0.1"
  tools = ["slack_post_message", "slack_list_channels"]
  required_env = ["SLACK_BOT_TOKEN", "SLACK_TEAM_ID"]

And environment variables configured according to mcpd’s exported secrets.prod.toml file:

[servers]
  [servers.github]
    [servers.github.env]
      GITHUB_PERSONAL_ACCESS_TOKEN = "${MCPD__GITHUB__GITHUB_PERSONAL_ACCESS_TOKEN}"
  [servers.slack-mcp]
    [servers.slack-mcp.env]
      SLACK_BOT_TOKEN = "${MCPD__SLACK_MCP__SLACK_BOT_TOKEN}"
      SLACK_TEAM_ID="${MCPD__SLACK_MCP__SLACK_TEAM_ID}"

Then starting the MCP server in VS Code gives us this output:

[info] Starting server mcpd
[info] Connection state: Starting
[info] Starting server from LocalProcess extension host
[info] Connection state: Starting
[info] Connection state: Running
[info] Discovered 4 tools

Those tools show up as: github__list_pull_requests, github__pull_request_read, slack_post_message; namespaced automatically so nothing collides.

Pro-tip: In VS Code you might see mcp_mcpd_github__list_pull_requests shown in places as the tool name, VS Code kindly prefixes the tools with ‘mcp’ and the server name you configured so you always know where it came from.

In Cursor or VS Code, you just start an agent chat:

"Check all open PRs the mozilla-ai/mcpd repo that have been waiting for review for more than 5 hours, and post a list to the Slack channel named #code-review."

The agent can now call github__list_pull_requests, github__get_pull_request, and slack__slack_post_message directly. It doesn't know (or care) whether these are different servers managed by different teams—it just coordinates them to get your work done.

Here’s what it looks like in the VS Code chat:

And this is what ended up in Slack:

Why This Matters for Platform Teams

For teams managing shared developer infrastructure, whether you're at a startup or a company like Microsoft, mcpd-proxy gives you centralized control, zero-config onboarding, and smoother scaling of agent toolchains.

It decouples agent access from server orchestration, making life easier for both platform operators and the engineers using the tools.

Take Microsoft's use case: a platform team manages mcpd centrally, provisioning and maintaining MCP servers in one place. Developers just point their IDE to a single URL and instantly get access to every tool they need.

  • No local server processes to manage. 
  • No individual configs to maintain. 
  • No version mismatches across the team.

The platform team centrally controls:

  • Which tools are available
  • Which versions of MCP servers to run
  • Access policies and rate limiting
  • Health monitoring and restarts

… Developers just get a single stable URL that simply works.

Here’s a before and after of how things might look for your engineers:

Before

After

We Need Your Feedback

We built mcpd-proxy because a user asked for it, but we're curious: does this solve a problem you have?

If you're:

  • Managing MCP servers for a team
  • Tired of configuring multiple MCP servers individually
  • Wanting centralized control with easy client access

… then we’d love your feedback.

Try mcpd-proxy and tell us where it works and where it doesn't.

We also built mcpd-proxy using our mcpd JavaScript SDK, which might be useful if you’re developing an agentic JS app and want to easily use mcpd-provided tools (spoiler: we’ve got a Python SDK too)

Our mission at Mozilla.ai is to help people work better with AI, safely and on their own terms. Part of that is making tools accessible; not just theoretically possible, but actually usable in your daily workflow.

This is an early release. We want to know what breaks, what's confusing, and what you wish it did.

Try it out, and let us know.

mcpd binary

PyPI 

npmjs 

Read more