I've been experimenting with MCP for a while, and one of the things I like about it is how easy it is to get started. You find an MCP server, add it to Claude, Cursor, VS Code, or another compatible client, configure the credentials it needs, and you're basically done.
For a developer working locally, this model makes a lot of sense.
But while working with more MCP servers, I started wondering what this setup looks like when you move beyond a single developer.
Let's say a team has 10 developers. Some use Claude Code, some use Cursor, and others use VS Code. The team also has MCP servers for GitHub, databases, internal APIs, monitoring, and maybe a few tools they built themselves.
The simple architecture starts becoming something like this:
Technically, there's nothing wrong with this. Every developer can configure the MCP servers they need and continue working.
The problem is that you now have configuration, credentials, and access distributed across multiple machines. At that point, managing MCP starts looking less like configuring a developer tool and more like managing infrastructure.
Credentials become surprisingly important
Credentials were the first thing that made me think about this problem.
Suppose you have an MCP server that connects to an internal API. When you're the only person using it, keeping the credentials locally is simple enough. But if 20 developers need access to that same service, you have to decide how those credentials should be managed.
You could distribute the same credentials to everyone, but then they're stored across many developer machines. You could create separate credentials for every developer, which is better for isolation but creates more administrative work.
Then normal lifecycle problems start appearing. Someone leaves the company, an API key needs to be rotated, a developer changes teams, or an MCP server moves somewhere else.
None of this is unique to MCP. We've already dealt with the same problems with databases, internal APIs, cloud infrastructure, and CI/CD systems.
The interesting part is that MCP is starting to expose those same infrastructure problems in a new place.
Access control is another problem
Once multiple people use the same MCP infrastructure, authentication alone isn't enough.
You also need to decide what each person should be allowed to use.
For example, maybe everyone on the engineering team should be able to use an MCP server that searches GitHub. At the same time, you might have another MCP server connected to production infrastructure that should only be available to a smaller group.
It can get even more granular than that. A user might be allowed to call read-only tools while another user can call tools that modify data.
With a local MCP configuration, the MCP client generally connects directly to the server:
That simplicity is great, but it also means there isn't necessarily a central place to make these decisions.
Auditing gets more interesting when AI is involved
Another question I hadn't thought much about initially was auditing.
If an AI assistant uses an MCP server to interact with GitHub, a database, an internal API, or some other company system, at some point you may want to understand what happened.
For example:
In a company environment, it can be useful to know which user initiated the interaction, which MCP server was used, which tool was called, and when it happened.
Again, this isn't particularly exciting infrastructure. Logging and auditing rarely are. But these are usually the boring problems that start becoming important once something moves from experimentation into regular use.
This started reminding me of API gateways
The more I thought about it, the more the problem reminded me of how APIs evolved.
A simple application can connect directly to an API:
Client → API
As systems become larger, we often introduce another layer:
Client → API Gateway → Services
The gateway gives us a central place for things like authentication, authorization, routing, policies, and logging.
That made me wonder whether MCP might eventually need a similar pattern.
Instead of every client knowing how to connect to every MCP server, clients could connect through a common layer.
Credentials could be managed centrally. Access decisions could happen in one place. The underlying MCP servers could also move or change without requiring every developer to update their configuration.
Of course, this adds complexity. If you're one developer running two MCP servers on your laptop, introducing a gateway would probably make your setup worse rather than better.
But for a team sharing MCP infrastructure, I think the tradeoff becomes more interesting.
I decided to build the idea and see what happens
At some point I realized I could keep thinking about the architecture or actually build it and discover where it breaks.
So I started an open-source project called MCPlama.
MCPlama is my attempt at the gateway/control-plane approach. MCP clients connect through it, while the platform handles the infrastructure around the MCP servers.
The basic architecture looks something like this:
The goal isn't to change MCP itself. Clients and servers still communicate using MCP. The gateway provides a place to manage the parts around that communication: identity, credentials, policies, routing, and auditing.
One design decision I spent some time thinking about was where the MCP servers themselves should run.
Putting everything inside the gateway would make deployment easier, but I wasn't comfortable with the idea of arbitrary MCP servers sharing the same process and environment as the control plane.
Instead, I started separating the management side from the execution side.
That introduces additional infrastructure, but it also creates a clearer boundary between managing MCP servers and actually executing them.
How are teams actually managing MCP?
As adoption grows, I think the conversation around MCP will gradually shift from "How do I connect this server?" to "How do we actually manage all of this?"
That means figuring out how teams share MCP servers, where credentials should live, how permissions should work, how private servers are deployed, and how organizations keep track of what their AI clients are doing.
I'm curious how teams using MCP today are approaching these problems. Are developers still configuring everything individually? Have you built some shared infrastructure around it? Or are you using MCP across a team and haven't run into these problems at all yet?
I'd genuinely like to hear how others are solving this.
Top comments (1)
The read-only-vs-modify-tools split you mentioned is the part I'd flag as the actually hard problem, harder than credentials. Credentials are a solved problem (secrets managers, rotation, short-lived tokens) — you're just wiring MCP into infra that already exists. But per-tool authorization inside a single MCP server is genuinely new: most servers today expose a flat tool list with no way for the gateway to say "this identity may call search_github_issues but not delete_deployment on the same server." Until MCP servers themselves annotate tools with a risk/capability tier (or at minimum a stable read/write flag), a gateway can only enforce policy at the granularity of "can reach this server at all," not "can call this specific tool." That's the gap I'd want MCPlama (or any gateway) to push the ecosystem toward — a lightweight tool-level metadata convention servers opt into, similar to how OAuth scopes let a gateway reason about intent without parsing every endpoint by hand.