Q&A
Why Model Context Protocol Matters for AI Systems
In this Q&A, Microsoft’s Fabian Williams explains how Model Context Protocol brings structure, reliability and governance to prompt-based AI systems.
As organizations push AI systems into production, IT teams are asking how to make models more dependable, secure and useful in real-world workflows. One approach gaining traction is the Model Context Protocol (MCP), which standardizes how models connect to and use external tools and services. Instead of relying on fragile memory hacks or chained prompts, MCP introduces a structured way for models to act across multiple steps and sessions.
To explore what this means for IT professionals, Redmondmag spoke with Fabian Williams of Microsoft ahead of his Live! 360 Orlando session, "What Is Model Context Protocol (MCP) and Why Should You Care? A Beginner's Guide."
In the Q&A, Williams outlines how MCP works in practice, where it is already supported, and what governance considerations teams should keep in mind as they adopt it. He also provides examples of how MCP can support debugging, task delegation and secure backend integration.
These insights will be central to Williams’ session on Tuesday, Nov. 18, where attendees can see MCP in action and learn how it is shaping the next generation of enterprise AI. Make your plans today to join us at Live! 360 Orlando.
Redmondmag: What problem does Model Context Protocol solve in prompt-based AI systems?
Williams: MCP solves the problem of structured orchestration in AI systems that rely on prompts. Most prompt-based apps today are single-shot or rely on fragile memory hacks. MCP introduces a contract-based protocol for how tools (APIs, functions data services) are declared, discovered and invoked by a model -- enabling models to reliably act, not just return text.
How does MCP support multi-step interactions across sessions or workflows?
MCP supports multi-step workflows by preserving tool context and execution traces. This allows a model to recall previous tool calls, their outcomes, and adapt behavior accordingly -- like an agent that can reason over state, not just react. This is critical for scenarios like debugging, task delegation or multi-turn search and recommendation systems.
What tools, libraries or services currently support MCP?
Currently, MCP is supported by:
- OpenAI (Claude via Anthropic also has early-stage support through Claude Desktop)
- Microsoft’s Semantic Kernel (via planner + function calling)
- Custom agents and orchestrators—I’ve built several open-source MCP-compatible servers using .NET and Python
- OpenTelemetry— Near and dear to my heart as that is what I am currently working on this semester at Microsoft. While not a direct dependency, it's crucial for observing MCP behavior across distributed systems (see this demo)
What does a basic MCP implementation look like in practice?
In practice, MCP is a JSON-based contract that a model can "see" and call. Tools are described with input/output schemas, and the server handles routing. Here's a simplified flow:
- Model receives tool list (via system prompt or config)
- User asks a question
- Model selects tool + parameters
- MCP server executes tool and returns result
- Model uses result to continue the conversation
I show this in action with a real HTTP server and CLI in this video.
How does using MCP compare to chaining prompts or memory systems?
Prompt chaining and memory are implicit -- the model must infer what happened before. MCP is explicit. It turns tools into first-class citizens and lets the model operate like an API consumer. This adds structure, debuggability, and reuse, making it ideal for real applications, not just demos.
Are there security or governance implications teams should be aware of when adopting MCP?
Yes. Because MCP enables tool execution, you're effectively granting the model access to backend services. You should:
- Authenticate tool calls
- Define access scopes per tool
- Log every invocation (I use OpenTelemetry for this)
- Monitor and alert on anomalies
MCP gives power, but that power needs guardrails -- just like any microservice architecture.