Tag / llm

A manga themed image with a coffee cup saying MCP dev and a blog post within a laptop title with the blog post.
by Simon Doy

My experiences Building Secure MCP Powered Microsoft Cowork Plugins


Introduction

This article discusses my experiences when building Microsoft 365 Copilot Cowork Plugins, which are powered by a secure custom MCP Server.

Why Cowork and Cowork Plugins?

Microsoft 365 Copilot Cowork is an evolution of Anthropic’s Claude Cowork. The tool is very versatile and enables the user to run multiple agent-based tasks at the same time. The backbone of Cowork is its skills framework which gives it the capabilities it needs. These skills allow it do things which can do, including creating and updating Microsoft Word, Excel, PowerPoint content, performing deep research, investigations, and more.

The difference between Copilot Cowork and Claude Cowork is that Copilot Cowork runs in the cloud and is always on, whereas Claude Cowork runs from your machine so is only on when your machine is on. 

I have to admit I have not used Claude Cowork, but my understanding is that Claude Cowork can also then drive your machine, which gives it an advantage in terms of Computer Use capabilities.

Cowork can access your Microsoft 365 data as Copilot can with hooks into your Email, Team discussions, SharePoint, Calendar entries and more.

These skills are great, and they allow you to define processes in detailed markdown files. These skills allow an organisation to define how to perform this work is done by Cowork. Up until Plugins, these skills were managed by each individual, and there was no way to share skills or have centralised skills.

This all changed with Cowork plugins, which allow you to deploy skills through a centralised mechanism.

However, all of this is great, but to really help you do more at work, Cowork needs to be able to access your business systems.

This is where Cowork Plugins come in, because as well as defining a skill, you can also tell them about your MCP servers. This enables you to provide a structured way for Cowork to access your business system. Through Cowork Plugins, you can provide a centrally managed set of Plugins which can then be added, updated, versioned and deployed to your teams.

Now we are talking!

Current state of Cowork Plugins

  • The current state of Cowork plugins is that they are in preview, and they are a bit rough around the edges. For example, the management of Cowork plugins isn’t quite there. So, for example, you can add them, but until recently, when Stephan Bisser discovered you could use the Integrated Apps page, there was no way to delete them.

Also, upgrading them is possible, but if you have automated the installation and deployment to a user or group of users, then this is broken now.

In this post, I am going to show you how to create a Cowork Plugin, how to build an MCP Server which is secured by Entra ID Authentication and how we can bring that MCP Server into the Cowork plugin, so that Cowork can make use of it.

How to access Cowork and Cowork Plugins

First, at the time of writing, Microsoft 365 Copilot Cowork is only available if your organisation has enabled Frontier access. You can find out how to do this by following this article:

Get Started with Frontier for IT Admins | Microsoft Frontier

Second, you can access your Plugins through Cowork, as shown below.

  • Fire up Cowork
  • Click on the + and then Manage plugins.
  • You will see a list of the Cowork plugins that have been made available to you.
  • Click on Browse plugins to allow you to install other plugins.

If you want to ensure that a plugin is available when you are kicking off a task in Cowork, make sure you have switched on the plugin.

How to build a Cowork Plugin

So, let’s get to building our Cowork plugin. In my example, we use a task and time management system called Toggl

Helping with everyone’s favourite job

One of the things that we all love doing is filing in your timesheets, don’t we?!

Well, how about if we could get Cowork to help us with this task?

We could ask it to look at our calendar and then automate the filling out of the user’s Toggl and fill out all the timesheets.

Something like this

Hopefully, the demo shows you the power of Cowork and these plugins. What is nice about it is that because you have the skill to describe how to do the task or tasks, these plugins can do more than one job, but you can guide them on how you want them to work.

For example, it is important that we allocate the right project and it is the right project for the right client. So I have asked Cowork to clarify anything that is unclear with or where there are duplicate project names.

Getting started

The following resources were used as a reference for building Cowork plugins; these are all found on Microsoft Learn.

https://learn.microsoft.com/en-us/microsoft-365/copilot/cowork/cowork-plugin-development

What do you need?

Well, you need an idea for your plugin. In our example, we are going to build a plugin to allow a user to fill out their timesheet.

So, to do this, we need the following:

  • A Toggl MCP Server that is secured by Entra ID
  • Entra ID Applications for your MCP Server and one for your MCP Client
  • Visual Studio Code
  • Ability to package up the Cowork Plugin.
  • Configuration within Teams Dev Portal.

