1 Overview: One Standard for Tools Across Every AI App

Every framework in this course so far — raw function calling (tutorial 12), Semantic Kernel plugins (tutorial 17), AutoGen's function map (tutorial 19) — solves tool integration the same way but with its own bespoke registration mechanics. If your organization builds five AI applications, each one re-implements its own connection to the same internal order system, the same ticketing API, the same document store. The Model Context Protocol, MCP, exists to fix exactly this duplication: it is an open standard for how AI applications discover and call tools and context sources exposed by independent servers, so a tool built once — an MCP server — can be used by any compliant AI application, regardless of which framework or vendor built it.

This advanced tutorial covers MCP end to end: an introduction to what problem it solves and why it matters; its architecture — hosts, clients, servers, and the tools/resources/prompts it exposes; building an MCP server in .NET; integrating MCP with the agents you built in tutorials 17–19; and connecting an agent to enterprise data via MCP, the concrete payoff this whole standard exists for. Everything here builds directly on tutorial 12's function-calling mechanics and tutorial 20's agent-first governance — MCP does not replace either, it standardizes how tools are packaged and shared.

2 Learning Objectives

• Explain what the Model Context Protocol is and the interoperability problem it solves across AI applications.
• Describe MCP architecture: hosts, clients, servers, transports, and the tool/resource/prompt capability model.
• Build a minimal MCP server in .NET exposing a tool with capability discovery.
• Integrate an MCP server with an agent (Semantic Kernel or AutoGen) so the model can call MCP tools like any other function.
• Connect an agent to an enterprise data source via MCP, applying least privilege and server-side authorization.

3 Prerequisites

• Tutorial 12's function-calling mechanics: describing a function, the model requesting it, code executing and returning a result.
• Tutorial 17 (Semantic Kernel plugins) or tutorial 19 (AutoGen function maps) — at least one agent framework you can integrate MCP into.
• Tutorial 20's governance concepts: capability scoping, policy engines, and least privilege, which apply directly to MCP servers.
• Basic familiarity with JSON-RPC or any RPC-style protocol is helpful but not required — this tutorial explains what's needed.

4 Key Concepts: A Contract Instead of a Convention

Every framework you've used defines tools its own way: Semantic Kernel with [KernelFunction] attributes, AutoGen with a function map, raw function calling with hand-written JSON schemas. These are conventions, each internal to one library. MCP is a contract: any MCP server, regardless of what language or framework built it, exposes its tools in the same protocol shape, and any MCP client, regardless of what framework it's embedded in, can discover and call them the same way. The payoff is interoperability — a tool built once is usable everywhere, not re-wired per framework.

The remaining sections build this up concretely: MCP architecture explains how host, client, and server relate and communicate; building an MCP server shows the shape of a real one in .NET; integrating MCP with agents connects it back to the frameworks from tutorials 17–19; and connecting an agent to enterprise data via MCP is the concrete business case — the reason organizations build MCP servers at all.

5 Deep Dive 1: Introduction to the Model Context Protocol

MCP addresses a specific pain point that emerges once an organization builds more than one AI application: N applications each needing to talk to M internal systems traditionally means N×M bespoke integrations — every chatbot re-implementing its own order-lookup tool, every internal assistant re-implementing its own ticketing integration. MCP turns this into N+M: each system is wrapped once as an MCP server, and each application only needs one MCP client capable of speaking the protocol to reach any of them.

MCP is an open standard, not tied to one vendor or one AI framework — a server built for one AI application can, in principle, be used by an application built with a different framework or even a different vendor's model, as long as both speak the protocol. This is the same interoperability value proposition as REST for web APIs or ODBC for databases: a shared contract that lets independently built pieces interoperate without prior coordination between their authors.

6 Deep Dive 2: MCP Architecture

