The End of Custom AI Glue

Everyone is suddenly talking about MCP—but most people are describing it wrong. This episode argues that MCP is not a plugin system, not an API wrapper, and not “function calling, but standardized.” Those frames miss the point and guarantee that teams will simply recreate the same brittle AI glue they’re trying to escape. MCP is a security and authority boundary. As enterprises rush to integrate large language models into real systems—Graph, SharePoint, line-of-business APIs—the comfortable assumption has been that better prompts, better tools, or better agent frameworks will solve the problem. They won’t. The failure mode isn’t model intelligence. It’s unbounded action. Models don’t call APIs. They make probabilistic decisions about which described tools to request. And when those requests are executed against deterministic systems with real blast radius, ambiguity turns into incidents. MCP exists to insert a hard stop: a protocol-level choke point where identity, scope, auditability, and failure behavior can be enforced without trusting the model to behave. This episode builds that argument from first principles, walks through the architectural failures that made MCP inevitable, and then places MCP precisely inside a Microsoft-native world—where Entra, Conditional Access, and audit are the real control plane. Long-Form Show Notes MCP Isn’t About Intelligence — It’s About Authority The core misunderstanding this episode dismantles is simple but dangerous: the idea that LLMs “call APIs.” They don’t. An LLM never touches Graph, SharePoint, or your backend directly. It only sees text and structured tool descriptions. The actual execution happens somewhere else—inside a host process that decides which tools exist, what schemas they accept, and what identity is used when they run. That means the real problem isn’t how smart the model is.
It’s who is allowed to act, and under what constraints. MCP formalizes that boundary. The Real Failure Mode: Probabilistic Callers Meet Deterministic Systems APIs assume disciplined, deterministic callers.
LLMs are probabilistic planners. That collision creates a unique failure mode:

• Ambiguous tool names lead to wrong tool selection
• Optional parameters get “improvised” into unsafe inputs
• Partial failures get treated as signals to retry elsewhere
• Empty responses get interpreted as “no data exists”
• And eventually, authority leaks without anyone noticing

Prompt injection doesn’t bypass auth—it steers the caller. Without a hard orchestration boundary, you’re not securing APIs. You’re hoping a stochastic process won’t make a bad decision. Custom AI Glue Is an Entropy Generator Before MCP, every team built its own bridge:

• bespoke Graph wrappers
• ad-hoc SharePoint connectors
• middleware services with long-lived service principals
• “temporary” permissions that never got revoked

Each one felt reasonable. Together they created:

• tool sprawl
• permission creep
• policy drift
• inconsistent logging
• and integrations that fail quietly, not loudly

That’s the worst possible failure mode for agentic systems—because the model fills in the gaps confidently. Custom AI glue doesn’t stay glue.
It becomes policy, without governance. Why REST, Plugins, Functions, and Frameworks All Failed The episode walks through the industry’s four failed patterns:

1. REST Everywhere
   REST assumes callers understand semantics. LLMs guess. Ambiguity turns into behavior.
2. Plugin Ecosystems
   Plugins centralize distribution, not governance. They concentrate integration debt inside a vendor’s abstraction layer.
3. Function Calling
   Function calling is a local convention, not a protocol. Every team reinvents discovery, auth, logging, and policy—badly.
4. Agent Frameworks
   Frameworks accelerate prototypes, not ecosystems. They hide boundary decisions instead of standardizing them.

Each attempt solved a short-term pain while making long-term coordination harder. Why a Protocol Was Inevitable Protocols exist when systems need to interoperate without sharing assumptions. HTTP didn’t win because it was elegant.
OAuth didn’t win because it was pleasant.
They won because they pinned down authority and interaction boundaries. MCP does the same thing for model-driven tool use. It doesn’t standardize “intelligence.”
It standardizes how capabilities are described, discovered, and invoked—and where control lives when they are. MCP, Precisely Defined MCP is a protocol that defines:

• how an AI host discovers external capabilities
• how tools, resources, and prompts are declared
• how calls are invoked over a standard envelope
• how isolation and context boundaries are enforced

The model proposes.
The host decides.
The protocol constrains. That’s the point. Why MCP Fits Microsoft Environments So Cleanly Microsoft environments are identity-first by necessity:

• Entra defines what’s possible
• Conditional Access defines what survives risk
• Audit defines what’s defensible afterward

Dropping agentic tool use into that world without a hard boundary would be reckless. MCP aligns naturally with Microsoft’s control-plane instincts:

• Entra for authority
• APIM for edge governance
• managed identity and OBO for accountability
• centralized logging for survivability

This isn’t “AI plumbing.”
It’s integration governance catching up to probabilistic systems. The Core Claim of the Episode This episode stakes one central claim and then proves it architecturally: MCP isn’t AI tooling.
It’s an integration security boundary masquerading as developer ergonomics. Once you see that, everything snaps into focus:

• why custom glue collapses at scale
• why overlapping tools create chaos
• why identity flow design matters more than prompts
• and why enterprises can’t afford to let models act directly

What Comes Next Later in the episode—and in follow-ups—we:

• design a Microsoft-native MCP reference architecture
• walk through Entra On-Behalf-Of vs managed identity tradeoffs
• show where APIM belongs in real deployments
• and demonstrate how MCP becomes the point where authority actually stops

Because protocols don’t make things easy. They make them governable.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365–6704921/support.

If this clashes with how you’ve seen it play out, I’m always curious. I use LinkedIn for the back-and-forth.