Let’s get started.

MCP Server Secured by Entra ID

So first, we need an MCP Server that is secured by Entra ID. I have written a blog post called “Building a secure MCP Server with Entra ID”, which contains a template to create your MCP Server from.

You can find this blog post here

Building a Secure Custom MCP Server secured by Microsoft Entra ID | Doy’s Microsoft 365 and Azure Dev Blog

Once you have downloaded and set up your secure MCP Server secured by Entra ID, then you can start building out your plugin and skill.

Building your Copilot Cowork Plugin

So, I will be honest, I have been using GitHub Copilot a lot, and generally these days I get GitHub Copilot to scaffold out the plugin and help me write the skill. I will share with you via my GitHub repo the skill that I have for Toggl, so you can see what I have.

Cowork Plugins follow a similar pattern to other Microsoft 365 Apps. This approach Is used by Microsoft Teams Apps, Declarative Agents, etc., in that they are a zip file which contains a manifest, a set of icons and then the resources for the Cowork plugin.

The Microsoft Learn Article, Build Cowork Plugins, has all the details, so you can read this, but I will talk about the key points and the gotchas that I went through.

https://learn.microsoft.com/en-us/microsoft-365/copilot/cowork/cowork-plugin-development

The plugin file structure is something like this (this is taken from the Microsoft Learn article)

my-extension.zip

In the article, there is a section which shows you how to build a plugin from scratch

https://learn.microsoft.com/en-us/microsoft-365/copilot/cowork/cowork-plugin-development#build-a-plugin-from-scratch

To get going, I opened Visual Studio Code.

  • I created a folder for each plugin that I was building, and then created a subfolder called skills and then a subfolder within skills with the name of my plugin.
  • Then I added a SKILL.md file which details my skills.
  • I then asked GitHub Copilot

It scaffolded the rest of the structure and created a reusable PowerShell script, which will then package up the plugins into individual zip files.

I have made this all available on GitHub, so take a look. You will be able to access the final result here (minus a couple of URLs).

https://github.com/SimonDoy/microsoft365-dev-samples/tree/main/cowork-toggl-plugin-example

So I would suggest that you clone this repo and use it to get started.

Once you have cloned the repo and downloaded your plugin, you will need to update it for your needs. This is handled by two key files: the manifest.json and the SKILL.md file.

Let’s start with the manifest.json and talk through this.

Firstly, we need to fill out the version number, update the ID and packageName to your specific organisation.

Next, we need to give it a good name and description.

As we get down to the bottom, this is where the exciting stuff lives. There is a section called agentSkills.

Here is where we point to our folder with our SKILL.md file.

Next is the really exciting bit. The agentConnectors section.

Here we provide an id for our connector, a name and a description of what the connector can do.

Finally, we provide the URL to our MCP Server, which includes the MCP endpoint.

Underneath, we provide authorisation information. Now, when I first read this, I thought the reference ID was just maybe the MCP Client ID we created when we created our secure MCP Server. Please see my blog article on writing a Secure MCP Server to understand what I am saying here.

Building a Secure Custom MCP Server secured by Microsoft Entra ID

These Cowork Plugins can support Anonymous Authentication, API Tokens (not tried) and OAuth or Open authentication.

However, this is something completely different and requires you to set up an asset via the Microsoft Teams Developer Portal.

What to do to Get your OAuthPluginVault ReferenceId?

So, to get a reference ID for your plugin, what do you need to do?

Well, you’ll need to go to the Microsoft Teams Developer Portal

https://dev.teams.microsoft.com

  • Click on Tools.
  • Click on Microsoft Entra SSO Client ID registration
  • From here, click on New client registration

Once you have filled this all out, save your entry, and you will get a screen that displays your registration ID.

You need to update your plugins manifest.json and set the reference ID to this value.

You will also need to go and add this Application ID URI to your MCP Server’s list of Application ID URIs.

This is achieved by editing your manifest file from within the Microsoft Entra ID, App Registrations

  • Browse to https://entra.microsoft.com
  • Click on App registrations under the Entra ID heading
  • Find your MCP Server Entra ID application
  • Choose Manifest and find the identifierUris array JSON.
  • Add the specified URI to the bottom of the array.
  • Save your settings.

