In earlier posts in this series, we’ve explored how to extend AI agents using function tools, how to compose agents together as function tools, and how to build and debug MCP servers in .NET.

In this post, we look at how you can take an existing AI agent built with the Microsoft Agent Framework and expose it as an MCP tool, thereby making it available to any MCP-compatible client.

This is where the two worlds collide.

• We already know how to build agents.
• We already know how to build MCP servers.

 

Now we combine them.

The idea is simple: take an agent, convert it to a function, wrap it as an MCP tool, and serve it over HTTP.

In this blog post, we cover the following:

• What it means to expose an agent as an MCP tool
• Why you would want to do this
• The key NuGet packages required
• How to create an AI agent using direct OpenAI
• How to convert that agent to an MCP tool
• How to host the MCP server with SSE transport
• Testing with MCP Inspector

 

Source code and video demo is included.

Let’s dig in.

~

What Does It Mean to Expose an Agent as an MCP Tool

In the agents as function tools post, we saw how an agent can be converted to an AIFunction using the .AsAIFunction() method.

This allows one agent to call another agent as if it were a regular function tool.

The Model Context Protocol takes this a step further. Instead of one agent calling another agent internally, we expose that agent-as-function to the outside world via an MCP server.

Any MCP-compatible client — VS Code, Claude Desktop, MCP Inspector, or your own custom client — can discover and invoke the agent.

The conversion chain looks like this:

AI Agent → AIFunction → McpServerTool → MCP Server

 

The agent’s name becomes the tool name. The agent’s description becomes the tool description. MCP clients see it as just another tool, they don’t need to know there’s an entire AI agent behind it.

~

Why Expose an Agent as an MCP Tool

There are several reasons you might want to do this:

• Reusability — an agent you’ve already built and tested can be consumed by any MCP-compatible client without writing new integration code
• Standardised access — MCP provides a well-defined protocol so you build once and connect everywhere
• Composability — other agents or tools can discover and call your agent through MCP, enabling multi-agent workflows across different systems
• Separation of concerns — the agent logic lives in your server, and clients simply invoke it over the wire

 

If you’ve been following this series, you’ll recognise the pattern.

In the function tools post, we gave agents the ability to call functions.

In the agents as function tools post, we let agents call other agents.

Now we’re letting anything call our agent -as long as it speaks MCP.

~

Setting Up the Project

The project uses the ASP.NET Core Web SDK since we’re hosting the MCP server over HTTP with SSE transport.

Here’s the project file with the required NuGet packages:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Agents.AI" Version="1.0.0-preview.260205.1" />
    <PackageReference Include="Microsoft.Agents.AI.OpenAI" Version="1.0.0-preview.260205.1" />
    <PackageReference Include="ModelContextProtocol" Version="0.8.0-preview.1" />
    <PackageReference Include="ModelContextProtocol.AspNetCore" Version="0.8.0-preview.1" />
    <PackageReference Include="OpenAI" Version="2.8.0" />
    <PackageReference Include="System.ClientModel" Version="1.8.1" />
  </ItemGroup>
</Project>

 

The key packages to note:

• Microsoft.Agents.AI and Microsoft.Agents.AI.OpenAI — the Microsoft Agent Framework and its OpenAI integration
• ModelContextProtocol and ModelContextProtocol.AspNetCore — the .NET MCP SDK with ASP.NET Core SSE transport support
• OpenAI — the official OpenAI .NET SDK for direct API access

~

The Agent We’re Exposing

For this example, we’re using a nutrition agent that searches for high protein recipes.

If you’ve been following the series, you’ll recognise this from the agents as function tools post where it was used as a sub-agent within our Iron Mind AI personal trainer.

The agent has a single function tool SearchRecipesAsync . This takes a search term, a minimum protein threshold, and a maximum number of results:

