What Is MCP? The 2026 Developer Guide for AI-103 Agents

Update (September 2026): AI-900 and AI-102 retired on June 30, 2026. Their replacements, AI-901 (Azure AI Fundamentals) and AI-103 (Azure AI App and Agent Developer Associate), are the current exams. For the current path, see the AI-103 Study Guide.

May 2026 update: This guide reflects the AI-103 official course content (AI-103T00-A) as of May 2026 and the version of the Model Context Protocol that was donated to the Linux Foundation's Agentic AI Foundation in December 2025. Where Microsoft Learn uses "Microsoft Agent Framework" and we use "Semantic Kernel," treat them as the same SDK for exam purposes.

Most engineers heard "MCP" for the first time in mid-2025 and have been quietly confused about it ever since. In the AI-103 exam, MCP is no longer a side note. It is the link between Azure AI Foundry agents and every external system your application will ever need to talk to, and the exam tests it at the SDK level.

This guide explains what MCP is, why Anthropic created it, how Microsoft uses it inside Foundry, how to connect an MCP tool to an AI-103 agent in code, and where it appears on the exam. If you are short on time, read the TL;DR and the section "How MCP fits into AI-103." Everything else is reference material you can come back to.

TL;DR

MCP, the Model Context Protocol, is an open standard that lets AI agents discover and call external tools at runtime without you hard-coding routing logic. Anthropic published it in November 2024 and donated it to the Linux Foundation's Agentic AI Foundation in December 2025. Microsoft adopted it as a first-class integration model in Azure AI Foundry. On AI-103, MCP appears in Learning Path 2 Module 3 and represents a meaningful portion of the "Integrate and Deploy AI Solutions" exam domain, which carries 20 to 25% of the exam weight. You connect MCP servers to a Foundry agent by registering an MCPTool, choosing an approval policy, and letting the model decide which exposed tool to call.

If you want the full curriculum context first, our AI-103 study guide maps every module and weighting in one page.

What MCP actually is

MCP is a thin, open specification for how an AI application (the client) talks to an external system that wants to expose tools, data, or prompt templates to a language model (the server). The specification covers transport, message format, capability discovery, and authorization handshakes. Everything else, which model you use, which agent framework wraps it, which tools an individual server exposes, is left to the implementer.

The analogy that stuck in 2026 is the one Microsoft and Anthropic both started using: MCP is the USB-C of AI tooling. Before USB-C, every device shipped its own connector and cable, and integrating two devices meant either writing custom firmware or buying an adapter. After USB-C, any compliant device works with any compliant host. MCP plays the same role for AI agents. Before MCP, every AI app wrote its own function-calling shim for every external system it wanted to use. After MCP, any compliant agent host can connect to any compliant MCP server, and the server's tool catalog is discovered at runtime rather than baked into application code.

That last detail is the one that matters for AI-103. The exam keeps coming back to the same question in different scenario clothing: when you add a new capability, do you have to redeploy your agent, or does the agent pick the new tool up automatically? With MCP, the agent picks it up automatically, because the tools live behind a server that the agent queries, not inside the agent's source code.

Why Anthropic built it

Function calling, the OpenAI-style mechanism where you describe a function in JSON Schema and the model decides when to invoke it, has been around since mid-2023. It works, but it has three structural problems that get worse as your application grows.

The first is brittleness. Every tool the model can call has to be declared in the request payload. Add a tool, redeploy. Remove a tool, redeploy. In production, with multiple teams owning different capabilities, the redeploy cycle becomes the bottleneck and people stop adding tools.

The second is fragmentation. Each agent framework, Semantic Kernel, LangChain, OpenAI Assistants, custom in-house, implemented function-calling slightly differently. A tool written for one framework had to be rewritten, or at least re-shimmed, to work in another. Accidental vendor lock-in.

The third is discovery. Function calling assumes the application already knows which tools exist. There is no standard mechanism for the application to ask a third-party service "what can you do?" at runtime. Every integration is hand-coded.

