Wiring Agents Into On-Prem and Cloud APIs

AI can't do much without context. It's (almost literally) like sticking a robot in a dark room. But like a moth, give it a light and it will move toward the stimuli. In this feeble, human-conjured metaphor, the light is your data and your business goals. So how do you get the light to your agent?

*Model Context Protocol has entered the chat*

Standing up your first MCP server takes about twenty minutes. Pick an SDK, define a tool, point it at something, watch an agent call it. It works. The room gets a little excited. Somebody starts talking about roadmaps.

And then somebody else asks how long it would take to do that against the systems the business actually runs on, and the temperature in the room changes.

That is the question worth being ready for, because the honest answer depends almost entirely on things nobody wants to bring up during a demo. Where does the system live. Who is the agent acting as. What happens when it writes something. I have spent the last three years in an environment where the answers to those were "a server down the hall," "nobody has decided," and "please do not."

So here is the architecture conversation the way I would actually run it, plus a note at the end about why I think this is where a lot of implementation work is headed.

Hybrid is the normal case

Many iterations of the MCP and agentic hype cycle assume every business has already spent the money and the hours moving their on prem systems into a cloud tenant with modern identity sitting neatly in front of it. This is hilariously incorrect. What actually exists is some systems in a data center, some in the cloud, an identity provider bridging both, and a set of integrations somebody built under deadline pressure in 2019 and has been afraid to touch since.

Sometimes that is a failure to modernize. More often it is just what a long term migration looks like from the inside, whether the holdup is resistance or budget, and the result is the same either way: a mess. Half your data has a modern API in front of it and half of it lives behind an export that runs at 2am. Identity works differently depending on which side of the house you are standing in. Nobody has a complete picture of what talks to what, and the person who did retired.

Dropping agents into that without a plan is an expensive way to learn a lesson. You will get a demo, then a pilot, then a quiet meeting about why the numbers never moved. I wrote about why that happens over here, but the short version is that automation reads what you actually have rather than what you meant, and a hybrid environment gives it a lot of material to work with.

The good news is that MCP genuinely does not care where an API runs. It cares about three things: whether the agent can reach it, whether it can prove who it is acting for, and whether it gets back something predictable. Every hard decision downstream is a version of one of those three, and most organizations cannot confidently answer any of them today.

Before we dive in, here's what changed on July 28

The Model Context Protocol published a new specification on July 28, 2026, and the maintainers called it the largest revision since launch. They were not overselling it. The headline change is that the protocol went stateless. The initialize handshake is gone, and so is the session header that used to pin a conversation to one specific server instance.

That sounds like a protocol footnote. It is not, and it matters most if your infrastructure predates the cloud. Under the old model, a remote MCP server needed sticky sessions or shared session storage, because a request had to land on the same instance that handled the handshake. Anyone who has tried to coax that behavior out of an existing on-prem load balancer knows exactly what it costs, both in hours and in the goodwill of the person who administers it. Now every request carries its own protocol version, client identity, and capabilities, so any request can land on any instance behind ordinary round-robin balancing with no shared state at all.

The routing change is just as useful in an enterprise network. Method and tool names now travel in HTTP headers instead of only inside the JSON body, which means your existing gateway, reverse proxy, WAF, or rate limiter can route and enforce policy on them directly. No deep packet inspection. No bespoke middleware. No forty-five minute meeting explaining to your security team why their existing controls do not apply to this new thing you want to plug in. That alone is a different conversation than it was six months ago.

If you are on the Microsoft stack like I usually am, the C# SDK shipped a v2.0 aligned to the new revision, and Python, TypeScript, and Go updated alongside it. The prior version keeps working, and the deprecated pieces carry a twelve month minimum window, so this is a migration to plan rather than a fire to put out. Worth knowing when somebody inevitably asks whether you should just wait.

Where does this thing actually live

First real architectural decision, and it is a fun one.

The agent usually runs somewhere you do not control. The API runs somewhere you very much do. Something has to bridge that gap, and the wrong answer is opening an inbound path to a core system because a pilot needed it before the end of the quarter. That is how you end up explaining a firewall rule to an auditor in 2028.

The shape I would propose: treat the MCP server as the only thing reachable from outside, sitting in front of APIs that stay unreachable. It lives at the edge, in a DMZ or behind a gateway you already run, and it holds no data of its own. Your internal systems keep exactly the exposure they have today, which is to say none. This framing also makes the pilot dramatically easier to get approved, because if it gets cancelled you tear down one component instead of unwinding network changes nobody remembers making.

For the genuinely locked-down environments (hi, healthcare and higher ed), an outbound-initiated tunnel is worth putting on the table. A connection your network opens is a much easier approval than a port somebody else opens into it. Either way the principle holds: the agent talks to the MCP server, the MCP server talks to your APIs, and those are two separate trust decisions that deserve to be made separately by people who are awake.

This is the same reasoning behind splitting internal and vendor-facing APIs onto separate surfaces. An agent surface is a third boundary with its own threat model, and it earns its own front door for exactly the same reason the other two did.

Identity is the whole game

The tempting shortcut is a service account with broad rights and a static key sitting in an environment variable. It works immediately. It demos beautifully. It also quietly converts every access decision your organization has ever made into a single credential that can do anything on behalf of anyone, which is the sort of thing that comes up in a security review roughly nine seconds after you present it.