public class NutritionAgent
{
    [Description("Searches for high protein recipes optimized for strength training. " +
                 "Returns recipes with detailed nutrition information. " +
                 "Best for finding recipes for 5x5 training, muscle building, or post-workout meals.")]
    public static Task<List<string>> SearchRecipesAsync(
        [Description("Search term (e.g., 'chicken', 'beef', 'protein', 'breakfast')")] string searchTerm,
        [Description("Minimum protein grams per serving (default 20)")] int minProtein = 20,
        [Description("Maximum number of recipes to return (default 3)")] int maxResults = 3)
    {
        var results = _stubRecipes
            .Where(r => r.Title.Contains(searchTerm, StringComparison.OrdinalIgnoreCase) ||
                        r.Ingredients.Any(i => i.Contains(searchTerm, StringComparison.OrdinalIgnoreCase)))
            .Where(r => r.Nutrition != null && r.Nutrition.ProteinGrams >= minProtein)
            .Take(maxResults)
            .Select(r => JsonSerializer.Serialize(r))
            .ToList();

        return Task.FromResult(results);
    }
}

 

The [Description] attributes are crucial here. They tell the AI agent (and ultimately the MCP client) what the function does and what each parameter means. This is the same pattern we covered in the function tools post.

Each recipe is a simple model with nutritional information:

public class Recipe
{
    public string Title { get; set; } = string.Empty;
    public string Url { get; set; } = string.Empty;
    public List<string> Ingredients { get; set; } = new();
    public List<string> Instructions { get; set; } = new();
    public NutritionInfo? Nutrition { get; set; }
    public string PrepTime { get; set; } = string.Empty;
    public string CookTime { get; set; } = string.Empty;
    public int Servings { get; set; }
}

 

We also have a NutrionInfo class :

public class NutritionInfo
{
    public int Calories { get; set; }
    public int ProteinGrams { get; set; }
    public int CarbsGrams { get; set; }
    public int FatGrams { get; set; }
}

~

Creating the Agent and Exposing It as an MCP Tool

This is where it all comes together. The Program.cs file does three things:

1. Creates an AI agent using direct OpenAI
2. Converts the agent to an MCP tool
3. Hosts the MCP server with SSE transport

 

Here’s the full code:

using Agent_Framework_7_Existin_Agent_as_MCP_Tool.Agent;
using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;
using ModelContextProtocol.AspNetCore;
using ModelContextProtocol.Server;
using OpenAI;

string apiKey = "your-openai-api-key";
string model = "gpt-4o-mini";

// Create the nutrition agent using direct OpenAI
AIAgent nutritionAgent = new OpenAIClient(apiKey)
    .GetChatClient(model)
    .AsIChatClient()
    .AsAIAgent(
        instructions: "You can fetch recipes and nutrition data.",
        name: "NutritionAgent",
        description: "An agent that searches for high protein recipes and nutrition information.",
        tools: [AIFunctionFactory.Create(NutritionAgent.SearchRecipesAsync)]
    );

// Convert the agent to an AIFunction and then to an MCP tool.
// The agent name and description will be used as the MCP tool name and description.
McpServerTool tool = McpServerTool.Create(nutritionAgent.AsAIFunction());


// Register the MCP server with SSE transport and expose the tool via the server.
var builder = WebApplication.CreateBuilder(args);
builder.Services
    .AddMcpServer()
    .WithHttpTransport()
    .WithTools([tool]);

var app = builder.Build();

app.MapMcp();
await app.RunAsync();

 

Let’s walk through each part.

~

Creating the Agent

We create an OpenAIClient with our API key, get a chat client for the model, and then use the .AsIChatClient().AsAIAgent() extension method chain to create an AIAgent.

This is the same pattern from earlier posts in the series, but note two things:

• We use .AsIChatClient() before .AsAIAgent().
• We provide a description parameter. This is important because it becomes the MCP tool description that clients will see.

 

Next, we will create the MCP tool from the agent.

~

Converting to an MCP Tool

This is the key line:

McpServerTool tool = McpServerTool.Create(nutritionAgent.AsAIFunction());

Two things happen here.

First, .AsAIFunction() converts the entire agent , including its instructions, tools, and conversation handling, into a single callable function. We used this same method in the agents as function tools post to let one agent call another.

Second, McpServerTool.Create() wraps that function as an MCP tool that can be served to clients.

~

Hosting the MCP Server