And ensure that the Microsoft Enterprise Token Store App is able to call our MCP Server app.

  • Add ab3be6b7-f5df-413d-ac2d-abf1e3fd9c0b

Now, one thing at the time of writing, we need to have our Entra ID applications configured as multi-tenant. I ended up having to set the identifier URIs to be either a valid domain that has been validated against the Microsoft 365 tenant or use the api://[clientid] naming convention.

Once this is done, then you can switch your app reg to multi-tenant and secure it against just your tenant by doing the following:

  • From your App Registration screen in Microsoft Entra ID
  • Click on Authentication, choose Supported accounts
  • Change to Multiple Entra ID tenants.
  • Choose just your tenant id.
  • Click Save

Next, we need to switch focus to our MCP Client that we are using to connect to our MCP Server.

We also need to ensure that the MCP Client is set up for Multiple Entra ID Tenants.

We also need to add a redirect URL for Web Authentication.

This allows the token to be retrieved and stored in the Microsoft Enterprise Token store (probably).

Package your plugin

Now you can save everything and package up your plugin.

  • Check your manifest, check your icons. Make sure you color.png is 192x192px in size and your outline is 32px by 32px.
  • From a terminal run
    • ./package-cowork-plugins.ps1 -PluginsPath “projects”
  • This will create a folder called dist and a zip file with the name of the subfolder time-tracking-toggl.zip.

This zip file is your plugin.

Install the Plugin

To install the plugin, we need to go to the Microsoft 365 Admin Centre or (MAC).

  • Choose the … at the top of the list of agents
  • Choose Add agent
  • Upload your file and click Next
  • Choose who can see your Plugin.
  • Be careful about auto-deploying the plugin, as I have had issues then upgrading a plugin that has been deployed.
  • Follow the wizard until you have successfully installed the Plugin.

You should see a successful screen, but then if you browse the list of agents, you cannot see your plugin anymore. This is just how it is at this time.

  • Now, Stephan Bisser pointed out that you can view your plugins by clicking on Settings->Integrated Apps

Now I can search from the Available Apps tab.

Enabling your Copilot Cowork Plugin.

Now you are ready to enable your Cowork Plugin.

  • Click on the +
  • Choose Manage plugins
  • Choose Browse plugins
  • From Discover, find your Plugin
  • Click on the Plugin you want to add.
  • Click Add
  • Because this plugin requires authentication, you will need to connect it by clicking on Connect below.

Now, here you will find out if you have set up everything correctly.

If you click on Connect and nothing happens, then check your configuration on the Development Teams Portal.

Right, we should be ready to try it out.

Try out your Cowork plugin

So, let’s try it out. In the following video, you can see what happens.

  • You need to enable your plugin before you kick off the prompt.
  • Now I type out this prompt.

“Please add today’s work tasks from my calendar into Toggl”

Cowork will kick off and connect to the Calendar, and look at the appointments. It then connects to the Toggl MCP Server and tries to resolve the tasks in the calendar to projects and entries in my calendar.

It will air on the side of caution and not add projects to the tasks that it is not sure of.

After a few seconds, the Toggl timesheet has been completed based on the tasks from today.

Cowork Plugin Upgrade Gotchas

Before I wrap up this post, there are a couple of gotchas that I want to mention.

  1. Upgrading the Plugin does not work if you have deployed the plugin to any users. You get an error saying that you have already deployed this version of the plugin.
  2. Make sure when upgrading the plugin, you update the version number in the manifest and the SKILL.md file.
  3. I have seen upgrades silently fail when the color.png icon is not 192px by 192px. The upgrade package is updated, but then nothing happens.
  4. Upgrades to Cowork plugins seem pretty quick, normally within a few minutes.

Conclusion

In this post, we showed you how to create a Cowork plugin with a skill and consume an MCP Server that is secured by Entra ID. We covered the steps needed to set it up correctly, and I hope you try it out with your own MCP server implementations.

There are a few things to say about Microsoft Cowork. We are not sure what the licensing will be, and it is still in public preview, so take the chance to try it out and see how you get on.

As it is still in preview, it’s still a bit rough around the edges, but updates and improvements are happening all the time. As you can see from the demo, it is a really powerful tool, and I am excited to see what people build with it.

Let me know how you get on and what your thoughts are on how you would use it.