Three roles make up an MCP system. The MCP host is the AI application itself — a chat app, an agent framework, an IDE assistant — that orchestrates the overall experience and decides when to reach for external tools. The MCP client is a component the host embeds that handles the protocol mechanics: connecting to a server, performing capability discovery (asking 'what do you offer?'), and issuing calls. The MCP server is the standalone process that actually implements tools, resources, and prompts, running independently of any particular host — often as a separate process on the same machine, or a remote service.

Communication happens over a transport — commonly standard input/output for a local server process the host launches, or HTTP-based transports for a remote server — carrying messages formatted as JSON-RPC, a lightweight standard for structuring remote procedure calls as JSON. Before any real work happens, the client and server perform protocol version negotiation (agreeing on a compatible protocol version) and then capability discovery, where the client asks the server for its manifest: the list of tools, resources, and prompts it exposes, each with a name, description, and schema — exactly the same information tutorial 12 hand-wrote and tutorial 17 generated from attributes, now declared once by the server itself.

7 Deep Dive 3: Building an MCP Server

Building an MCP server in .NET follows the same shape as any tool you've defined so far — name, description, parameters, implementation — wrapped in the protocol's server scaffolding. An SDK handles the JSON-RPC and transport plumbing; your job is declaring the server's capabilities and implementing them, with the same tutorial-12 discipline (validate arguments, authorize, keep idempotent, return structured errors) inside every tool.

using ModelContextProtocol.Server;   // illustrative namespace -- verify against the current SDK

var builder = Host.CreateApplicationBuilder(args);
builder.Services
    .AddMcpServer()
    .WithStdioServerTransport()          // local process, communicates over stdio
    .WithToolsFromAssembly();             // discovers [McpServerTool]-attributed methods

var app = builder.Build();
await app.RunAsync();

// The tool itself: same shape as a tutorial-17 native function, now MCP-attributed.
public static class OrderTools
{
    [McpServerTool, Description("Gets the status and delivery estimate of an order by its order number.")]
    public static async Task<string> GetOrderStatus(
        [Description("The order number, e.g. ORD-1042")] string orderNumber)
    {
        if (!orderNumber.StartsWith("ORD-"))
            return "{\"error\":\"invalid order number format\"}";

        var status = await OrderRepository.FindAsync(orderNumber);
        return status is null
            ? "{\"error\":\"order not found\"}"
            : $"{{\"stage\":\"{status.Stage}\",\"eta\":\"{status.Eta}\"}}";
    }
}

Notice how little of this is new: the tool implementation is identical in spirit to tutorial 17's OrderPlugin — validate, look up, return compact structured JSON or a structured error. What's new is the hosting shell around it: AddMcpServer registers the protocol machinery, a transport (stdio here, HTTP for a remote server) defines how clients reach it, and WithToolsFromAssembly performs the capability discovery a client will later query, generating the server manifest from your [McpServerTool]-attributed methods and their [Description] attributes automatically.

8 Deep Dive 4: Integrating MCP with Agents and Connecting to Enterprise Data

Integrating MCP with agents means an agent framework's MCP client discovers a server's tools and presents them to the model exactly like any native plugin function — the model doesn't know or care whether a tool call resolves to a local [KernelFunction] or a remote MCP server; from its perspective, both are just named functions with descriptions and parameters. In Semantic Kernel, an MCP client's discovered tools can be added to a kernel's plugin collection alongside native functions; in AutoGen, they can populate a function map the same way a hand-written delegate would.

using ModelContextProtocol.Client;

// Connect to an MCP server (here, a local process) and discover its tools.
await using McpClient mcpClient = await McpClient.ConnectAsync(
    new StdioClientTransport(command: "dotnet", args: ["run", "--project", "OrderMcpServer"]));

IList<McpClientTool> discoveredTools = await mcpClient.ListToolsAsync();

// The kernel treats MCP-discovered tools the same as native [KernelFunction]s --
// the model sees one uniform set of callable functions regardless of origin.
kernel.Plugins.AddFromFunctions("OrderMcpTools", discoveredTools.Select(t => t.AsKernelFunction()));