We use WebApplication.CreateBuilder and the ModelContextProtocol.AspNetCore package to host the MCP server with HTTP/SSE transport.

The three key calls are:

• .AddMcpServer()  – registers the MCP server services
• .WithHttpTransport() – configures SSE transport over HTTP
• .WithTools([tool]) – registers our agent-as-MCP-tool

 

Finally, app.MapMcp() maps the MCP endpoints and app.RunAsync() starts the server.

By default, the server runs on http://localhost:5000.

~

Testing with MCP Inspector

MCP Inspector is a handy tool for testing MCP servers. You can use it to connect to your server, discover tools, and invoke them.

Step 1: Run the project:

dotnet run

Step 2: Open MCP Inspector and configure the connection:

• Transport Type: SSE
• URL: http://localhost:5000/sse

Step 3: Click Connect. You should see the NutritionAgent tool listed with its description.

Step 4: Select the tool and provide a search term (e.g., “chicken“). Click Run Tool:

The MCP Inspector sends the request to your server. Your server invokes the AI agent, which uses its SearchRecipesAsync function tool to find matching recipes. The results are returned to the MCP Inspector as the tool response.

What’s happening behind the scenes is worth highlighting.

The MCP client sends a tools/call request. Your MCP server receives it and invokes the McpServerTool.

The tool calls the AIFunction, which runs the full AI agent. The agent processes the request using its instructions and function tools, and the result flows back through the chain to the MCP client.

~

Demo

You can see this in action in the 5 minute demo:

~

Summary

In this post, we’ve covered how to take an existing AI agent built with the Microsoft Agent Framework and expose it as an MCP tool.

The key part is that the conversion chain :

Agent → AIFunction → McpServerTool

This bridges two powerful concepts we’ve explored separately in this series.

The important pieces to remember:

• .AsAIFunction() converts an agent into a callable function
• McpServerTool.Create() wraps that function as an MCP tool
• .WithHttpTransport() serves the tool over HTTP with SSE transport
• The agent’s name and description become the MCP tool’s name and description
• Any MCP compatible client can discover and invoke the agent

 

Being able to take an agent you’ve already built and make it available over a standardised protocol is a practical step forward.  You build the agent once, and any MCP client can use it.

~

Further Reading and Resources

Some additional resources you might find helpful.

• Model Context Protocol Specification
• Microsoft Agent Framework GitHub Repository
• MCP Inspector
• ModelContextProtocol .NET SDK
• Building and Debugging Your First MCP Server in .NET
• Using Agents as Function Tools

~

Enjoy what you’ve read, have questions about this content, or would like to see another topic?

Drop me a note below.

You can schedule a call using my Calendly link to discuss consulting and development services.

~

The CountryPhonePostalInfoRepository provides an efficient solution for validating phone numbers and postal codes globally, addressing the complexities of varying formats and rules. It offers a centralized API for reliable country-specific validation, enhancing data integrity in applications while simplifying maintenance and development. This tool ensures accurate, consistent validation logic.

Highlights this week include: Agent Skills for Azure Bicep with GitHub Copilot: From Manual Work to Automated Workflows: learn how to create reusable Agent Skills in GitHub Copilot that package domain expertise into automated workflows for Azure Bicep, including four ready-to-use skills for formatting, type conversion, and Azure Verified Modules migration. Writing Effective Prompts for Testing Scenarios: AI Assisted Quality Engineering: a deep dive into prompt design patterns for AI-assisted testing, covering role-based, few-shot, and context-rich prompting techniques that move QA teams beyond shallow test generation toward reliable, high-coverage outputs. Getting more out of Copilot with Copilot Pages: an overview and live demo of Copilot Pages, which turn Copilot Chat outputs into collaborative, editable canvases that support rich content, real-time co-editing, and seamless sharing across M365 apps.

Building Smarter Agents with FoundryIQ: Microsoft's Agentic RAG Platform: introduces FoundryIQ, a fully managed knowledge layer that enables agentic RAG by autonomously decomposing complex queries, planning multi-source searches, and synthesising answers across SharePoint, Blob Storage, OneLake, and the web. Observability in Generative AI: Building Trust with Systematic Evaluation in Microsoft Foundry: explains how Microsoft Foundry supports GenAIOps observability through evaluators for quality, safety, RAG grounding, and agent behaviour across the full lifecycle from model selection through production monitoring.