MCP solves all three by moving the contract to the server. The server declares its tools (and resources, and prompts). The client discovers them at startup and refreshes them at runtime. Any MCP-compliant client can talk to any MCP-compliant server, regardless of whose framework either side uses.

The standard has moved fast. As of March 2026, the official MCP SDKs had passed 97 million monthly downloads, and there were more than 13,000 MCP servers indexed on GitHub, covering databases, cloud providers, SaaS tools, file systems, and internal enterprise systems. Every major AI vendor, Anthropic, OpenAI, Google, Microsoft, AWS, supports MCP in their primary agent stacks in 2026.

The MCP architecture in 90 seconds

There are three roles in an MCP system.

The host is the application the user actually interacts with. For an AI-103 candidate, the host is usually a Foundry agent running in the Foundry Agent Service, but it could equally be Claude Desktop, VS Code's GitHub Copilot agent mode, or a custom Python script that calls the Foundry SDK directly.

The client is the embedded library inside the host that speaks the MCP wire protocol. You almost never write client code directly. When you register an MCPTool on a Foundry agent, the Foundry SDK is running the client on your behalf.

The server is the external process that exposes capabilities. It can run anywhere: as a local process on the developer's machine, as a sidecar in a Kubernetes pod, as a managed Azure service, or as a remote HTTPS endpoint hosted by a third party. Microsoft ships several official MCP servers as managed Azure endpoints, we'll get to them below.

A server can expose three kinds of capabilities, called primitives in the spec.

Tools are functions the model can invoke. Each tool has a name, a description, a JSON Schema for inputs, and a return type. Tools are by far the most common primitive, and they are what AI-103 tests in the most depth.

Resources are pieces of data the model can read. Think of resources as the "this is what's in your context" primitive: a file, a database row, a log snippet. The client decides which resources to attach to the conversation.

Prompts are reusable prompt templates the server provides. The host can offer them as starting points to the user, or feed them to the model as system messages. Prompts are the least commonly used of the three primitives and rarely appear on the exam.

Transport is typically HTTPS for remote servers and stdio for local servers. The wire format is JSON-RPC 2.0. You will not need to read raw JSON-RPC on the exam, but knowing the shape (request, response, notification) helps when debugging.

How MCP fits into AI-103

The AI-103 official course (AI-103T00-A) places MCP in Learning Path 2, Module 3: Connect MCP Tools to Azure AI Agents. The module covers the MCP client and server architecture in detail, how to connect Microsoft's official MCP servers to a Foundry agent, the MCPTool class in the Foundry SDK, approval policies and human-in-the-loop patterns, and the tool-execution flow inside an agent run loop.

MCP also shows up implicitly in LP3 Module 2 (Develop a Text Analysis Agent with the Azure Language MCP Server) and LP3 Module 5 (Develop a Speech Agent with the Azure Speech MCP Server). Roughly three out of the eighteen non-vision modules in AI-103 either directly cover or directly use MCP. Expect MCP-flavored questions across the Integrate and Deploy AI Solutions domain, which is weighted at 20 to 25% of the exam.