var agent = new ChatCompletionAgent
{
    Instructions = "Use the available tools to answer order questions.",
    Kernel = kernel   // now includes both native plugins and MCP-discovered tools
};

This is exactly how connecting an agent to enterprise data via MCP works in practice: rather than writing a bespoke native function that directly queries a CRM, ticketing system, or internal database from inside the agent process (as tutorial 12 and tutorial 17 did for a mock order repository), an organization builds one MCP server that wraps that enterprise data source, with its own server-side authorization, connection credentials, and rate limiting entirely separate from any particular agent. Any agent — built with Semantic Kernel, AutoGen, or another framework — connects to that same server and inherits its governed access, instead of every agent team re-implementing and re-securing its own direct connection to the enterprise system.

9 Ecosystem and Tools

MCP sits at the same architectural layer as tutorial 20's agent-first patterns: it is one concrete, standardized way to implement 'a reusable tool server' that many agents can discover and use, addressing the agent communication and governance concerns from that tutorial specifically for tools and enterprise data access.

10 Use Cases

• Shared enterprise data access: one MCP server wraps an order management system; every internal AI application (support bot, sales assistant, ops dashboard) connects to the same governed server instead of re-integrating.
• Cross-framework tool sharing: a tool built as an MCP server can be consumed by a Semantic Kernel-based app and an AutoGen-based app without maintaining two separate implementations.
• Vendor-neutral tool ecosystems: an organization publishes internal MCP servers that any team's AI project can adopt, regardless of which agent framework that team chooses.
• IDE and developer tool integration: MCP servers exposing code search, documentation lookup, or build tooling let AI coding assistants reach project-specific context uniformly.
• Third-party data and service integration: external providers expose their APIs as MCP servers so any compliant AI application can integrate without a bespoke SDK per provider.
• Governed data access layers: a data platform team builds one MCP server with strict server-side authorization and audit logging in front of sensitive enterprise data, and every downstream agent inherits that governance automatically.

The throughline is reuse across boundaries — framework boundaries, team boundaries, and vendor boundaries — which is precisely the interoperability problem MCP exists to solve.

11 Code Examples

These examples show a slightly fuller MCP server with a resource alongside a tool, and the client-side discovery-plus-invocation pattern.

public static class SupportTools
{
    [McpServerTool, Description("Creates a support ticket from a summary and priority.")]
    public static async Task<string> CreateTicket(
        [Description("A short summary of the issue")] string summary,
        [Description("low, normal, or high")] string priority)
    {
        if (priority is not ("low" or "normal" or "high"))
            return "{\"error\":\"invalid priority\"}";
        var ticket = await TicketRepository.CreateAsync(summary, priority);
        return $"{{\"ticketId\":\"{ticket.Id}\"}}";
    }

    [McpServerResource, Description("The current support escalation policy document.")]
    public static Task<string> EscalationPolicy() => PolicyStore.ReadAsync("escalation-policy");
}

await using McpClient client = await McpClient.ConnectAsync(
    new StdioClientTransport(command: "dotnet", args: ["run", "--project", "SupportMcpServer"]));

// Capability discovery: ask the server what it offers before using anything.
IList<McpClientTool> tools = await client.ListToolsAsync();
logger.LogInformation("Discovered {Count} tools: {Names}",
    tools.Count, string.Join(", ", tools.Select(t => t.Name)));

// A direct call, outside any agent, showing the raw request/response shape.
McpToolResult result = await client.CallToolAsync(
    "CreateTicket",
    new Dictionary<string, object?> { ["summary"] = "Login page 500 error", ["priority"] = "high" });
Console.WriteLine(result.Content);