The specification is refreshingly direct about the alternative. An MCP server acts as an OAuth 2.1 resource server, not an authorization server. It validates short-lived, scoped tokens issued by the identity provider you already run rather than minting its own. In a hybrid environment that is the correct answer anyway, because agent access ends up governed by the same directory and the same groups that govern everything else. You are not standing up a parallel permission system that will drift from the real one inside of a year, then quietly become the thing nobody wants to own.

Three details worth getting right:

Bind tokens to a specific resource, so a token minted for one MCP server cannot be replayed against another. Do not pass tokens through to upstream APIs: exchange them for one scoped to that downstream service, so a compromise at one hop does not turn into access to everything behind it. And note that the July revision hardened the flow further by requiring clients to validate the issuer before redeeming an authorization code, which closes a mix-up attack that was previously possible.

Take this part seriously, because the ecosystem currently is not. A May 2026 study of nearly eight thousand live remote MCP servers found roughly 40% exposed tools with no authentication mechanism at all, and another 29% leaned on static tokens or API keys. So whatever you build is probably not going to be the weakest thing out there. That is a very low bar and a genuinely terrible thing to aim at.

An MCP server is not your API with a hat on

The most common design mistake is mirroring your REST surface one to one. Forty endpoints become forty tools, the agent gets a catalog it cannot reason about, and every call asks a model to assemble something a human developer would have needed documentation to assemble.

A tool is a task, not a route. "Look up a student's current enrollment status" is a tool. Six chained GETs and a join is not a tool, it is homework. If completing a common request takes an agent four calls in a specific order, that sequence should have been one tool with a name that says what it does.

You are designing an interface for a reader that cannot walk over and ask a coworker what a field means, which makes the tool description and the response shape the interface, not documentation about the interface. Keep the catalog small and curated. Fewer, well-named tools with clear descriptions beat exhaustive coverage every single time, and the fastest way to make an agent unreliable is to hand it thirty plausible options for the same job. Same instinct as the agent desktop problem in a contact center: information density is not context.

And be extremely deliberate about which tools write. Read access is recoverable. Write access is a decision about what an agent is allowed to do to production data on a Tuesday afternoon, and it deserves its own line in the scope document rather than arriving as a side effect of exposing a resource because it was convenient.

Keep the human where the judgment is

The new revision helps here too. Multi Round-Trip Requests let a tool pause mid-call to ask for a confirmation or a missing parameter. The server returns a result flagged as needing input, the client comes back with the answer attached, everybody moves on. Previously that pattern meant holding a stream open, which is the kind of thing that works great on your laptop and dies immediately on a real corporate network.

What this gives you is a clean way to encode the line between toil and judgment directly into the tool. The agent assembles everything, stages the work, and then stops at the exact point where a person needs to approve the thing that has consequences. Automate the retrieval and the formatting. Ask before the write that somebody is going to have to answer for later.

It is also, practically speaking, a much easier design to walk a nervous stakeholder through than a diagram of everything the model has promised not to do.

Where the work is

Here is the part I find genuinely interesting, and the reason I think this is worth more than a pilot.

Every organization I have worked in or sold into has a list of deferred integration work. Clean up the API surface. Consolidate identity. Retire the export that gets emailed every Friday to a distribution list containing four people who no longer work there. Document the endpoints. That work has always been correct and almost never funded, because the business case was "things will be tidier," and tidier does not win a budget meeting against a revenue project.

Agents changed the shape of that argument entirely. The exact same cleanup now has a visible payoff attached to it, and leadership is asking for the payoff directly. That does not make the work any easier. It makes it fundable, which was the actual blocker for the last decade.

The second thing that makes this attractive is that it does not require replacing anything. An MCP server is an adapter, and an adapter in front of a system nobody wants to touch is a far smaller ask than a migration. You are not proposing to rip out the platform the business runs on. You are proposing a curated surface in front of it, and the legacy system underneath gets to go on being a legacy system in peace. That phases beautifully: one read-only tool, then a second, then the write path once trust exists, with every phase producing something usable instead of a milestone on a slide.

Which means the real deliverable is rarely the MCP server. It is the reachable API. The scoped credential. The identity model that finally got sorted out. The documentation that finally got written because something other than a human had to read it. The protocol work is the small part. The modernization it justifies is the engagement, and it is the kind of work that leaves a client better off even in the scenario where the whole agent strategy changes underneath them next year.

Where to start

Pick one read-only tool against a system people already ask questions about. Put it behind your real identity provider on day one, because retrofitting auth after a successful pilot is a conversation nobody has ever won. Log every call with who requested it and what came back, since the first question after any incident is what the agent actually did, and "we're not totally sure" is a rough thing to say out loud to a client.

Then leave it alone for a few weeks and watch what people try to do with it. The second tool is dramatically easier to design once you have evidence instead of a roadmap, and honestly, the usage data usually turns out to be the strongest argument for funding phase two.

None of this is really about agents. Reachable APIs, centralized identity, scoped credentials, tools named after tasks, audit logs that answer questions. It is the same list it has always been, the one everyone nodded along to and then deprioritized. The agents just make it painfully obvious which parts got skipped.