MCP Is Not Magic – It’s Just a Cleaner Way to Admit You Need an Orchestrator

Every few months there is a new framework that supposedly “changes everything” about how we build AI systems.

Right now, MCP and Foundry are in that spotlight.

If you read some of the marketing posts, you get the impression that MCP is a kind of magic dust you sprinkle on your agents and suddenly everything is more powerful, safer and easier to manage.

I don’t buy that.

I like MCP. I like Foundry. But not because they are magic.

MCP is essentially a cleaner way to admit that you need an orchestrator.

In this post I want to unpack what that means, using a very concrete example: an agent that understands the gap between SAP / SuccessFactors and Entra ID, and reports identity drift back to you.

1. The reality before MCP: ad-hoc glue everywhere

Before MCP/Foundry, most “agents” in companies looked like this:

• a chat UI somewhere (Teams bot, web frontend, Slack app),
• a backend service written in whoever’s favourite language,
• a bunch of custom HTTP endpoints or SDK calls to systems like SAP, Entra, Jira, Confluence, ServiceNow, …
• some prompt engineering and an LLM call glued on top.

If you were disciplined, you at least hid those systems behind a minimal set of APIs:

• getUserProfile(email) instead of “call SAP, then Graph, then some random DB”,
• createTicket(summary, details) instead of “POST to Jira with a half-baked payload”.

If you weren’t, your agent prompt probably contained a free-form explanation like:

“When you need SAP data, call this URL with this payload. When you need Entra data, call this other URL…”

It worked, but it was fragile and hard to reason about.

2. What MCP actually gives you

MCP (Model Context Protocol) formalises something many of us were already doing intuitively:

• you describe tools in a machine-readable way,
• you keep business logic and credentials on your side,
• the agent gets a clean menu of what it can do and how to call it.

Instead of informal “when you need SAP…” paragraphs, you get structured capabilities like:

• sap_list_users(limit)
• entra_list_users(limit)
• report_mismatches(filter)

Foundry builds on top of this by giving you a consistent runtime, hosting and lifecycle around those tools.

None of that is magic. It’s just good software engineering discipline encoded into a protocol and a platform.

3. Example: A Sync Insights agent on MCP/Foundry

Let’s make this less abstract.

Imagine you want an agent that can answer questions like:

• “Show me active SAP employees who don’t have an Entra account.”
• “Where do department attributes differ between SAP and Entra?”
• “Which Entra accounts look like they should have been deprovisioned already?”

Under the hood you need three things:

1. an SAP/SuccessFactors API client,
2. an Entra ID client (Microsoft Graph),
3. a bit of logic that compares both and reports mismatches.

With MCP/Foundry, you expose this as a small set of tools instead of one giant do-everything endpoint.

3.1. Tool-level view

The tools might look like this in conceptual terms:

• sap_list_users(limit, departmentFilter) – returns a normalised list of SAP users.
• entra_list_users(limit, departmentFilter) – returns a normalised list of Entra users.
• report_mismatches(scope) – returns a summary of differences between both sides.

The Sync Insights agent doesn’t need to know how SAP authentication works or which Entra Graph scopes you requested. It only “sees” the tools.

Behind those tools lives your service code – written in Node, .NET, whatever you like – that you can test like any other backend.

3.2. Why this is better than pure prompt glue

The benefits are subtle but important:

• Discoverability: tools are explicit. You can introspect them, generate docs, reason about what the agent can and cannot do.
• Security: credentials stay in your server. The agent never sees SAP passwords or client secrets.
• Reusability: the same toolset can be used by multiple agents, CLI tools, scripts.
• Testability: you can unit test report_mismatches() without an LLM in the loop.

You could have built all of this without MCP, of course. But MCP gives you a shared language and wiring for it.

4. Where Foundry adds value

Foundry is essentially a home for your MCP tools and agents.

From my perspective, its value in this story comes from:

• standardised hosting for your agents and tools (no more “where is that container running again?”),
• configuration and environment separation (dev vs. prod, different tenants),
• observability: calls, latency, errors per tool,
• and a place to evolve your agents over time without rewriting everything.

For the Sync Insights agent, a Foundry setup might look like:

• one Foundry project per organisation/tenant,
• a tool bundle exposing SAP and Entra operations,
• an “Insights” agent that knows how to combine them.

From there, you can connect different frontends:

• a Teams message extension,
• a simple web UI for identity admins,
• scheduled runs that post reports into a channel.

5. The orchestrator question you can’t dodge

MCP and Foundry don’t change a fundamental truth about non-trivial AI systems:

Somewhere, you need an orchestrator that decides which tools to call, in which order, and with which data.

You can pretend that this logic “just happens” inside the LLM because you wrote a long prompt. Or you can admit that:

• part of that orchestration belongs in the model (planning, natural language understanding),
• and part of it belongs in your code (validation, retries, safety checks, state).

MCP makes that split a bit more honest: tools are first-class citizens. Foundry gives you a place to run them.

But you still have to design:

• which tools an agent is allowed to use,
• what a “good plan” looks like for a given workflow,
• and where you want a human in the loop.

6. Where I see the sweet spot for MCP + Foundry

In my own projects, the combination of MCP and Foundry shines when:

• I have to integrate multiple enterprise systems (SAP, Entra, Jira, Confluence, ticketing),
• I want to keep all real credentials and complexity in a backend I own,
• but I want agents to feel like they have a unified “brain” for these systems.

The Sync Insights agent is a great fit for this:

• it’s cross-system by nature (HR vs. Identity),
• it’s read-heavy and insight-focused (perfect for AI summarisation),
• it benefits massively from being able to call multiple tools in a single conversation.

I wouldn’t use MCP/Foundry for a one-off “call this single API and return JSON” plugin – that’s overkill. But the moment you’re juggling several systems and workflows, you need an orchestrator anyway. MCP just gives that orchestrator a standard shape.

7. My take

I don’t see MCP or Foundry as magic. I see them as an honest acknowledgement that:

• tool calls matter,
• backends matter,
• and orchestration is too important to hide in a prompt.

For scenarios like SAP ↔ Entra Sync Insights, that’s exactly what I want:

• a clean set of tools that express what my backend can do,
• a platform that runs them with proper observability,
• and agents that are powerful because their world is well-structured – not because we believed in magic.

If you go into MCP/Foundry with that mindset, you’re less likely to be disappointed – and much more likely to build something that survives the next hype cycle.