Writing
Part 2: Building a Centralized MCP Gateway - The Context Layer
AI tools get dramatically more useful when they can reach internal systems. They also get more dangerous, for exactly the same reason. Most enterprises respond by picking one fear and committing to it — either locking everything down until the tools are useless, or letting integrations sprawl until nobody can say what the agents can touch. A centralized MCP gateway is how you decline that choice: agents get access to context, but every call routes through one controlled, audited, permissioned layer.
Make tool access boring
The gateway's job is to make connecting an AI tool to an internal system unremarkable. Authentication, authorization, schema discovery, logging, rate limits, and policy checks live in one place instead of being reimplemented — with varying levels of care — by every team that wants an integration.
Without that layer, adoption fragments in a predictable way. Teams write local connectors. Security loses visibility. Agents accumulate invisible power, one well-intentioned script at a time, and nobody notices until something goes wrong. With the gateway, internal context becomes a platform capability rather than a sprawl you discover during an incident review.
Get security out of the prompt
This is the part I care about most, since my day job is largely deciding what AI systems should be allowed to do. Telling an agent in its prompt not to access sensitive data is a hope, not a control. Prompts get ignored, injected, and creatively reinterpreted. The gateway is where security responsibility actually belongs: it refuses calls outside the agent's capability profile and logs the refusal. That gives a security team something inspectable — who asked, which tool, which resource, under which task, with what result — instead of a promise embedded in English prose.
Tools are contracts
The other shift is treating tool definitions as product surfaces rather than thin wrappers over internal APIs. A good tool definition carries its input and output schema, auth scope, owner, rate limit, data classification, and — most importantly — whether the call is read-only, staged, or mutating. That metadata is what makes a model-facing interface governable rather than merely available.
A few implementation lessons that have held up:
- Put identity propagation and audit logging in before scaling tool count. Retrofitting either is miserable.
- Separate read tools from write tools, and give write tools dry-run and staged modes wherever possible.
- Version tool schemas like product APIs. Agents learn behavioral contracts and break in confusing ways when the contract shifts underneath them.
- Attach ownership metadata, so broken tools page the right team and stale tools can actually be retired.
MCP is the interface. The gateway is the control plane that makes the interface safe enough to scale. And once every tool call flows through one place, you get something else for free: a request stream that describes how your organization actually uses AI. That's the subject of the next part.
This is Part 2 of the AI-for-Work series. Next: Part 3: From Proxy Logs to Intelligence.