[McpServerTool, Description("Gets a customer's account balance.")]
public static async Task<string> GetAccountBalance(
    [Description("The account id")] string accountId,
    McpServerRequestContext context)   // illustrative: how server-side identity might be surfaced
{
    // Server-side authorization: never trust the caller to have already checked this.
    string callerIdentity = context.RequestingIdentity;
    if (!await AuthorizationService.CanAccessAccountAsync(callerIdentity, accountId))
        return "{\"error\":\"not authorized for this account\"}";

    decimal balance = await AccountRepository.GetBalanceAsync(accountId);
    return $"{{\"accountId\":\"{accountId}\",\"balance\":{balance}}}";
}

12 Step by Step: An MCP Server for Enterprise Order Data, Consumed by an Agent

This walkthrough builds a small MCP server wrapping a mock enterprise order system, then connects a Semantic Kernel agent to it — demonstrating the full introduction-through-enterprise-data arc of this tutorial.

1. Create a new console project for the MCP server and add the MCP .NET SDK package; scaffold it with AddMcpServer and a stdio transport, following Example/deep-dive 3's shape.
2. Implement GetOrderStatus as an [McpServerTool]-attributed method wrapping your mock OrderRepository, with the same validation and structured-error discipline as tutorial 12.
3. Run the server standalone and, using a minimal test client (Example 2's pattern), call ListToolsAsync to confirm capability discovery returns the tool with its name, description, and parameter schema.
4. Add server-side authorization: require a caller identity and check it against which orders that identity may view, refusing (with a structured error) rather than trusting the caller.
5. Create a separate console project for the agent, referencing tutorial 17's Semantic Kernel setup, and connect an McpClient to the order server process.
6. Merge the MCP-discovered tools into the kernel's plugin collection alongside (or instead of) any native plugins, and create a ChatCompletionAgent with instructions to use them for order questions.
7. Ask the agent 'Where is my order ORD-1042?' and confirm the request actually crosses the process boundary to the MCP server and back — verify with logging on both sides.
8. Test the authorization boundary: have the agent attempt (via a crafted question) to access an order it should not be authorized for, and confirm the server refuses rather than the agent voluntarily declining.
9. Add a second, independent client — a plain console app with no agent framework at all — and confirm it can also discover and call the same MCP server's tools, demonstrating the interoperability MCP exists to provide.
10. Reflect on what changed versus tutorial 17's OrderPlugin: the tool logic is nearly identical, but it now lives in its own process, is reachable by any compliant client, and enforces its own authorization independent of whichever agent is calling it.

13 Limitations and Caveats

• SDK and ecosystem caveat: MCP is a young, fast-evolving standard; the .NET SDK's exact types (AddMcpServer, McpServerTool, McpClient, transport classes) are illustrative here and will continue to change — verify against current documentation and the installed package before relying on any signature in this tutorial.
• Protocol overhead is real: an MCP tool call crosses a process (and possibly network) boundary with JSON-RPC serialization, which is slower than an in-process native function call — reserve MCP for tools that genuinely benefit from being externalized and shared, not every function in a system.
• MCP standardizes discovery and invocation, not safety: every governance concern from tutorial 20 (capability scoping, policy engines, sandboxing, audit trails, kill switches) still applies and must be implemented inside the server; the protocol does not provide these for you.
• Trust boundaries require explicit design: an MCP server must perform its own server-side authorization and never assume a connecting client has already validated the caller, since any compliant client can, in principle, connect.
• Transport choice has operational implications: a local stdio server is simple but tied to a single machine/process lifecycle; a remote HTTP server needs its own deployment, scaling, and network security considerations.
• Interoperability depends on both sides actually complying with the standard correctly; a server or client with subtle protocol deviations can fail in ways that are harder to diagnose than a bug in code you fully control.
• Not every tool needs to become an MCP server: a tool used by exactly one application, with no plan to share it, gains protocol overhead and operational complexity without the interoperability benefit that justifies MCP.
• The tool/resource/prompt taxonomy requires judgment: forcing something that's really a resource (static readable data) into a tool shape, or vice versa, works but forfeits some of the protocol's intended benefits (caching, browsability).

14 Best Practices

• Build an MCP server when a tool or data source will genuinely be reused across multiple applications or teams; keep single-app tools as native functions to avoid needless protocol overhead.
• Apply tutorial 12's function-level safety and tutorial 20's capability scoping inside every MCP tool exactly as you would for a native function — the protocol boundary is not a safety boundary by itself.
• Enforce server-side authorization inside the MCP server itself; never trust a connecting client or calling agent to have already checked permissions.
• Choose the right capability type deliberately: tools for actions, resources for readable reference data, prompts for shared reusable instructions — don't force everything into 'tool' shape.
• Keep tool descriptions precise, exactly as in tutorial 12/17/19 — capability discovery surfaces these descriptions to models across every consuming application, so quality here has wide leverage.
• Log and audit MCP server activity independently of any calling agent's own logging, since a server may be called by multiple different agents/applications you don't fully control.
• Version your server's protocol support and capability manifest deliberately, since multiple independently-updated clients may depend on it simultaneously.
• Treat an MCP server wrapping enterprise data with the same governance rigor as any production data-access layer — it is one, regardless of the AI framing.

20 Summary

• The Model Context Protocol standardizes how AI applications discover and call tools/context sources, turning N×M bespoke integrations into N+M by letting each system be wrapped once as a server any compliant client can use.
• MCP architecture has three roles — host (the AI application), client (protocol mechanics, capability discovery), and server (implements tools/resources/prompts) — communicating via JSON-RPC over a transport like stdio or HTTP.
• Building an MCP server in .NET follows tutorial 12's exact tool shape (name, description, parameters, validated implementation) wrapped in protocol-facing scaffolding for discovery and invocation.
• Integrating MCP with agents merges discovered tools into a framework's existing plugin/function collection, so the model sees one uniform tool set regardless of whether execution is in-process or on a remote server.
• Connecting an agent to enterprise data via MCP centralizes credentials, authorization, and audit in one governed server that many agents inherit access from, instead of each team re-implementing and re-securing its own direct connection.
• MCP standardizes discovery and invocation only — every governance control from agent-first architecture (capability scoping, policy engines, sandboxing, audit trails, kill switches) still must be implemented inside the server itself.

MCP extends the tool-calling shape you've built since tutorial 12 across a boundary none of the frameworks alone could cross: any compliant application, any framework, any team. The safety principles don't change — validate, authorize, scope narrowly, govern proportionally — only where they're enforced does: at a server boundary reachable by more than one consumer. With individual agents, architecture, and now standardized, shareable tools in place, the course's final agent-focused tutorial turns to what happens when several agents — potentially built by different teams using different frameworks, all speaking MCP where they need shared tools — must work together as one coordinated multi-agent system.

21 Next Steps

Next tutorial: Multi-Agent Systems (multi-agent-systems). Having covered individual agents (tutorials 17–19), architecture and governance (tutorial 20), and now a standard for sharing tools across agents and applications (this tutorial), the next tutorial brings these together into complete multi-agent systems — synthesizing orchestration patterns, communication models, and MCP-based tool sharing into cohesive, production-oriented designs.

• Practice: build the order-status MCP server from the walkthrough, then connect two independent clients to it — a Semantic Kernel agent and a plain console test client — confirming both can discover and call it.
• Practice: add a deliberate authorization gap to a test MCP server (skip the server-side check) and demonstrate the failure scenario from exam question 11, then fix it and confirm the fix holds.
• Practice: model one tool and one piece of static reference data on the same server, exposing the first as an MCP tool and the second as an MCP resource, and articulate why each fits its type.
• Practice: apply the decision checklist from exam question 14 to three real or hypothetical capabilities in a project you know, and write down which should be native functions versus MCP servers.
• Read: the official Model Context Protocol specification, the MCP .NET SDK documentation, and any current guidance on securing MCP servers in production.