If you score badly on MCP scenario questions in a practice run, that domain alone can drop you below the pass line. (If you're still deciding between exams, our guide to moving from the retired AI-102 to AI-103 is the right starting point.)

The official Azure MCP servers Microsoft ships in 2026

You do not need to write a server from scratch to use MCP. Microsoft publishes managed MCP servers for the most common Foundry capabilities. As of May 2026, the production servers include:

Server	Hostname pattern	What it exposes
Azure Language MCP	{resource}.cognitiveservices.azure.com/language/mcp	NER, sentiment, key phrase extraction, language detection, PII redaction, summarization, text analytics for health, conversational language understanding, custom question answering
Azure Speech MCP	{resource}.cognitiveservices.azure.com/speech/mcp	Speech-to-text recognition, text-to-speech synthesis
Azure MCP Server (DevOps)	Configured via azd or the VS Code extension	Azure resource management, ARM queries, deployment helpers, used inside GitHub Copilot agent mode

A useful exam fact: the Azure Language MCP server exposes nine tools behind a single endpoint. From the agent's point of view, that means one MCP connection unlocks nine separate analytical capabilities, and the agent decides which to call. No routing code on your side.

A useful operational fact: the Azure Speech MCP server requires an Azure Blob Storage account with a SAS URL (Read, Add, Create, Write, List permissions) for audio I/O. This is the kind of detail that turns into an exam question.

Connecting an MCP tool to a Foundry agent

Here is the minimum viable Python code to wire the Azure Language MCP server into a Foundry agent using the Foundry SDK. This is the shape the AI-103 exam expects you to recognize.

import os
from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import MCPTool
from azure.identity import DefaultAzureCredential

project = AIProjectClient(
    endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
    credential=DefaultAzureCredential(),
)

language_mcp = MCPTool(
    server_label="azure-language",
    server_url=(
        f"https://{os.environ['LANGUAGE_RESOURCE']}.cognitiveservices.azure.com"
        "/language/mcp?api-version=2025-11-15-preview"
    ),
    require_approval="always",
)

agent = project.agents.create_agent(
    model="gpt-4o",
    name="text-analysis-agent",
    instructions=(
        "You analyze short text for sentiment, named entities, "
        "and key phrases. Use tools when needed and explain your reasoning."
    ),
    tools=[language_mcp],
)

thread = project.agents.threads.create()
project.agents.messages.create(
    thread_id=thread.id,
    role="user",
    content=(
        "Analyze the sentiment of this review: "
        "'The hotel was beautiful but the food was awful.'"
    ),
)

run = project.agents.runs.create_and_process(
    thread_id=thread.id,
    agent_id=agent.id,
)

A few details worth highlighting before you sit the exam.

The server_label is a free-form identifier. It does not have to match the server's actual hostname; it is what the SDK uses internally when logging and when surfacing approval requests to your host application.

The require_approval parameter is the one that confuses people the most. The three valid values are "always", "once", and "never". Always means every tool invocation requires the host application to explicitly approve before execution. Once means the first invocation requires approval and subsequent calls within the same run are auto-approved. Never means tools execute without confirmation. For any agent that takes a destructive action (writes, deletes, sends emails, calls billable APIs) "always" is the correct setting and the exam tests this.

You do not need to define tool schemas, parameters, or descriptions yourself. The MCP client fetches them from the server when the connection is established. This is the whole point of the protocol, and it is exactly the difference the exam asks you to recognize between MCP and hand-rolled function calling.

MCP vs hand-rolled function calling

This is the comparison question the exam loves. Use the table below.

Concern	Hand-rolled function calling	MCP
Tool definition lives where	In your application source code	In the server, fetched at runtime
Adding a new tool	Edit app, redeploy	Add it on the server, agent picks it up
Cross-framework portability	Tool must be rewritten per framework	Same server works across any MCP-compliant host
Discovery	Hard-coded	Dynamic at runtime
Approval flow	You build it yourself	Standard, built into the protocol
Best for	Tightly controlled, small tool surface	Multi-team, multi-source, evolving tool surface
Latency overhead	Lower (one less hop)	Slightly higher (server round-trip)
Exam guidance	Acceptable for simple, in-process tools	Required answer when the scenario mentions runtime discovery, multiple teams, or third-party tools

A scenario the exam likes: "Your organization wants the agent to pick up new analytical capabilities without redeploying the agent service. Which integration approach should you choose?" The answer is MCP, every time.

The approval model in depth

Approval is the safety primitive in MCP. It is not optional design surface; it is part of the protocol.

When require_approval="always", the run loop pauses after the model decides to call a tool but before the tool actually executes. The Foundry SDK surfaces an approval request to your host application. Your application then either approves or rejects. If approved, the tool runs and the result flows back to the model. If rejected, the model receives a tool-call-rejected signal and decides what to do next, usually by trying a different tool or asking the user for clarification.

The exam expects you to know three things about this.

First, the approval pauses the run; it is not async fire-and-forget. Your application code must respond before the run can continue.

Second, the same tool can be called multiple times in a single run. Each call gets its own approval check under "always" and one approval up-front under "once".

Third, "never" should not be the default in production. The exam asks scenario questions where a candidate is tempted to pick "never" for convenience or latency; the correct answer is "always" for any tool that performs a write, sends data outside the tenant, or has financial impact.

Where teams go wrong with MCP in production

These are common failure patterns in Azure AI Foundry deployments, and they are the same patterns the exam scenario questions are built from.

Teams set require_approval="never" early in development for speed, and forget to switch back. A model misinterprets a user request, calls a destructive tool, and there is no human in the loop. Mitigation: never deploy an agent to production without an explicit review of every MCP tool's approval setting. Treat it like a security review.

Teams pin to a single MCP server URL in code without an environment variable. When the underlying Azure resource is rebuilt, the URL changes and the agent silently fails its tool discovery. Mitigation: route every MCP endpoint through environment variables or Foundry connections, and add a startup health check that verifies the agent can list tools.

Teams treat MCP server health as someone else's problem. When the language server is down, the agent's response degrades silently. The model attempts the call, gets back an error, and either improvises or apologizes to the user. Mitigation: emit traces and metrics for every tool call, and alert when a tool error rate spikes.

Teams use MCP for everything, including small in-process Python helpers that have no business living behind a server. The result is added latency and operational overhead for no benefit. Mitigation: judgment. If the tool runs in your own process, fits in fifty lines of Python, and is unlikely to be shared with another agent, native function calling is the right choice.

Teams forget that the model decides which tool to call, not the developer. If two tools have overlapping descriptions, the model will pick wrong, and no amount of system-prompt engineering fixes ambiguous tool descriptions reliably. Mitigation: write tool descriptions like API documentation, and test with realistic prompts before shipping.

Multi-agent orchestration with MCP

This is where MCP gets interesting and where AI-103 stops testing it directly and starts testing it implicitly through orchestration scenarios.

When you build a multi-agent system using the Microsoft Agent Framework, each agent can have its own MCP toolset. A handoff from a triage agent to a billing agent can carry context but not tools; the billing agent has its own MCP connections (to your billing system, say) that the triage agent does not. This separation of tool scope by agent role is the cleanest pattern in 2026 for keeping blast radius small. If the triage agent is compromised by a prompt injection, it cannot reach into the billing system, because it never had the billing MCP server registered to begin with.

We covered the four orchestration patterns (sequential, concurrent, group chat, handoff) in detail in our Semantic Kernel guide. MCP plugs into all four. The exam does not require you to write the orchestration code, but it does test whether you know that tool scope follows agent role, not the other way around.

Building your own MCP server

You can, and at some point you will need to. Microsoft's official servers cover Foundry-native capabilities, but if you have an internal system (a CRM, a ticketing system, an internal knowledge base) you will want it accessible to your agents via MCP rather than as a one-off function-calling shim.

At a high level, building an MCP server means:

1. Pick the official MCP SDK in your preferred language. Python, TypeScript, C#, Go, and Java are all official.
2. Declare your tools, resources, and prompts in code.
3. Implement the handlers for each.
4. Host the server. Locally over stdio for dev, in a container or Azure Container App for production.
5. Register the server's URL with the Foundry agent via MCPTool.

The details (handling state, authorization, telemetry, scaling, observability) are beyond the scope of this guide. Our AI-103 hands-on labs cover MCP in a pre-provisioned Foundry environment - you wire a custom MCP server to an agent, configure approval flows, and practice against the failure patterns above. Exact server names and extensions are subject to the final lab release.

Study strategy for the MCP section of AI-103

Two weeks before the exam, run through this sequence.

Days 1 to 2. Build the minimal connection above to the Azure Language MCP server. Verify you can get a sentiment analysis result back. Read every error you get carefully, most exam scenarios are dressed-up versions of real error states.

Days 3 to 4. Repeat with the Azure Speech MCP server. You will hit one new dependency: an Azure Blob Storage account with a SAS URL for audio I/O. Knowing this requirement is a high-frequency exam fact.

Days 5 to 7. Experiment with require_approval. Build a tiny host loop that surfaces approval requests to stdout and accepts y/n from the keyboard. Switch between always, once, and never and observe the behavior. Pay attention to what happens on rejection.

Days 8 to 10. Read the Foundry SDK reference for MCPTool, ToolApproval, and RequiredAction carefully. Note which parameters are required and which have defaults. Exam questions often turn on a default value.

Days 11 to 14. Practice scenario questions where the answer hinges on choosing between MCP and hand-rolled function calling. Get fast at recognizing the trigger phrases: "multiple teams," "runtime discovery," "new tools without redeployment," "third-party integration."

Frequently asked questions

What does MCP stand for?

Model Context Protocol. It is an open standard for connecting AI applications to external tools, data, and prompt templates.

Who created MCP?

Anthropic published the specification and reference implementation in November 2024. The specification was donated to the Linux Foundation's Agentic AI Foundation in December 2025, making it a vendor-neutral industry standard.

Is MCP only for Anthropic models?

No. MCP is model-agnostic. It works with OpenAI's GPT-4o, Anthropic's Claude, Microsoft's Phi, Meta's Llama, Mistral, and any other model that an MCP-compliant host can drive. On AI-103, you will primarily see MCP used with GPT-4o.

Do I need to know MCP for AI-103?

Yes. Learning Path 2 Module 3 is dedicated to it, and modules in Learning Path 3 use it. Expect multiple scenario questions where MCP versus hand-rolled function calling is the choice the candidate has to make.

What is the difference between an MCP tool and a Foundry agent tool?

A Foundry agent tool is anything an agent can call: a native Python function, an OpenAPI endpoint, a code interpreter, or an MCP server. An MCP tool is one specific kind of agent tool, one that lives behind an MCP server and is discovered at runtime. Every MCP tool is an agent tool; not every agent tool is an MCP tool.

Can I use the same MCP server from multiple agents?

Yes, and you should. That is the whole point. One Azure Language MCP server can be wired into a sentiment agent, a moderation agent, a customer-support agent, and a content classifier without any duplication of integration code.

What is the right require_approval setting for production?

"always" for any tool that writes, deletes, sends external messages, or incurs cost. "once" is acceptable for read-only tools on data the user has already authorized. "never" should be reserved for low-stakes, idempotent read operations and is almost never the right answer on a scenario question.

Where does MCP run, in my process or remotely?

Either. Local servers communicate over stdio and are common in developer tooling. Remote servers run over HTTPS and are how Microsoft ships its managed servers. The choice is operational, not architectural.

Is MCP a replacement for OpenAI function calling?

No. MCP sits on top of function calling. Under the hood, an MCP-enabled agent still uses the model's function-calling capability to decide which tool to invoke. MCP adds a discovery layer and a transport layer. The two are complementary, not competing.

Does MCP add latency?

Yes, modestly. A remote MCP call adds one network round-trip versus an in-process function call. For most enterprise applications, the latency is negligible compared to the LLM inference itself. If you are building a latency-critical agent and your tool is local and tiny, native function calling is faster.

Where to go next

If you have not already, read our AI-103 Study Guide for the full curriculum map, and our Azure AI Foundry Explainer for the platform context. Once you are comfortable with MCP, the natural next step is our Semantic Kernel guide, which covers the agent framework that wraps MCP in your application code. Switching from the older exam? See AI-102 has retired: what to do now.

The hands-on advantage

Reading about MCP gets you maybe half the way to the exam. The other half is recognizing what happens when an MCP connection times out, when a tool description is malformed, when a SAS URL has the wrong permissions, or when your approval handler returns an unexpected error.

Our AI-103 hands-on labs include MCP as part of the agent-integration module. You work in a pre-provisioned Foundry sandbox - no Azure subscription required, no "spin up a project and hope nothing breaks." The labs cover wiring an MCP server to an agent, setting approval policies, and troubleshooting the connection and failure patterns we walked through above. Exact lab scenarios are subject to the final curriculum release.

View pricing · Try a free lab

---

Related: What Is an AI Engineer in 2026? Role, Skills & Path