Serverless workspaces in Azure Databricks (GA): Azure Databricks serverless workspaces are now generally available, offering a fully managed SaaS experience with pre-configured serverless compute and default storage that eliminates the need for manual networking, cluster, and storage setup. Bringing together Fabric Real-time Intelligence, Notebook and Spark Structured Streaming Preview: a new preview integration lets developers access Eventstreams directly inside Spark Notebooks with auto-generated PySpark code and secure, secret-free connectivity, enabling low-latency real-time analytics and AI pipelines within Microsoft Fabric.

Reference Architecture for Highly Available Multi-Region Azure Kubernetes Service AKS: a practical reference architecture for running AKS across multiple Azure regions using Azure Front Door, geo-replicated data services, and regional ingress layers, with detailed trade-off analysis of active/active, active/passive, and cold standby deployment patterns.

Finally, upcoming community events: Join us at SQLCon 2026 (March 16–20) co-locates with FabCon in Atlanta featuring 50+ SQL sessions and shared keynotes, and SQLBits 2026 returns to ICC Wales (April 22–25) covering SQL Server 2025, Microsoft Fabric, AI-powered analytics, and more. Book your tickets now.

If you're interested in all things Microsoft Fabric - don't forget to sign up for our new newsletter - Fabric Weekly - which we'll start publishing in the next month or so. We'll be moving all Fabric content over from Azure Weekly to Fabric Weekly, just as we did with Power BI Weekly 7 years ago.

I spent the past week experimenting with OpenClaw

You can read my full review here.

OpenClaw (Clawdbot / Moltbot) is the open‑source AI agent that can operate your actual computer. And honestly? It's equal parts impressive, terrifying, and a glimpse of where OS‑level AI is heading.

OpenClaw isn't doing anything radically new on its own. What it does get right is packaging everything developers usually duct‑tape together. This includes:

• Unified installer
• Plug‑and‑play integrations
• Browser automation
• Mobile control
• Low‑friction setup

It's the first time I've seen all of this bundled into something you can install in minutes.

What surprised me most

You can control your PC from Slack or Discord. Yes, really. Tell your desktop to edit files or browse the web while you're away.

Free LLMs work, but only if you give very explicit instructions. Vague tasks often turn into JSON dumps instead of actions.

Browser automation is also still tricky. Navigation works, but form‑filling is hit‑or‑miss on Windows.

Trust is the real question. Giving an AI access to your filesystem and browser is a different psychological leap than using ChatGPT or Copilot.

Should you try it?

If you're curious about where AI‑powered operating systems are headed, OpenClaw is worth a weekend experiment. Just be prepared for some quirks, especially on Windows, and think carefully about how much access you're comfortable granting.

