My 2026 Take on MCP and Microsoft Foundry

When you read Microsoft marketing right now, it’s very easy to lose track of what actually matters.

There is Azure, there is Copilot everywhere, then there are “agents”, Foundry, MCP (Model Context Protocol) and almost every week a new product that promises to automate your entire job.

If you come from an integration and engineering background like I do, a different question pops up:

What does any of this mean if you already live in SAP, Azure and Microsoft 365 – and you’re not just playing with ChatGPT in a browser tab?

In this article I try to look at MCP and Microsoft Foundry from exactly that angle:

• not as marketing buzzwords,
• but as a toolbox for people who already use APIs, automation and enterprise systems every day.

I’ll stay practical: how I would think about this as a “SAP/Azure/integration person”, and where I see real use cases.

What is MCP, in normal language?

Officially, MCP stands for “Model Context Protocol”. The basic idea is simple, even if the docs can get abstract quickly:

• An LLM (or more generally: an “agent”) should be able to talk to external systems – tools, databases, APIs.
• Instead of every integration looking different, there is a standard protocol for how a tool/service exposes itself:
• “I am calendar”,
• “I am SAP backend”,
• “I am Azure DevOps”,
• “These are the functions I can perform and the data I can return.”

The LLM no longer needs to understand a bespoke plugin format for each integration. It “speaks MCP” and can talk to all tools that speak MCP.

If you’ve ever built an API gateway or ESB, this feels familiar:

• In the past, you normalised HTTP/REST, SOAP, OData, etc.
• Now you normalise “tool capabilities” for AI agents.

So you can think of MCP – a bit roughly – as:

“OpenAPI for tools an AI agent can work with.”

Microsoft Foundry builds exactly on top of this: it’s an environment where you can define, test and connect such agents to your systems.

Why this matters if you already live in SAP, Azure and M365

If you’re in the SAP/Microsoft world, you probably know this picture:

• SAP or another ERP as your system of record
• Microsoft 365 (Teams, Outlook, SharePoint, OneDrive) as the place where people actually work
• Azure as your integration and automation platform (Functions, Logic Apps, Event Grid, Storage, etc.)

Today we connect these worlds with:

• classic integrations (REST/OData, SAP BTP Integration Suite, Azure API Management)
• manual workflows (Power Automate, Logic Apps)
• our own services (Node/.NET backends in Azure)

All of that stays. MCP and Foundry do not replace these pieces – they sit on top of them.

The difference is this:

Instead of a fixed Power Automate flow, you can tell an agent:

“When a new order over 100k comes in from SAP:
– fetch relevant customer data,
– check open tickets (e.g. in Jira/Azure DevOps),
– write a summary into a Teams channel,
– and suggest a next step.”

For that, the agent must talk to:

• SAP,
• your ticketing system,
• Teams/Graph,
• maybe your monitoring stack.

We already know how to integrate those systems. What we didn’t have until now was a standard way to expose them to AI agents. MCP is that missing layer.

How I imagine an MCP/Foundry integration in practice

Let’s walk through a simplified scenario as I would picture it in 2026:

• You have a few existing APIs:
• SAP orders via OData/REST
• Azure DevOps work items
• Microsoft Graph for Teams/notifications
• You put a small layer in front of these APIs (Azure API Management or a custom backend) that speaks MCP.
• This layer offers the agent a set of clearly defined actions, for example:
• getSalesOrderById(orderId)
• listOpenIncidentsForCustomer(customerId)
• postTeamsMessage(channelId, text)

In MCP terms, these are “tools” with functions.

The agent you define in Foundry doesn’t see raw SAP or Graph – it sees these tools:

• sapOrdersTool
• incidentTool
• teamsMessagingTool

Its job is to decide, based on natural language and context:

• which tools to call,
• in which order,
• and how to combine the results into something useful for a human.

The important part: you separate intelligent orchestration from backend plumbing.

Your backend still has clean APIs and policies. MCP is just the adapter layer for the agent.

What an MCP tool for SAP might look like

Let’s stay on the idea level. Imagine a small Node/Express service running in Azure that talks to SAP and exposes an MCP tool.

// sapOrdersTool.ts – simplified
import { createMcpTool } from 'some-mcp-sdk';
import { getOrderFromSap } from './sapClient';

