The Model Context Protocol solved a real problem elegantly: agents need to reach tools and data, and everyone was inventing a bespoke integration per pairing. A shared protocol was obviously right, and adoption has been fast.
It also quietly created an enterprise problem, in the way that good abstractions often do. When connecting an agent to a tool becomes trivial, agents connect to a lot of tools, and nobody is tracking which.
The shape of the mess
The pattern is recognisable to anyone who lived through early microservice adoption. Each team stands up the MCP servers its agents need. Each configures its own credentials for the systems behind them. Each decides independently what an agent is allowed to reach.
Six months later, nobody can answer: which of our agents can reach the CRM? Where are the credentials for that integration, and when were they last rotated? If we need to revoke access to a system, how many places do we change? When an agent did something surprising, which tool did it call?
These are not protocol questions, so MCP quite reasonably does not answer them. They are the questions that appear when a capability moves from working to being operated.
Consolidating the tool surface
FireFoundry's MCP Gateway puts the tool layer in one governed place. Tools and resources are registered centrally rather than per application, credentials for the systems behind them are managed by the platform rather than copied into each team's configuration, and access is a policy decision instead of a deployment detail.
The developer experience does not get worse for this, which is the important part. An agent still asks for a tool. It just gets one the enterprise approved, through credentials it never has to see, with the call landing in the same telemetry as everything else.
The other half: skills as packages
Tools are what an agent can reach. Skills are what an agent knows how to do, and they have a parallel problem.
Useful agent capabilities tend to spread by copy-paste. One team writes a good document-classification routine; three others copy it; four versions drift apart; a bug fixed in one never reaches the others. This is the oldest failure mode in software, arriving in a new place.
The Skills Service treats a capability as a versioned, uploadable package instead. Publish once, install into the environments that need it, upgrade deliberately, roll back when an upgrade misbehaves. Ordinary dependency management, applied to the thing agents actually consume.
Why both belong in the environment
There is a consistent test worth applying to any capability: not whether it can be solved per application -- MCP servers and shared code both work fine per team -- but whether every team should have to solve it separately.
Credential lifecycle, access policy, version management, and observability for the tool layer are identical problems whichever team faces them, and they are problems that get harder in proportion to how many teams have solved them differently. Centralising them is not about restricting developers. It is about making sure that revoking one integration is one change rather than an archaeology project.
A note on scope
Neither of these makes tool use safe on its own. A gateway controls which tools an agent can reach and under whose credentials; it does not evaluate whether calling one was a good idea. That judgement stays with the agent's design, the policy on the request path, and the humans reviewing the outcomes.
What it changes is that those controls now have somewhere to attach. Explore the platform, or see how the tool layer fits the wider lifecycle in What Production AI Actually Requires.