From Hardcoded APIs to MCP: How Enterprise Developers Must Rethink Agent Integration
I have sat through too many architecture discussions and review boards where the debate gets stuck on “should we go with Skills or MCP?” as if we are choosing between two competing options. And, function calling has entered the same conversation and made things even more confusing.
All three of these get conflated constantly, and that conflation is what causes bad architectural decisions.
Skills are about reasoning. Function calling is about how the model requests an action in a single turn. MCP is about connectivity and governance at scale.
These three operate at completely different levels of the stack. Mixing them up is like asking your network team whether you need TCP/IP, a REST convention, or a good database schema. You need all three, and each has its rightful place.
But before we talk about any of those three, we need to talk about where most enterprise agent code actually starts. And that is hardcoded API calls.
Stage One: The Hardcoded API Call
Every developer who has built an enterprise agent in the last two years has written some version of this. A Python function that hits the SAP endpoint directly. A bearer token pulled from an environment variable. The response parsed inline and fed back into the prompt. It works in the demo. It gets committed to the repository. And then it quietly becomes a technical debt.
The issue is that this approach was perfectly reasonable when you were building a traditional application where a human was clicking a button to trigger each call.
When an agent is autonomously deciding to call that same API ten times in a session, chaining the results across three other services, and doing all of this without a human in the loop, the hardcoded approach breaks in ways that are very hard to recover from.
Every schema change, every endpoint rotation, every authentication update is a code deployment that warrants change request, UAT sign off, and a release window. Your agent integration now lives on the same release cycle as your application code, and that cycle was never designed for the pace at which business system APIs evolve.
You also have zero discoverability. The agent only knows what a developer decided to bake in at build time. New capabilities that come online in your ERP system are invisible to the agent until someone writes more code. You are building a static map of a landscape that is constantly changing.
And when your CISO asks which agents are touching which business systems and under what conditions, there is no clean answer. The API calls are buried across repositories, called from different places, using different credentials that someone hardcoded into environment variables six months ago and nobody has rotated since.
The architecture conversation has to start here, because this is the reality on the ground.
Stage Two: Function Calling in lieu of Hardcoded APIs
The natural next step for most teams is to introduce function calling. The model now decides dynamically which function to invoke based on the user’s intent, rather than the developer hardcoding the sequence. This feels like a significant improvement, and in some ways it genuinely is.
But function calling solves the routing problem without solving the integration problem. And in an enterprise context, the integration problem is the one that will actually hurt you.
Every function your agent needs to call must be defined and passed into the model context at inference time. In a simple chatbot with three or four tools, that is fine.
In an enterprise environment where your agent might need access to 10-15 different business system capabilities depending on context, you are either bloating every prompt with tool definitions the agent will never use in that session, or you are building complex routing logic to figure out which function definitions to inject.
The function definition now lives in the prompt rather than buried in application code, which is marginally better from an auditability standpoint.
Native function calling primitives are intentionally lightweight and request-scoped. Long-running enterprise workflows require orchestration capabilities beyond the function calling interface itself.
So where does function calling actually fit in a mature architecture? It fits as the low level dispatch mechanism inside an MCP tool implementation. Your MCP server receives a standardised request from the agent, and internally it may use function calling patterns to route to the right backend handler.
Stage Three: MCP as the Enterprise Integration Layer
MCP does not replace hardcoded API calls or function calling at the code level. It replaces the architectural pattern of having agents reach directly into business systems at all.
Instead of your agent knowing about your SAP API, your agent knows about an MCP server that exposes SAP capabilities in a governed, discoverable, standardised way.
The MCP server is the boundary. Everything behind it is an implementation detail that the agent team does not need to own.
This effort should be led by Enterprise Architects, as this impacts agents across organization, rather than individual development teams.
One Server, Many Consumers
When your platform team builds an MCP server on top of your SAP instance, every agent team in the organisation consumes it.
You want to swap the underlying language model next year? Fine.
You want to migrate your orchestration framework? No problem.
The integration layer stays stable and provides the reuse we have been promising stakeholders for years with SOA and microservices. MCP gives us another shot at it in agent-era.
There is an important caveat here that platform architects need to plan for honestly. Wrapping a modern REST API into an MCP server is relatively straightforward work. Wrapping a legacy ERP system, a stateful on premise integration, or a proprietary mainframe interface is a significantly different proposition. These systems were not designed to be called as stateless tools by an autonomous agent.
Session management, transaction boundaries, error handling, and partial rollback scenarios all require careful engineering that the MCP specification itself does not prescribe.
The reuse promise is real, but the upfront investment to get legacy systems wrapped correctly should not be underestimated in your programme planning.
Where Skills Fit in All of This
Here is the nuance that often gets lost when teams get excited about MCP. The protocol tells your agent what tools are available and how to call them. It says absolutely nothing about when to call them, in what order, how to reconcile conflicting data coming back from three different API responses, or when the right answer is to stop and escalate to a human.
An agent sitting on top of 20+ well governed MCP servers but with shallow reasoning logic is basically a very expensive search interface with a compliance dashboard attached to it.
The genuinely hard problems in enterprise agent deployments are not connectivity problems. They are judgment problems. Figuring out that a vendor master check must happen before a purchase order is raised, even when the user did not mention it. Handling the situation where your ERP returns a partial result because of a downstream timeout. Knowing when ambiguous user intent requires clarification rather than a best guess action.
None of that lives in MCP. All of that lives in skills.
So skills are not going away. What changes is their role in the stack. They get promoted to the reasoning layer above orchestration and they get relieved of their current job as bespoke integration glue. The middle tier of framework specific, non reusable, ungovernable tool definitions is what we need to retire.
The Identity Problem, and How Entra ID Solves It
I want to be transparent about where the hardest architectural question in this space sits, because it is the one that determines whether your agent programme scales safely or collapses under its own complexity.
Federated trust across organisational boundaries is genuinely hard.
When your agent calls an MCP server operated by a third party SaaS vendor, whose identity model is in charge?
OAuth scopes give us a partial answer. They do not compose cleanly across different organisational trust boundaries.
Services like, Microsoft Entra ID, provide the most mature and practical answer available in the market today.
Entra ID now supports agent identity, which means your AI agents can be registered as non-human identities inside the same directory where your users, service principals, and managed identities already live. Each agent gets an identity object. That identity object participates in the same conditional access policies, role based access controls, and audit logging pipelines that your IT and security teams already operate. This extends your existing governance model to cover agents.
The authentication flow is clean. The agent authenticates using OAuth 2.0 and receives a scoped access token. That token carries the agent identity, not a hardcoded service account credential that three different developers know the password to. The token is short lived. It is scoped to the specific resource the agent needs to access in that session. And every token issuance is logged centrally.
Where this becomes genuinely powerful is with third party SaaS applications that already support Entra based authentication.
If your business systems already accept Entra tokens for human user authentication, your agents can participate in the same trust chain without any bespoke integration work.
The MCP server calls the SaaS API, the SaaS API validates the Entra token, and the access decision is made using the same policies that govern your human users.
The complexity of cross-boundary agent authentication does not disappear, but with Entra ID as the identity backbone it becomes a manageable engineering problem rather than an unsolved architectural one.
How the Stack Actually Fits Together
The organisations that will get enterprise agents right in 2026 and beyond are not the ones debating Skills vs Function Calling vs MCP. They are the ones who recognise that these are three different layers of the same stack, each solving a different problem, and each needing to be governed differently.
Here is what that architecture looks like in practice:
MCP servers sit at the integration layer, owned by your platform team, with proper IAM controls and audit logging from day one.
Agent identity is anchored in Microsoft Entra ID, with tokens that are short lived and scoped to specific tool audiences.
Reasoning skills sit above the orchestration layer and encode the domain judgment that your business actually needs. Domain architects and business analysts need to be deeply involved in defining the reasoning skills.
Emerging MCP gateway patterns are beginning to address where an MCP gateway handles the security concerns the protocol itself does not address, including tool poisoning, rug pull protection, cross server shadowing, and per user OAuth passthrough.
Rather than building this from scratch, some gateways like, Azure API Management, allow existing APIs to be registered directly as MCP servers. If your SAP, Salesforce, and internal APIs are already onboarded into APIM, they become MCP tools without hosting another server, carrying forward existing policies for authentication, rate limiting, and access control.
We went through this same maturity journey with application integration before. We started with hardcoded database connections. We moved to DAOs and service layers. Then to REST APIs. Then to API gateways and service meshes. Each step followed the same concept: stop letting individual developers own the integration boundary and put it somewhere it can be governed.
Agent integration is following the exact same path. The developers who built their first agents with hardcoded API calls were just at Stage 1. The job now is to help every team in the organisation make that journey to Stage 3 without losing the speed and agility that made those early agents valuable in the first place.