AI Generated Image of Simon Doy with thumbups and elements related to Azure, Model Context Protocol, AI, Copilot Studio and Containers displayed in the background.
by Simon Doy

How to: Build a Custom MCP Server with the .NET MCP SDK, host as an Azure Container and connect to Copilot Studio


This blog post is part of a series of blog posts on my experiences building Custom Model Context Protocol Servers.

You can find the first in the blog post series, I would recommend starting there.

Unfortunately, it got a little delayed by my having a heart attack at the end of August. Fortunately, I am very lucky. Did you know that if you have a heart attack outside of a hospital, you have a survival rate of 8/100.

Fortunately, I was at home with my kids, and one of them was with me when I collapsed. They got help from my heroic neighbours, who did CPR and brought me back to life. This, plus the fact that I live in a city which is only 10 minutes away from a hospital, meant I was one of the fortunate ones who was only down for 5-6 minutes, and within 3 hours I had had heart surgery and was in ICU.

What I will say to you, dear reader, is if you have what you think is heartburn, but it only comes on when you do exercise, please go and get checked out by the doctor.

I am still on the road to recovery, but I am very happy to be here and say that I am making good progress, and it’s time to start blogging properly again.

This document describes the trials and tribulations of building an MCP Server for LinkedIn with the .NET MCP SDK Toolkit and then hosting it in Microsoft Azure using the Azure Container Instance Service. This MCP Server is then going to be integrated into a Copilot Studio-built Agent. I will show you how to do this; unfortunately, I cannot share the code for the LinkedIn integration.

So, let’s get started.

High-level Steps

The following high-level steps are required to deliver an MCP Server.

  • Build MCP Server
  • Test Locally
  • Configure Visual Studio to build the container container
  • Set up Azure Container Repository
  • Set up Azure App Service
  • Publish and Deploy Container
  • Test, Debug with MCP Inspector
  • Setup MCP Server
  • Connect MCP with Copilot Studio Agent

Build your MCP Server

So, the first step is to build your MCP Server. It does not really matter what your MCP Server does, but using the details that I provided in my previous post. I built my MCP Server using the following:

  • Fire up Visual Studio 2022
  • Created a new Console Project called i365.LinkedInMcpServer
  • Added the following packages
    • Microsoft.AspNetCore.Authentication.JwtBearer – Version=”9.0.11”
    • Microsoft.Extensions.Hosting – Version=”9.0.11”
    • Microsoft.Identity.Web Version=”4.1.1″
    • ModelContextProtocol Version=”0.5.0-preview.1″
    • ModelContextProtocol.AspNetCore Version=”0.5.0-preview.1″
  • I added a Program.cs file and configured it so that a WebApplicationBuilder class was created and contained the configuration of the WebApplication.
  • You can see the code in the associated GitHub Repo.

I edited the project file and added several configuration items to set up container support for the project. This allows me to create a container which will be used to host the MCP Server. I wanted to be able to test this locally before pushing up to Azure, which is made easier by being able to run the process locally.

 <PropertyGroup>
    <EnableSdkContainerSupport>true</EnableSdkContainerSupport>
    <ContainerRepository>ithink365/ithinkexamplemcp</ContainerRepository>
    <ContainerRegistry>[container-registry-prefix].azurecr.io</ContainerRegistry>
    <ContainerFamily>alpine</ContainerFamily>
    <ContainerRuntimeIdentifiers>linux-x64;linux-arm64</ContainerRuntimeIdentifiers>
    <ContainerBaseImage>mcr.microsoft.com/dotnet/sdk:9.0</ContainerBaseImage>
    <UserSecretsId>[UserSecretId]</UserSecretsId>
  </PropertyGroup>

Next, for the tools that are provided by the MCP Server.

The MCP Server tool that I am showing here is a simple tool which will echo what has been sent to it. My real example was building a set of tools for LinkedIn for my company, but the approach is the same.

Create a class which will host your MCP Server and decorate it with the following attributes.

  • McpServerToolType attribute is applied to the class.
  • McpServerTool attribute is applied to each function that exposes a tool to the MCP Server.
  • Description attributes are important and allow you to describe to the calling MCP Client what the function does and also what the role is for each parameter that is passed into the function.

Once you have set up your MCP Server Tool and configured the Program.cs you are ready to go.

The first time I fired up the MCP Server in Visual Studio, I hit a couple of issues, which I will cover now so that you don’t have the same problem.