I'm still figuring out how it fits into my workflow, but the potential is undeniable. If you've tried OpenClaw, I’d love to hear what worked (or didn't) for you.

Microsoft argues that Copilot+ PCs are also a new class of PCs built for gaming. In fact, the company says these new Windows 11 AI PCs “take gaming performance further,” but how much RAM (memory) do you need in 2026? According to Microsoft, 16GB is plenty for most games, but 32GB is recommended for serious gamers, ironically at a time when memory prices are rising.

Microsoft has a new marketing campaign for Copilot+ PCs where it tries to answer some of the basic questions, such as how fast the AI PCs are compared to older Windows 10 desktops, and pitches Copilot+ PCs as your solution.

As part of the same campaign, Microsoft is now encouraging gamers to consider “Copilot+ PCs” because it’s a headache to “match parts” and build a gaming PC or laptop.

“Copilot+ PCs are the smart choice to bring it all together,” the company argues in a document spotted by Windows Latest. Microsoft added that 16GB of RAM is plenty for most games, but if you’re a serious player who runs demanding titles or heavy mods, you should look for 32GB of RAM PCs.

Now, you have three options: build your own computer, find laptops that meet all your gaming requirements, or just choose one of the new Copilot+ PCs, which are already optimized for gaming.

Microsoft lists several hardware specs recommended for gaming, including at least 16GB of RAM (32GB ideal for serious gamers), an AMD Ryzen 5 5600 or Intel Core i5-12400, NVIDIA GTX 1660 Super or AMD Radeon RX 6600, SSD, and a high-end monitor. If you have these features, it’s supposedly gaming certified.

Most power gamers prefer to build their own gaming rig. However, Microsoft argues that part-matching is a ‘headache’ and it’s just better to buy a Copilot+ PC, which comes pre-configured with the latest CPU, GPU, thermal, and memory.

“If you’d rather skip the part-matching headache, Copilot+ PCs come pre-configured with the latest CPUs, GPUs, and thermal designs tuned for gaming, so you can dive straight into the action,” Microsoft noted.

Microsoft is making bold claims that its new AI PCs also have the best “thermal designs tuned for gaming,” which makes them a worthy alternative to a full-fledged gaming PC. But it doesn’t tell us how a Copilot+ PC performs in real games, at real settings, against a similarly priced custom build.

Copilot+ PCs are not just “AI” PCs anymore for Microsoft’s marketing team

Also, it looks like Microsoft is slowly selling a new dream for Copilot+ PCs. While originally these PCs were “AI” first because they include an NPU for processing locally, Microsoft is now claiming that AI PCs are also gaming PCs and mixing the message in a way that can confuse regular customers.

In the same campaign, Microsoft lists “recommended” gaming parts like a GTX 1660 Super or RX 6600 and mid-range CPUs. That is fine advice for entry-level gaming, but it does not prove anything about Copilot+ PCs as a “new class” for gaming.

The company also claims these Copilot+ PCs are “faster than MacBook Air M4” and “up to 5x faster than a 5-year-old Windows device,” but it won’t comment on M4 Max or even M5 (base).

The post Microsoft says 32GB RAM is ideal for serious gamers on Windows 11, recommends Copilot+ PCs for gaming appeared first on Windows Latest

Has the rise of hyper-addictive digital technologies really shattered our attention spans and driven books out of our culture? Maybe not, argues social psychologist Adam Mastroianni (author of the Substack Experimental History): As a psychologist, I used to study claims like these for a living, so I know that the mind is primed to believe narratives of decline. We have a much lower standard of evidence for "bad thing go up" than we do for "bad thing go down." Unsurprisingly, then, stories about the end of reading tend to leave out some inconvenient data points. For example, book sales were higher in 2025 than they were in 2019, and only a bit below their high point in the pandemic. Independent bookstores are booming, not busting; at least 422 new indie shops opened in the United States last year alone. Even Barnes & Noble is cool again. The actual data on reading, meanwhile, isn't as apocalyptic as the headlines imply. Gallup surveys suggest that some mega-readers (11+ books per year) have become moderate readers (1-5 books per year), but they don't find any other major trends over the past three decades. Other surveys document similarly moderate declines. For instance, data from the National Endowment for the Arts finds a slight decrease in the percentage of U.S. adults who read any book in 2022 (49%) compared to 2012 (55%). And the American Time Use Survey shows a dip in reading time from 2003 to 2023. Ultimately, the plausibility of the "death of reading" thesis depends on two judgment calls. First, do these effects strike you as big or small...? The second judgment call: Do you expect these trends to continue, plateau, or even reverse...? There are signs that the digital invasion of our attention is beginning to stall. We seem to have passed peak social media — time spent on the apps has started to slide. App developers are finding it harder and harder to squeeze more attention out of our eyeballs, and it turns out that having your eyeballs squeezed hurts, so people aren't sticking around for it... Fact #2: Reading has already survived several major incursions, which suggests it's more appealing than we thought. Radio, TV, dial-up, Wi-Fi, TikTok — none of it has been enough to snuff out the human desire to point our pupils at words on paper... It is remarkable, even miraculous, that people who possess the most addictive devices ever invented will occasionally choose to turn those devices off and pick up a book instead. The authors mocks the "death of reading" hypothesis for implying that all the world's avid readers "were just filling time with great works of literature until TikTok came along."

Read more of this story at Slashdot.