export const sapOrdersTool = createMcpTool({
  name: 'sap-orders',
  description: 'Read basic order information from SAP',
  functions: [
    {
      name: 'getOrderById',
      description: 'Load a sales order by ID from SAP',
      inputSchema: {
        type: 'object',
        properties: {
          orderId: {
            type: 'string',
            description: 'The SAP sales order number'
          }
        },
        required: ['orderId']
      },
      handler: async ({ orderId }) => {
        const order = await getOrderFromSap(orderId);
        // Only return what the agent actually needs
        return {
          orderId: order.id,
          customerId: order.customerId,
          amount: order.netAmount,
          currency: order.currency,
          status: order.status
        };
      }
    }
  ]
});

From the agent’s perspective, this is all it needs to know:

• there is a tool called sap-orders,
• it has a function getOrderById(orderId),
• it returns a JSON object with the fields above.

The agent doesn’t care whether there is OData, BTP, Destinations, S-Users or HANA behind it. That’s still your job as integration engineer – and that’s exactly where your expertise stays relevant.

What changes for me as a developer

If you ignore the hype and look at the concrete impact, I see three main changes:

1. Thinking in capabilities instead of endpoints

Instead of “I have a REST API with 10 endpoints”, you start thinking:

“I expose three capabilities to an agent: read orders, list incidents, post messages.”

That mindset shift forces you to design better APIs, because you see them through the agent’s eyes.

2. Decoupling human interaction and system interaction

Before:

• User clicks in a UI → app calls APIs.

With an agent:

• User says or types “What’s going on with customer X?” → agent decides which tools to call and how.

Your job: define tools cleanly, set up logging/monitoring, enforce boundaries.

3. Governance for AI tool access

As soon as an agent has tools that can change SAP or other critical systems, you are in classic governance territory:

• Authentication: which user identity does the agent represent?
• Authorization: what is it allowed to do?
• Audit: who called which function with which parameters and why?

None of this is new (IAM, RBAC, logging, all well-known), but you now have to apply it to agents, not just UIs and services.

Where MCP/Foundry already make sense – and where I’m cautious

Where I see real value today:

• Whenever you already have several APIs that are wired into multiple places. MCP lets you define them once as tools, and then you can build agents that act as flexible clients.
• For complex, context-heavy workflows. For example: “Summarise all relevant topics for customer X” – the agent can pull SAP orders, tickets, emails, chats, monitoring data. Doing that manually is painful; with well-defined tools it becomes realistic.

Where I’m more cautious:

• Adding MCP/Foundry “for show” when a simple REST client or Power Automate flow would do the job.
• When the underlying APIs and data models are bad. An agent won’t magically fix them.
• When people assume the agent “won’t break much” without doing the security and governance homework.

How I would start today

If I were to start in a SAP/Azure/M365 landscape today, I’d keep it small and focused:

1. Pick a tiny scenario where a human already does a lot of manual context gathering, for example:
   “Customer X calls and I want a one-paragraph summary of everything relevant.”
2. Identify existing APIs:
   – SAP: customer, open orders, open invoices
   – Azure DevOps / Jira: open tickets
   – Exchange/Graph: recent emails (if allowed)
3. Build a small backend that “tool-ises” these APIs:
   – one MCP tool per logical capability.
4. Define one agent in Foundry that only knows these tools and has exactly one job:
   “Given a customer name or ID, produce a useful summary.”
5. Log everything, keep the scope tight, and watch how the agent behaves before giving it more power.

That’s not about replacing people. It’s about automating the context-gathering part that currently eats a lot of time for developers, consultants and support engineers.

Conclusion: MCP/Foundry as “AI ESB” for people who already know ESBs

For me, MCP and Microsoft Foundry in 2026 are not magic. They are a logical next step of what we already do:

• design clean APIs and services,
• standardise integration,
• add automation where it creates real value.

The difference is that now we’re not just connecting systems to systems, but also agents that understand natural language and orchestrate tools.

If you come from the SAP/Azure/Microsoft world, the real questions aren’t “Do we need this?” but:

• “Which capabilities would I expose to an agent in my context?”
• “Where do I already have APIs that fit well?”
• “How do I keep it secure and auditable?”

Once you answer those, MCP stops feeling like hype and starts looking like just another useful piece in your architecture toolbox – one that happens to speak the same language as modern AI agents.