Firstly, I needed to redirect the ports for the MCP Server that it was listening to on this port to allow the MCP Server to listen to the requests.

You can read about how to resolve this in the Port Fun section below.

Debugging and Testing your MCP Server

Currently, the best way to test the MCP Server is by using MCP Inspector. However, I am having some challenges using MCP Inspector when testing MCP Servers that are protected by Microsoft Entra ID. This is due to an issue with how the MCP Protocol is described vs how the OAuth Protocol has been described. The MCP Protocol is stricter than the underlying OAuth protocol, and this is causing an issue because of how Entra ID works with resource parameters.

I have found that using the following to run MCP Inspector from a PowerShell script works well.

  • npx @modelcontextprotocol/inspector dotnet run

Once you have your MCP Server running in your Visual Studio debugger and your MCP Inspector running, you can test it by connecting your MCP Inspector to the /mcp endpoint provided by your MCP Server when running locally.

To connect MCP Inspector to your MCP Server, simply

  • fill in the URL, ensuring you have added the right port and /mcp on the end.
  • Click Connect
  • Click on Tools in the middle and click List Tools.
  • Your tools should load up after a few seconds, and now you can test each tool.

Deploying to the Cloud

Once you have tested your MCP Server, then you are ready to deploy it to the Cloud. You will need a few bits of Azure Infrastructure including the following:

  • Resource Group
  • Azure Container Registry
  • Azure App Service
  • Storage Account

Setting up the Azure Infrastructure

Create a new resource group in your desired location. Add the Azure Container Registry, Azure App Services and Storage Accounts.

Make note of the Azure Container Registry Connection String.

As you will need that to configure the publishing of your container from within Visual Studio.

Port Fun

It turns out that MCP Servers running on Azure Containers are not happy on the default ports provided, as they run on 8080.

To resolve this, I used the following environment variable to change the container to use a different port. This fixed my problems.

To set up the environment variables, do the following. This can all be done within Visual Studio:

  • Open up your MCP Project file
  • Create the following environment variables in the project file
<ItemGroup>
   <ContainerEnvironmentVariable Include="ASPNETCORE_URLS " Value="http://*:8080;http://*:5000" />
   <ContainerEnvironmentVariable Include="ASPNETCORE_HTTP_PORTS " Value="8080;5000" />
 </ItemGroup>

Fun and Games with SSL and Azure Container Instances.

The original intention was to use an Azure Container Instance and access it directly. I had to come up with another plan because the process of setting up SSL within an Azure Container Instance just seemed too painful.

Change of Plan

The issue with setting up SSL and Azure Container Instances gave me some food for thought.

The challenge is how to ensure that all communication is through an encrypted channel.

When we are running our MCP Server as an Azure Container Instance, it means that we have to have SSL termination happening within the container. Which looked really painful from a couple of different sides, in particular, having to keep updating the SSL certificate when it expired was going to add some admin overhead. So, I looked at different options.

We could implement containers behind Azure API Management as an option.

Additionally, we could use Azure Functions, which was going to be my preferred option. However, at the time of setting this up, I hit an issue where, because we want to integrate MCP with Copilot Studio, we had a mismatch with protocols.

Azure Functions, at the time of writing this blog post, only supported SSE, and Copilot Studio has just deprecated SSE support.

I can see that updates have been made to the MCP Azure Functions SDK, and they now support Streamable HTTP. I am going to take a look at this next.

My other option was to use an Azure App Service to host the container. It turns out that this works well and solves my problem with SSL. At the same time, I can still use the container that I had already built and tested to host the MCP Server. Result!

So, what was involved?

Deploying MCP Server

It is possible to deploy the MCP Server from Visual Studio using the publish feature.

To deploy the container into the Azure Container Repository, do the following

  • Ensure that you have set up the Visual Studio Project settings as mentioned above.
  • Right-click your Project that hosts your MCP Server
  • Choose Publish
  • Click New Profile
  • Choose Azure
  • Click Next
  • Choose Azure Container Registry
  • Click Next
  • Choose the Azure Container Registry by selecting the Azure Subscription.
  • Choose the Azure Container Registry that you have created.
  • Click Next
  • Choose .NET SDK (No Dockerfile required)
  • Click Finish

Now you are ready to publish your Container to the Azure Container Registry.

  • Ensure your Azure Container Registry is selected
  • Click Publish

Wait for the deployment to be completed.

Setting the MCP Server as an App Service

I created an Azure App Service within the same resource group and Azure subscription that the Azure Container Registry had been provisioned within.

To configure the Azure App Service:

  • Click on Deployment -> Deployment Centre
  • Add a Custom Container and configure the container to be loaded from the Azure Container Registry by choosing the Azure Subscription and Image.
  • Set the Port to 8080
  • Click Apply.

This will deploy the Azure Container to the Azure App Service.

Updating your MCP Server

Of course, one of the challenges is updating the MCP server because we are deploying and updating a container; we need to notify the host of the MVP Server, the App Service, that an update has taken place. I really should look at how to automate this. Maybe I will once I have published this.

The steps are to go to the Deployment Centre on the App Service and click the Sync button. Acknowledge the warning that things will be updated and let it take place.

In my experience, this takes a bit longer than you think. After 5 minutes or so, your MCP server will be up to date. I have started to tweak the description of the MCP server so that I can see when it’s updated.

If you use the MCP Inspector, you will start to experience delays in the MCP connecting, and that is the sign that it has been updated.

Updating your MCP Server with Azure DevOps Pipelines

I have found that updating through publishing via Visual Studio is a little unreliable at times. I believe that this is down to authentication issues when authenticating with the Azure Container Registry.

To resolve this, I have built a series of Azure DevOps Pipelines, which are used to build and release the MCP Server to the Azure Container Repository and then deploy to the Azure App Service.

I will document this in a separate blog article.

Linking the MCP Server to Copilot Studio

The process of hooking up and making the MCP server available to Copilot Studio is much easier than I was expecting.

First, we need to create a custom connector which will be targeted at the MCP server.

  • Browse to https://make.powerapps.com
  • Click on Custom Connectors
    • If you cannot see Custom Connectors, click More and then Discover All
swagger: '2.0'
info:
  title: Contoso
  description: MCP Test Specification, YAML for streamable MCP support in Copilot Studio
  version: 1.0.0
host: contoso.com
basePath: /
schemes:
  - https
paths:
  /mcp:
    post:
      summary: Contoso Lead Management Server
      x-ms-agentic-protocol: mcp-streamable-1.0
      operationId: InvokeMCP
      responses:
        '200':
          description: Success

  • Click on New Custom Connector
  • Choose Import an OpenAPI File
  • Choose your mcp-server-openapi-schema.json file
  • Click Continue
  • Ensure your Host URL is correct and the same as your Azure App Service.
  • Ensure Base URL is /
  • Give the MCP Server a suitable name and description.
  • Click Security

For this MCP Server, there is no authentication, but we should have authentication, preferably with Entra ID OAuth 2.0 style authentication.

I will be putting together a guide to enable an MCP Server with authentication in a future post.

  • Click Definition
  • Update the Summary Name
  • Update the Connector Name
  • Check the URL for the Invoke MCP command

Once happy then

  • Click Create Connector

Once we have created the custom connector, we can consume it through our Copilot Studio Agent. The process of publishing the connector will create a new MCP tool within the Power Platform environment, and then this can be added to your agent.

  • Browse to your Agent
  • Click Tools
  • Click “Add a Tool”
  • Choose your MCP Server
  • You will be asked to create a connection to the MCP Server.
  • Click Add and Configure
  • After a short period of time you should see a list of tools appear.
  • Now enable/disable the tools that the MCP Server provides.

Recently, there was an update so you can choose which tools are available to your Agent, so enable the ones you want and disable the ones you don’t want.

Now you can publish and test your agent.

Try it out.

Of course, you will need to make sure your agent is enabled to use the MCP tool and has orchestration enabled.

Conclusion

In this blog post, I explained how to set up an MCP server to be hosted in a secure and encrypted environment using Azure App Service. I also explained how to deploy and update the MCP Server, and finally test it and connect it up to Copilot Studio.

I’d love to hear how your MCP Server experiences are going and if you found this useful.

My plans for the next post in this series are to build and deploy an MCP server with Azure Functions, explain how we can deliver Azure Dev Ops pipelines to build and release our MCP Server container, discuss authentication so that you can secure your MCP Servers and finally, I want to look into the recent update to Declarative Agents which now support Model Context Protocol!

Check out the Microsoft Dev Blogs Post.