Jekyll2026-06-03T13:02:33+00:00https://nullpointer.se/feed.xmlThe Nullpointer BlogBlog created in Jekyll, theme [Minima v2.5.1](https://github.com/jekyll/minima/blob/v2.5.1/_config.yml).Andreas AdnerThe new MCP spec and the unfortunate deprecation of MCP Sampling2026-05-25T00:00:00+00:002026-05-25T00:00:00+00:00https://nullpointer.se/the-unfortunate-deprecation-of-mcp-sampling
Greetings from beautiful Portorož in Slovenia, where I am joining Jonas Rapp to present a session titled “How and why did we implement AI Chat in FetchXML Builder?” at the DynamicsMinds conference. We are talking about our fun collaboration from last year, where we added AI chatbot functionality to Jonas’ tool FetchXML Builder - one of the most widely used Power Platform community tools (even mentioned in the official docs!).
This was a fun project, since it was an “infusion of AI” into an existing codebase, running on “legacy” technology (.NET Framework), rather than the greenfield AI projects I usually do. You can read more about my contribution in my blog post The anatomy of FetchXML Builder with AI from last summer.
So, if you are at DynamicsMinds, please come by and say hi!
But now, let’s put fun conferences aside, and get back to talking about AI protocols.
New MCP specification!
The MCP specification is evolving, and a release candidate for the next version of the spec (2026-07-28) was announced a couple of days ago by Den Delimarsky (former Microsoft, now working with MCP at Anthropic) and David Soria Parra (part of the Technical Staff at Anthropic). It is said to be “the largest revision of the protocol since launch”, and it comes with a few goodies:
Stateless core - No more initialization handshakes or session IDs, which helps with load balancers, etc.
MCP Apps ships as an official extension - Great news, since MCP Apps is by far one of the most exciting parts of the MCP spec, and something that I have written about extensively lately, for example:
A demo of how to use MCP Apps UI components in Microsoft 365 Copilot.
A demo of how to embed Claude Code in a terminal, as an MCP Apps agent in M365 Copilot.
…among many other changes. They are also introducing a Feature Lifecycle Policy for MCP features, which allows the maintainers of the MCP spec to formalize the lifecycle around MCP features - that can now be Active, Deprecated and Removed. A change in the lifecycle status of a feature comes with a 12-month window between deprecation and removal, to allow consumers to adapt. This is a good thing, I guess…
The missed opportunity of the MCP Sampling feature
What is not so good is that they are also deprecating what is probably my favourite feature in the MCP Spec (well, except for MCP Apps, of course) - MCP Sampling.
Despite its name, MCP Sampling has nothing to do with music - it is a way for MCP Server tools to “piggy back” on the MCP client’s Large Language Model, and use that LLM for completions. In the words of the specification:
The Model Context Protocol (MCP) provides a standardized way for servers to request LLM sampling (“completions” or “generations”) from language models via clients. This flow allows clients to maintain control over model access, selection, and permissions while enabling servers to leverage AI capabilities—with no server API keys necessary. Servers can request text, audio, or image-based interactions and optionally include context from MCP servers in their prompts.
So, this basically gives the MCP Server tool access to its own LLM (borrowed from the client), and it requires no AI plumbing on the MCP Server side, and no API key - the MCP client pays for the inference!
I have blogged and posted about this feature extensively for the last year, and explored it in various ways:
In this blog post I use MCP Sampling to allow an MCP tool to dynamically generate reports, based on user input.
In my LinkedIn post“What if your MCP Server could think for itself?” I explore a related MCP feature - SEP-1577 Sampling with Tools - a feature that made the Sampling capability even more powerful, by allowing LLM calls made by the tool through Sampling to also be able to call other MCP Server tools.
This could have been a real game-changer, since with the “Sampling with tools” feature the MCP Server could take over the steering-wheel and drive its own agentic loop, all on its own, using the client’s model. This inverts the typical MCP control flow: instead of the client orchestrating everything, the tool itself becomes an agent orchestrator - able to reason, call other MCP tools and iterate until it arrives at an answer. All while borrowing the client’s LLM, and on the client’s dime.
Think about what that unlocks. For example, a research_topic tool no longer has to return a single canned answer - it can fan out across a dozen searches, read and summarize the results, follow the promising threads, and synthesize a final report before handing anything back. A fix_bug tool can plan an approach, edit a file, run the tests, observe the failure, and try again. A domain-expert MCP Server - say, one that knows everything there is to know about Dataverse, FetchXML, or Power Platform licensing - can host a full agent loop server-side, but the user still gets to pick which model powers it and who pays for the tokens.
This is all really sad - it sure feels like a lost opportunity to make MCP Servers more intelligent, autonomous and agentic.
Low adoption - Yes, that is true, sort of - and maybe not as true as it used to be. VS Code has had good, although experimental support for Sampling for a long time, and I have done all my experiments there. But looking at the official list of supported MCP Clients, that list is actually pretty long, nowadays.
Complex to implement - Perhaps true, but hasn’t stopped many clients from shipping it.
The deprecation wasn’t without debate, as can be seen from the comments to SEP-2577, but I am not really seeing anyone mentioning the main benefit that I see with sampling, and that I mention above - all the agentic capabilities it opens up.
Even though the new MCP Spec is not set in stone, I am assuming this will be the death of MCP Sampling. Farewell, old friend - a brief, brilliant run that hinted at a more agentic future for MCP. I hate to see you go.
The silver lining? Thanks to that brand new Feature Lifecycle Policy, MCP Sampling won’t actually disappear for at least 12 months after the deprecating spec ships - so if you have never built an MCP Server that uses Sampling, now is the time to give it a try. Go grab some inference tokens on the client’s tab while you still can!
Until next time, happy hacking!
]]>Andreas AdnerThe death of BizApps and the rise of the agentic Power Platform2026-05-03T00:00:00+00:002026-05-03T00:00:00+00:00https://nullpointer.se/the-agentification-of-power-platform
Sometime last summer, it started to dawn on me that business applications as we know them might soon be a thing of the past.
I had been experimenting with the Model Context Protocol for a while, building custom agents that read and wrote to Dataverse directly - no UI in between. Talking to my business application in natural language, with MCP doing the plumbing, was unexpectedly delightful - and surprisingly productive. If you are interested, you can find some of my early experiments with Dataverse and MCP here and here.
It was early days, before the release of the official Dataverse MCP Server - so I had to roll my own - which turned out to be surprisingly easy, especially given the fact that LLMs are really good at FetchXML 😊.
Accessing Dataverse from an agent in this way was fun and all, but it became pretty clear that text might not be the optimal modality for using business applications, mainly because it is painfully slow (local speech-to-text helps somewhat, see this demo). This got me thinking - what if the agent could surface user interfaces when the user needs them - in addition to text?
Once again, it was early days and there wasn’t much available in terms of standards or specifications for agentic user interfaces. AG-UI, OpenAI Apps SDK and MCP Apps, all of which I’d later spend a lot of time exploring, hadn’t been announced yet. So, lacking official specs and tooling, I started rolling my own agent UIs.
Nowhere near enterprise-ready, but during this time I built a few demos that explored these ideas. One of them showed a bespoke agent UI that pulled in Power Apps screens when needed, and rendered reports dynamically from natural language:
We started showing this to customers, and the response was simply overwhelming. “We want this!” they said after nearly every demo - the idea that you could just ask for what you needed and have the right UI appear, instead of clicking through menus and tabs, clearly struck a chord.
But there was a problem: the technology simply wasn’t there. These were just demos, and even though the benefits of agent UIs were clear, shipping this to customers felt a long way off.
Some specs, finally
But then last autumn, things started happening. First, quietly on the open-source side, MCP-UI showed up - an early attempt at formalizing how agent UIs could be served over MCP (here’s my demo from August). Then the frontier labs followed:
MCP Apps - announced in November, as an extension to the MCP protocol from Anthropic.
MCP Apps was directly inspired by MCP-UI, so credit to the MCP-UI team for paving the way.
Going back a bit further - last spring, a small, then-unknown company called CopilotKit released AG-UI, the spec that, more than any other, piqued my interest in agent UIs. I’ve since explored it in depth, including a session at AgentCon (video summary) and in a conversation with Rasmus Wulff Jensen. For deeper dives, see my LinkedIn writeups here and here.
One specific concept in AG-UI - Shared state between the UI and the agent orchestrator, and a core part of the AG-UI spec - is, in my view, the single biggest unlock for agent UIs, and one piece that is still missing as support for agent UIs finally lands in mainstream Microsoft tools. Shared state unlocks some really transformative user experiences, such as these:
Suddenly, the demos from a year earlier didn’t look quite so far-fetched - the pieces in the agentic UI puzzle were starting to come together.
The death of BizApps
So while agent UI standards started emerging at the end of last year, support for them was still lacking in the Microsoft ecosystem. Our customers were eager to start trying these experiences in Microsoft Teams and M365 Copilot, but as it turned out - they would have to wait a bit longer.
But inside Microsoft, these kinds of ideas had apparently been brewing for quite some time. Already back in December 2024, on the BG2 podcast Satya Nadella famously predicted the eventual death of SaaS applications as we know them, in favor of AI orchestration layers that serve agents directly.
“As the guy at Microsoft who works on business applications, sometimes the truth hurts, but business apps as we know it are indeed dead … Instead, what will probably happen is you’ll see this ossification of these classic biz apps, the emergence of this new AI layer, which is very focused around automation and completing tasks in a way that extends the team of humans and people with these AI agents that go and do work .. You’re going to have a generative UI, which AI dynamically authors and renders on the fly to exactly match what the person’s trying to do .. The gist of it is yes, indeed, biz apps, the age of biz apps is over.”
The coming war of the AI Capabilities Layer
And it’s not just the apps. At the Power Platform Community Conference 2025 in Las Vegas, Lamanna delivered the line that lit up the low-code community: “Low code is dead, as we know it.” That caused quite a stir - but seven months on, it looks less like the low-code frameworks themselves are dying, and more like the way we use them is changing. Instead of clicking around a designer to build a low-code app, we’re letting our agents build them using a CLI. See for example this demo of Copilot Studio agents built with Claude Code and agent skills. Honestly, I didn’t see that one coming.
Another harbinger of things to come - and one I have quoted repeatedly - is Lane Swenka’s blog post from last summer, laying out a new direction for Power Platform admin tools: a transition from UX-first to API-first. The scope was seemingly limited to admin tooling, but in hindsight it was pretty clear that it pointed to something bigger - an API-first shift across the whole Power Platform, to cater for the needs of AI agents.
Recently, this article by Todd Trotter about the Capabilities Layer - the architecture and plumbing needed to serve AI agents - is one of the best summaries I’ve read of where all this is heading, and what it means for the Power Platform.
“AI needs applications to describe what they can do, what their constraints are, and what state they are operating against. They need a surface that is designed to be composed … That surface is the Capabilities Layer. It sits between your application services and any consumer - human, agent, or orchestrator - and it exposes typed tools, structured data resources, and interactive UX components through MCP.”
One concept in particular stands out - the idea of “micro-frontends”:
“Micro-frontends apply service-style decomposition to the user interface by splitting the frontend into independently developed and deployed features or components that are composed into a larger experience.”
Some corporate-speak, sure - but he’s basically saying the same thing as Charles Lamanna was saying: the user experiences of the future will surface when they’re needed, with just the UI elements the user needs, no more, no less. We’re heading toward a world where dynamically surfaced, agent-centric “micro experiences” are the norm.
So the vision from Microsoft is pretty clear: agentic user experiences FTW, and the infrastructure, APIs and MCPs to support them. And they’re not the only ones reaching this conclusion - Salesforce’s recent Headless 360 announcement is the same play, and SAP, ServiceNow and the rest are also doing it. The platforms are being (re)built to be consumed by an army of autonomous agents, and the human-facing UIs - when they’re needed - will be dynamic and served by the agents.
The writing is on the wall; this is the war that’s coming. And when the dust settles, the winner will be the provider with the best Capabilities Layer for agents - and the best support for agent UIs.
But vision is one thing; execution is another. With the coming clash of the titans to build the best capabilities layer as backdrop, let’s look at what Microsoft has actually shipped lately in this space.
The rise of the agentic Power Platform
In all honesty, being passionate about agent user experiences and at the same time being a consultant in the Microsoft space last year wasn’t all that great. With the explosion of specifications in the agent UI space we saw late last year, I had high hopes that these capabilities would be promptly made available in the Microsoft tech stacks. Perhaps support for MCP Apps for Copilot Studio agents? Or why not an iteration on the Adaptive Card spec to support dynamic user interfaces? Or maybe AG-UI support in M365 Copilot? One could only dream…
But Ignite 2025 came and went without any real announcements in this space, so I kept waiting and hoping, hoping and waiting. And good things come to those who wait, because on the 9th of March 2026, somewhat hidden in the Microsoft 365 Copilot Blog was this little nugget:
Support for OpenAI Apps SDK was already available, with MCP Apps coming soon. I found some really cool samples which I used to create my own demo:
This feature was part of a capability exclusive to Microsoft 365 Copilot declarative agents, marketed as “interactive UI widgets”, part of “MCP plugin actions” (more info here).
For some reason, all these new fancy capabilities related to support for agentic UI protocols were implemented for declarative agents, a technology I hadn’t tried before - I had mostly dabbled with Copilot Studio agents and agents built with custom code (referred to as custom engine agents in the M365 Copilot nomenclature). So this gave me the chance to explore declarative agents, which was pretty interesting.
Then, it was announced that it was possible to use M365 Copilot agents in a Power App. At first glance, the benefit of this is to run the main M365 Copilot agent from a Power App - which is already grounded in your organization’s data, but which now also indexes the data in your Power App environment. It’s not the first time we have seen Copilots in Dynamics/Power Apps, but this time it seems to actually work pretty great:
A limitation of this “standard” M365 Copilot agent is that it can’t really “do” anything in Dataverse - it can read data just fine, but it can’t modify anything.
To remedy this, you can also access your custom agents (declarative, Copilot Studio or custom engine agent) from M365 Copilot in your Power App, and this is where it starts to become really cool! I created a demo of this, once again using the Microsoft samples. This means that if your custom agent is equipped with e.g. the Dataverse MCP Server, it can update data in Dataverse. One big limitation currently is that the custom agent has no context - it doesn’t know which Power App/form/view/record it is using:
I hope that this will change soon - context-awareness for custom agents is such an unlock that it should have been implemented yesterday…
Next was the announcement that your Power App could expose its own MCP Server, which came with a set of custom MCP Apps UI tools. You could then download it as a declarative Copilot agent package, which you could deploy to your tenant. I created a demo of this as well:
Then came the announcement that custom tools could be added to your Power Apps, which became part of the MCP plugin actions when you exported the Power App as a declarative agent. Demo here.
And then on April 7 came the big one - support for MCP Apps in declarative Copilot agents! Since I had already created an MCP Server with some cool-looking MCP Apps UI components, I simply added them to a declarative agent which resulted in my most successful LinkedIn post to date:
So, it feels like Microsoft is firing on all cylinders when it comes to agentic UIs, at least when it comes to declarative Copilot agents. The state of things has improved enormously since last year. So, kudos to everyone at Microsoft, and while we’re at it - here is my wishlist:
Pretty please with sugar on top - make it possible for custom agents to be aware of their Power Apps context. Please?
Let’s make it possible for all Copilot agents to use MCP Apps, not just declarative agents. Here’s an idea - make MCP Apps support a general functionality in M365 Copilot, that works for all agent types - declarative, Copilot Studio and custom engine agents. And perhaps in Teams too?
Add a way to limit the number of user approvals needed when using MCP action plugins in declarative Copilot agents. There is so much clicking. 😉
Implement some smart way of providing context to an agent UI that is synchronized with the agent backend. Similar to the context management feature in AG-UI. As stated above, this is the one thing that more than anything else unlocks the possibility to build real agentic applications.
What’s next?
So, we have talked about the agentic UI layer. But what about the AI Capabilities Layer that will power the rise of the autonomous agentic workforce? It seems to me that Microsoft is currently consolidating this capabilities layer under the Work IQ umbrella, at least when it comes to Microsoft 365 and Dataverse. A set of MCP Servers is available that could allow agents to interact with Microsoft services on behalf of the user, and eventually also autonomously - under their own agentic identity. I have played around with the Work IQ MCP Servers, and they are pretty neat.
But who is winning? On agent UIs, Microsoft has caught up impressively fast in just a few months. On the Capabilities Layer it might be a different game - one where the other big firms are moving in parallel and fast. One can only assume that massive efforts are underway internally at Microsoft to build out this Capabilities Layer and respond in force to Salesforce Headless 360, and the others. All the major players have reached the same conclusion - that the race for the AI capability stack is the race for the next era of enterprise software, and there are no prizes for second place. Game on!
So, are BizApps dead? Yes, it seems so. A year has passed, and I’d say it’s even clearer than it seemed back then. It’s still early days, but in a matter of months we could have dynamically generated agentic user interfaces and a mature capabilities layer that can power our agents, and honestly - who needs a business application then?
As always, thanks for reading and until next time - happy hacking!
]]>Andreas AdnerDeclarative Agents with Work IQ MCP Servers2026-04-06T00:00:00+00:002026-04-06T00:00:00+00:00https://nullpointer.se/declarative-agent-work-iq
It has been a while since I last looked into Agent 365 SDK, and since then a couple of interesting things have happened.
First of all, a release date has been announced for Microsoft 365 E7, a new type of license that includes Agent 365 capabilities. It is worth noting that the parts of Agent 365 that have to do with agentic identities and autonomous agentic users will not be GA on 1st of May, and licensing details regarding this are yet to be announced. This is a bit of a bummer, since I have spent a lot of time the last few months exploring the agentic parts of Agent 365 (see for example here and here), and it would have been cool to be able to test it in production. But for the time being, agentic users stays in the Frontier program and we’ll have to wait a bit longer until the agentic bits become generally available. Good things to those who wait!
The parts of Agent 365 that go GA in May are all about agents acting “on-behalf-of” the user, as well as a lot of agent governance goodies. Check out this Agent 365 AMA for a deep-dive, and a good explanation of what is coming in May.
Another thing that has happened is that the Agent 365 tooling servers have been rebranded to Work IQ MCP. This is how Work IQ is described by Microsoft:
“Work IQ is the intelligence layer that grounds Microsoft 365 Copilot and your agents in real-time, shared context across your organization.”
So from a product/marketing perspective I guess it makes sense to “move” the MCP Servers from Agent 365 to Work IQ, as it positions Agent 365 as being all about agent governance, while Work IQ deals with the data.
The Work IQ MCP Servers
Since Ignite 2025 I have done a lot of demos and blog posts about the Agent 365 MCP servers (now called Work IQ MCP), for example:
Two blog posts describing how to use the MCP Servers from a custom agent - part 1 and part 2.
A post about how to use an (at that time) undocumented feature for creating custom MCP Servers in Agent 365.
A post about how to let an agent respond to Word comments and send emails using the Agent 365 notification functionality.
Lately, it seems that these MCP servers have gotten much easier to access and to use, something that I explored in a recent LinkedIn post where I tried out the servers from VS Code.
It has really started to felt like the tooling for agents in the Microsoft ecosystem is starting to come together now, and with the Work IQ MCP Servers we have pretty much everything we need to do work in Microsoft 365 work from an agent. Exciting times, for sure!
The Work IQ MCP Servers are still documented as part of the Agent 365 docs. At the time of writing, these are the available MCP Servers:
Work IQ Copilot
Work IQ User
Work IQ Mail
Work IQ Calendar
Work IQ Teams
Work IQ Word
Work IQ OneDrive
Work IQ SharePoint
Dataverse MCP Server
Microsoft MCP management MCP server
When it comes to data retrieval, the Work IQ Copilot MCP Server is the “swiss army knife” that allows for retrieval of pretty much all your M365 data. It has only one tool - copilot_chat - and the description is pretty telling:
Use this tool for any user request that might require finding, searching, discovering, or locating information contained within Microsoft 365 content—including documents, PDFs, spreadsheets, emails, sites, reports, or files—regardless of whether the question appears general or domain-specific.
If the user's request could plausibly be answered using organizational content, you must invoke this tool unless a workload-specific tool exists for that scenario. When no dedicated tool (mail, calendar, Teams, OneDrive, SharePoint, etc.) is available, this tool becomes the primary mechanism for retrieval.
If the request mentions a specific workload and its tool is unavailable, you might use this search tool as a fallback. If the search tool can't retrieve the information, clearly state that the information isn't accessible from the available tools instead of answering from general knowledge.
So this truly is (or should be) the “one MCP Server to rule them all”, at least when it comes to data retrieval. When it comes to updating data it is a different story, and that is what the rest of the MCP Servers are for. More on that later.
So much cool stuff from Redmond
Just the last couple of weeks so much cool stuff has come out from Microsoft, that it has honestly been hard to keep up. If you follow me on LinkedIn, you probably know that I have spent a lot of time the last six months exploring various specifications for agentic user interfaces, such as AG-UI, A2UI and MCP Apps. Lately, it has been really exciting to see these specs have finally made their way into the Microsoft ecosystem:
On 9th of March it was announced that MCP Apps and OpenAI Apps SDK would be available for Copilot declarative agents. I posted a video to LinkedIn where I ran Doom in a Copilot agent, by serving it as a OpenAI Apps SDK resource from an MCP Server.
Then it was announced that a custom Copilot agent could be used from a model-driven Power App, which I also tried out.
And if that was not enough, it was announced that a model-driven Power App could be exposed as an MCP Server that could be used from a declarative Copilot agent - and that also served some custom UIs! I created a demo of this also.
It seems that lately all this awesomeness has come to Copilot Declarative agents. And the single thing that enables all of the coolness is the ability to use MCP Servers from a declarative agent.
What is a declarative agent? Well, basically it is a no-code agent that can be put together declaratively (through lots of bundled files that describe the agent capabilities). A suggested way of doing this is to use the Microsoft 365 Agents Toolkit, a VS Code extension that makes it possible to create such agents in a simple way.
So, since it is possible to use MCP Servers from a declarative agent, then we must of course try to use the Work IQ MCP Servers from a declarative agent!
Using Work IQ MCP servers from a Microsoft 365 Copilot declarative agent
First of all, we need a way of finding out the metadata for the Work IQ MCP Servers, so we can add them to our declarative agent. Haven’t found this in the docs yet, but deeply hidden in this PR we can find a file that contains URLs to the various Work IQ MCP Servers. Example:
Replace <TENANT_ID> with your own tenant ID, and you have the MCP Server URL.
So, now that we have the MCP Server URLs, let’s try to add them to a declarative agent using the Microsoft 365 Agents Toolkit extension in VS Code. Install the extension, click the “M365” button and hit “Create a new agent/app”:
Then, select “Declarative agent” -> “Add an action” -> “Start with an MCP Server”, and then add the URL to the MCP Server. This scaffolds the declarative agent project, and adds your MCP Server to the mcp.json file:
Click “Start” to run the MCP Server. After authenticating, you can see that the MCP Server is connected and the tools (5 of them, in this case) are loaded:
Then, click “ATK: Fetch action from MCP” to add the MCP Server tools to the ai-plugin.json file. Select all tools that you want to add:
For auth, select “OAuth (with static registration)”:
You will see an error message saying Unable to find the authentication metadata in the MCP server, which you can disregard for now. The Work IQ MCP Servers unfortunately don’t publish authorization config information even though they SHOULD, so we will add this info manually later (for a previous rant about the Agent 365 MCP Server not being MCP spec compliant, see this post).
Now two things have happened:
ai-plugin.json has been updated with descriptions for all the tools that are exposed by the added MCP Server.
m365agents.yml has been updated with infra provisioning information.
Now it is time to add the missing authorization information to the m365agents.yml file. Add the following rows:
Make sure to replace the GUID:s with your Tenant ID!
Next, we need to setup the infra necessary to make it possible to do OAuth2 authentication with the MCP Servers. How to accomplish this for declarative agent MCP plugins is described here in the docs.
First, we need to add an App Registration to Entra ID. Create the app registration and:
Create a web redirect URL that points to: https://teams.microsoft.com/api/platform/v1.0/oAuthRedirect
Make a note of the app registration ID.
Create an app registration secret and make a note of it.
Then, add API permissions for the Work IQ MCP Servers that you intend to use in your declarative agent, and grant admin consent for these.:
Back in VS Code, click “Provision” in the “M365 Agents Toolkit” pane:
In the dialogs that are shown, enter:
The ID for the application registration that you created earlier.
The Client Secret that you created earlier.
The MCP Server scope (same as you added to the m365agents.yml file, for example https://agent365.svc.cloud.microsoft/agents/tenants/<YOUR TENANT ID>/servers/mcp_MeServer/.default)
Now M365 Agent Toolkit will create the infra for your agent, and when completed you can find the agent in the Teams Dev Portal: https://dev.teams.microsoft.com/. There, you can also see that OAuth client registrations have been created for all the MCP Servers that you added. This allows you to authenticate against the Work IQ MCP Servers when using the agent:
You can now try your agent by opening it up in the Teams Dev Portal, and clicking “Preview in Teams”:
You should now have a working declarative agent that uses the Work IQ MCP Servers!
In the video below I have wired up the agent with the mcp_MeServer, mcp_CalendarTools, mcp_MailTools and mcp_M365Copilot Work IQ MCP Servers.
This has been fun, declarative agents and Work IQ MCP Servers are pretty awesome. The Agent 365 Toolkit does a good job of provisioning the infrastructure for it all, which make things much simpler.
Thanks for reading, and until next time - happy hacking!
]]>Andreas AdnerDataverse MCP Server revisited, agent context reduction strategies and the future of BizApps2026-02-08T00:00:00+00:002026-02-08T00:00:00+00:00https://nullpointer.se/dataverse-mcp-server-revisited
It has been a while since I last tried the Dataverse MCP Server. Last summer, when it was in preview, I experimented with it extensively and posted my experiences to LinkedIn and to my blog:
In this LinkedIn post, I showed how the Dataverse MCP Server can be used from Claude Code, Claude Desktop and Gemini CLI.
In this fun experiment, I demonstrated how the Dataverse MCP Server can be used from anywhere - in this case from Excel, implemented as a VBA macro.
I also did a test of how well different LLMs used the Dataverse MCP Server, and blogged about it here. This was a looong time ago, and lots of stuff has happened since then:
The Dataverse MCP Server is now generally available.
Loads of new models have been released. Around New Year with the release of Opus 4.5, it felt like an inflection point was hit where models became so capable at coding that most developers, myself included, have largely transitioned from hand-coding to AI-assisted tools like Claude Code and OpenAI Codex.
It is becoming increasingly clear that we are rapidly moving towards a future where business applications will pretty much be headless APIs and that agentic applications with dynamically generated user interfaces will be the new BizApps. The writing was already on the wall last summer, when MSFT communicated that Power Platform would be API-first rather than UX-first, moving forward.
On that note, I spent a lot of time last autumn exploring the possibilities of agentic user interfaces and dynamically generated UIs. My experiments included dynamic report generation using MCP Resources and a couple of videos showing various dynamic agent-driven UIs. At that time, there wasn’t much available in terms of standardization and specifications for agentic UIs. Some attempts were made, like MCP-UI but it took a good couple of months until things started happening in this space. But then, it completely exploded and now we have an ever growing number of specs to choose from when designing our agentic UIs, like:
A2-UI - a protocol for declarative agent-driven interfaces from Google that was announced last year.
With all these new specifications, the protocol stack for agentic UIs is surely taking shape quickly. When I submitted my talk Creating rich agent user experiences using AG-UI: The Agent-User Interaction Protocol to the AgentCon Stockholm conference a while back, I thought it would be a really obscure topic. But it turned out to tie in pretty well with everything that has been happening with agentic user interfaces lately. AG-UI seems to be the “protocol glue” that ties all these new agent user interface specs to the agent orchestrator backends.
So where is all of this going? At this point in time, I think the AG-UI demos and the AG-UI MCP Apps demos are probably the best way to get a feel for where this tech is heading, and what we can expect from agentic user interfaces in the future. Also, check out my AG-UI demos from AgentCon:
So, while there is a veritable explosion happening in the agentic UI space, we are still waiting for these new standards to make it into the broader Microsoft stack. VS Code is, as always, an early adopter of everything new - they already shipped MCP Apps support back in January - but for those of us in the BizApps world, we are impatiently waiting for this tech to land in Copilot Studio, Microsoft Teams and the rest of the Power Platform. Good things come to those who wait! But I digress, we were talking about Dataverse MCP Server, right? Yes, we were - so let’s see what has happened with it since I last checked it out.
Dataverse MCP Server revisited
As I already mentioned, I spent a lot of time last year exploring the preview version of the Dataverse MCP Server. Now it is GA, so I thought I’d try it out again and see what has changed. Last year, I wanted to try out the locally running Dataverse MCP Server from an agent created in Microsoft Agent Framework, but that didn’t work because of a bug in the C# Model Content Protocol libraries. This bug is now fixed, so let’s try it!
But before we dive into the tech, let’s say some words about the licenses required to use the Dataverse MCP Server. The docs have the following to say:
Rather than trying to untangle what this means for makers building agentic applications on Dataverse, I’ll just point you to Jukka Niiranen’s blog post which covers it far more eloquently than I ever could.
So, let’s get started by following the instructions in the documentation for how to set up the Dataverse MCP Server to be used by non-Microsoft clients. Similar to the preview, this still involves creating a Dataverse connection in Power Automate, and using it when running the local STDIO Dataverse MCP Server. Unfortunately, the docs are somewhat confusing here:
The URL mentioned here differs slightly from the actual URL you see when you open up the Dataverse connection in Power Automate:
But if we inspect the mysterious URL found in the docs, and compare it to what we have in our address bar when opening up the connection in Power Automate, we can patch together something that works. In my case:
Using that connection string, we can make the Dataverse MCP Server work in Claude!
So what has changed? Well, not much. There are a couple of new tools for schema manipulation but apart from that, things are mostly the same. The big thing is probably the remote Dataverse MCP Server that can be used from Copilot Studio, but in this example I am using the good old STDIO Dataverse MCP Server (my prediction for 2026 is that STDIO support will be dropped from the MCP specification for security reasons, but we’ll have to see what happens…)
I assume that much has changed “under the hood”, but functionality-wise the MCP Server is basically the same - including the limitation of being able to return maximum 20 records per call to read_query.
When I participated in the private preview for the Dataverse MCP Server, one of my suggestions was to use MCP Resources to be able to return large result sets without weighing down the context, for example using the pattern described here in the Copilot Studio CAT team blog. Hopefully this will be implemented some day!
But let’s move on to using the Dataverse MCP Server from Microsoft Agent Framework!
The big shift to agentic user interfaces, and the need to manage agent context
Lately, things have started to shift quickly with regard to how we build business applications for our customers. The focus is no longer mainly on creating model-driven apps on top of Dataverse - instead, many customers want to build AI chat interfaces on top of their existing Dataverse/Dynamics 365 applications. And honestly, it is easy to see why. Even with something as basic as a text input box, a natural language interface has some pretty compelling advantages over a traditional BizApp UIs, especially when it comes to finding information:
Natural language search beats Advanced Find every day of the week - Instead of navigating to Advanced Find, picking entities, adding filter conditions, choosing operators and remembering exact field names, etc - you just ask “Show me all open opportunities over 500k that haven’t been updated in the last 30 days.” Done. The agent figures it out.
You don’t need to know the application - With a traditional model-driven app, there is a learning curve. Where is that view? Which tab has the field I need? How do I navigate to that related entity? With a chat interface, you just describe what you want in plain language and the agent handles the rest.
And this is with text input - which honestly is not exactly the optimal user experience. But imagine what will happen when voice input becomes the norm and you can just talk to your business applications. And when the dynamically generated agentic UIs that I discussed earlier start landing in the Microsoft stack - combining natural language interaction with rich user interfaces generated on the fly - that’s when things get really interesting. We are not that far away from this becoming reality, I think (hope).
So, a kind of project we have been doing quite a lot lately is chat agents that use tools to communicate with Dataverse, mainly for data retrieval purposes. Not much reasoning needed, and not much data manipulation going on. Such agents are characterized by:
No real need for reasoning models, speed is important - the agent needs to be snappy!
Tool calling is frequent and tool calling accuracy is super-important, this kind of agent lives and dies with its ability to call tools.
Loooooads of data being retrieved, which can lead to context rot and massive context usage and high costs, if not handled properly.
The last bullet here is really interesting and begs the question - how can we manage context for this kind of agent? Yes, let’s talk about chat history reducers - mechanisms for reducing the amount of context used by the agent, without sacrificing (too much) agent ability.
MessageCountingChatReducer - This is a reducer that at the end of each turn throws away all tool calls and their result, as well as truncating the message history if it exceeds a certain number of messages .
SummarizingChatReducer - This reducer uses an LLM to regularly summarize old messages into one message - and throw away the old messages.
Danish AI guru Rasmus Wulff Jensen has a great video about chat history reduction techniques in Microsoft Agent Framework, check it out!
The OOB reducers mentioned above are unfortunately not very suitable for our particular use case, for a couple of reasons:
Since tool calling is key to our use-case, throwing away all tool calls from the history like MessageCountingChatReducer does is not a good idea.
The SummarizingChatReducer - while usable for “normal” ChatGPT-style use-cases - doesn’t really bring any real value here. In the Question -> Tool Call -> Response loop, the LLM response is basically always a summary of the result of the tool call and are just a few tokens. LLM summarization doesn’t add anything.
So, let’s explore other options! But while we are at it, let’s also try out the reducers mentioned above so we can see how they behave in our scenario. I created a test harness for evaluating a number of context reducer techniques, that can be found here. In addition to MessageCountingChatReducer, it also evaluates a couple of new reducers:
DummyReducer - No reducer at all! Let’s see what happens if we let the context grow without control!
ToolPreservingChatReducer - Works like the MessageCountingChatReducer but keeps the tool calls in the context, until they are dropped.
Keeps the most recent messages (including tool calls!) without modification.
Older tool call results are condensed (verbose results being the the main culprit with regard to token consumption), while the arguments are kept so the LLM knows what requests is has made previously.
Certain tool calls are kept intact - specifically tool calls that retrieve data model metadata - so that the LLM doesn’t have to call these tools repeatedly.
All messages older than a certain cutoff are thrown away, including metadata tool calls.
In this example, I have set up a Dataverse environment that contains information about astronauts, rockets and space missions. The Dataverse MCP Server is used to retrieve data from Dataverse. We have a static set of questions that are asked in sequence:
“List all the astronauts in the system and their specialization!”
“What rockets are available?”
“Which astronaut is leading the most missions?”
“What is the specialization of Astrid Lindqvist?”
“Earlier you listed the astronauts. Can you recall who the first one was?”
“What was the specialization of Alan?”
Let’s run the tests and see how these different reducers behave!
DummyReducer
As mentioned above, this reducer doesn’t reduce at all but keeps the full context indefinitely. In the first turn we can see that the agent retrieves the metadata it needs, and since no reduction is ever done, the context just keeps growing as questions are asked.
── Turn 1 ──────────────────────────────────────────────────
Q: "List all the astronauts in the system and their specialization!"
[Tool Call] list_knowledge_sources()
[Tool Call] list_tables()
[Tool Call] read_query(querytext=SELECT TOP 20 contactid, fullname, jobtitle FROM contact ORDER BY fullname)
[Tool Call] describe_table(tablename=contact)
[Tool Call] read_query(querytext=SELECT TOP 50 fullname, contact_specialization FROM contact WHERE jobtitle = 'As...)
[Tool Call] read_query(querytext=SELECT TOP 20 fullname, contact_specialization FROM contact WHERE jobtitle = 'As...)
A: "Here are the astronauts (contacts) in the system and their specialization: | Astronaut | Specialization | |---|---| | Alan Shepard | Pilot | | Amara Okafor | Payload Specialist | | Astrid Lindqvist |..."
Tokens: Input: 47 065 | Output: 296
Cumulative: Input: 47 065 | Output: 296
Session messages: 14 | Sent to LLM: 13
────────────────────────────────────────────────────────────────
…
── Turn 6 ──────────────────────────────────────────────────
Q: "What was the specialization of Alan?"
A: "Alan Shepard’s specialization is **Pilot**."
Tokens: Input: 13 036 | Output: 12
Cumulative: Input: 160 054 | Output: 547
Session messages: 32 | Sent to LLM: 31
────────────────────────────────────────────────────────────────
========================== COMPARISON SUMMARY ==========================
Reducer | Total In | Total Out | Final Msgs | Last LLM
------------------------------------------------------------------------------------
DummyReducer | 160 054 | 547 | 32 | 31
=========================================================================
In total, 160054 input tokens are spent. The full transcript of the run can be found here.
MessageCountingReducer
This reducer throws away all tool calls and their results while keeping a fixed number of regular messages.
Since all tool calls are stripped from the context, the agent needs to retrieve the data model metadata over and over again, as can be seen here:
── Turn 1 ──────────────────────────────────────────────────
Q: "List all the astronauts in the system and their specialization!"
[Tool Call] list_knowledge_sources()
[Tool Call] list_tables()
[Tool Call] describe_table(tablename=contact)
[Tool Call] read_query(querytext=SELECT TOP 20 fullname, contact_specialization FROM contact WHERE contact_specia...)
A: "| Astronaut | Specialization | |---|---| | Alan Shepard | Pilot | | Amara Okafor | Payload Specialist | | Astrid Lindqvist | Commander | | Buzz Aldrin | Pilot | | Chris Hadfield | Mission Specialist |..."
Tokens: Input: 21 917 | Output: 223
Cumulative: Input: 21 917 | Output: 223
Session messages: 8 | Sent to LLM: 7
────────────────────────────────────────────────────────────────
── Turn 2 ──────────────────────────────────────────────────
Q: "What rockets are available?"
info: MyMessageCountingChatReducer[0]
Chat history reduced: 8 messages → 2 retained. Dropped 0 non-system messages exceeding limit of 5, dropped 6 function call/result messages.
[Tool Call] list_knowledge_sources()
[Tool Call] list_tables()
[Tool Call] describe_table(tablename=cr087_rocket)
[Tool Call] read_query(querytext=SELECT cr087_rocketid, cr087_rocketname, statecode, statuscode, createdon, modif...)
A: "The following rockets are available in the system (all currently **Active**): - Atlas - Delta - Falcon - Nova - Saturn - Soyuz"
Tokens: Input: 21 800 | Output: 137
Cumulative: Input: 43 717 | Output: 360
Session messages: 12 | Sent to LLM: 11
────────────────────────────────────────────────────────────────
We can also see that when the reducer reaches its limit of regular messages, and starts dropping these, it is (of course) not able to respond to questions relating to data retrieved earlier in the conversation:
── Turn 4 ──────────────────────────────────────────────────
Q: "What is the specialization of Astrid Lindqvist?"
info: MyMessageCountingChatReducer[0]
Chat history reduced: 14 messages → 5 retained. Dropped 1 non-system messages exceeding limit of 5, dropped 8 function call/result messages.
[Tool Call] list_knowledge_sources()
[Tool Call] list_tables()
[Tool Call] describe_table(tablename=contact)
[Tool Call] read_query(querytext=SELECT TOP 20 fullname, contact_specialization FROM contact WHERE fullname = 'As...)
A: "Astrid Lindqvist’s specialization is **Commander**."
Tokens: Input: 27 456 | Output: 98
Cumulative: Input: 99 382 | Output: 643
Session messages: 15 | Sent to LLM: 14
────────────────────────────────────────────────────────────────
── Turn 5 ──────────────────────────────────────────────────
Q: "Earlier you listed the astronauts. Can you recall who the first one was?"
info: MyMessageCountingChatReducer[0]
Chat history reduced: 15 messages → 5 retained. Dropped 2 non-system messages exceeding limit of 5, dropped 8 function call/result messages.
A: "I didn’t list any astronauts earlier in this chat—only rockets (Atlas, Delta, Falcon, Nova, Saturn, Soyuz) and then details about Astrid Lindqvist. If you mean the first rocket I listed, it was **Atl..."
Tokens: Input: 2 109 | Output: 55
Cumulative: Input: 101 491 | Output: 698
Session messages: 7 | Sent to LLM: 6
────────────────────────────────────────────────────────────────
========================== COMPARISON SUMMARY ==========================
Reducer | Total In | Total Out | Final Msgs | Last LLM
------------------------------------------------------------------------------------
MyMessageCountingChatReducer | 128 545 | 812 | 15 | 14
=========================================================================
In total, 128545 input tokens are spent, which is less than the DummyReducer but at the price of poor agent memory and worse answers. The full transcript of the run can be found here.
ToolPreservingChatReducer
The ToolPreservingChatReducer works like the MessageCountingReducer but keeps the tool calls in context. It also has a mechanism for making sure that tool call result messages are not being orphaned by the tool call message being dropped.
We can see that since the tool calls are kept in context, the agent doesn’t have to call metadata tools repeatedly:
── Turn 1 ──────────────────────────────────────────────────
Q: "List all the astronauts in the system and their specialization!"
[Tool Call] list_knowledge_sources()
[Tool Call] list_tables()
[Tool Call] describe_table(tablename=contact)
[Tool Call] read_query(querytext=SELECT fullname, contact_specialization FROM contact WHERE contact_specializatio...)
A: "| Astronaut | Specialization | |---|---| | Alan Shepard | Pilot | | Amara Okafor | Payload Specialist | | Astrid Lindqvist | Commander | | Buzz Aldrin | Pilot | | Chris Hadfield | Mission Specialist |..."
Tokens: Input: 21 931 | Output: 237
Cumulative: Input: 21 931 | Output: 237
Session messages: 8 | Sent to LLM: 7
────────────────────────────────────────────────────────────────
...
── Turn 3 ──────────────────────────────────────────────────
Q: "Which astronaut is leading the most missions?"
info: ToolPreservingChatReducer[0]
Chat history reduced: 14 messages → 11 retained (target: 10). Dropped 3 messages (cut at index 3).
warn: ToolPreservingChatReducer[0]
Dropped tool messages from context: 1 function call(s), 1 function result(s). Tool context has been lost for these interactions.
[Tool Call] read_query(querytext=SELECT TOP 1 fullname, contact_missions_completed FROM contact WHERE contact_mis...)
A: "Chris Hadfield is leading the most missions, with **3 missions completed**."
Tokens: Input: 20 363 | Output: 65
Cumulative: Input: 71 749 | Output: 389
Session messages: 15 | Sent to LLM: 14
────────────────────────────────────────────────────────────────
As soon as older regular messages are dropped, it suffers from the same issue as the MessageCountingReducer:
── Turn 5 ──────────────────────────────────────────────────
Q: "Earlier you listed the astronauts. Can you recall who the first one was?"
info: ToolPreservingChatReducer[0]
Chat history reduced: 18 messages → 11 retained (target: 10). Dropped 7 messages (cut at index 7).
warn: ToolPreservingChatReducer[0]
Dropped tool messages from context: 2 function call(s), 2 function result(s). Tool context has been lost for these interactions.
A: "I can’t reliably recall that from our earlier messages alone. If you tell me which list you mean (e.g., “all astronauts ordered by name” or “top missions”), or if you want, I can re-run the query to ..."
Tokens: Input: 6 484 | Output: 59
Cumulative: Input: 98 922 | Output: 553
Session messages: 13 | Sent to LLM: 12
────────────────────────────────────────────────────────────────
...
========================== COMPARISON SUMMARY ==========================
Reducer | Total In | Total Out | Final Msgs | Last LLM
------------------------------------------------------------------------------------
ToolPreservingChatReducer | 111 812 | 600 | 14 | 13
=========================================================================
In total, 111812 input tokens are spent, which is less than the MessageCountingReducer, while the accuracy is the same. The transcript can be found here.
ContextAwareChatReducer
This reducer keeps recent tool calls intact, while condensing the results of older tool calls. It also keeps data model metadata tool calls completely intact.
Here we can see the reducer in action, preserving the metadata tool calls (list_tables and describe_table) while condensing the other tool calls:
── Turn 3 ──────────────────────────────────────────────────
Q: "Which astronaut is leading the most missions?"
info: ContentAwareChatReducer[0]
Phase 2: 14 messages split into 9 historical + 5 recent. Condensing historical data tool results.
info: ContentAwareChatReducer[0]
Condensed tool result: list_knowledge_sources (call_Ij9XqcyqCpOv6poFTpgCFJvh) → {"@odata.context":"https://orga7f9a5a6.crm4.dynamics.com/api/data/v9.1.0/$metadata#expando","value":[]}
info: ContentAwareChatReducer[0]
Preserved tool result: list_tables (call_ddNb1LRFDNMGHuYoXYvIEeK6)
info: ContentAwareChatReducer[0]
Preserved tool result: describe_table (call_yjomSmfZxqLumvg2wCc6cr1V)
info: ContentAwareChatReducer[0]
Condensed tool result: read_query (call_CLGs3ncXnWifJgWnl2c0FCRi) → {"@odata.context":"https:// [truncated]
info: ContentAwareChatReducer[0]
Phase 3: 14 messages within maxMessages (20), no trimming needed.
info: ContentAwareChatReducer[0]
Reduction complete: 14 → 14 messages.
[Tool Call] read_query(querytext=SELECT TOP 1 fullname, contact_missions_completed
FROM contact
WHERE contact_mis...)
A: "**Chris Hadfield** is leading the most missions, with **3 missions completed**."
Tokens: Input: 19 514 | Output: 70
Cumulative: Input: 70 966 | Output: 385
Session messages: 18 | Sent to LLM: 17
────────────────────────────────────────────────────────────────
...
========================== COMPARISON SUMMARY ==========================
Reducer | Total In | Total Out | Final Msgs | Last LLM
------------------------------------------------------------------------------------
ContentAwareChatReducer | 119 321 | 509 | 25 | 24
=========================================================================
For this particular use-case, this reducer works really well, for a couple of reasons:
It doesn’t clog down the context with tool call results, except for the most recent tool call(s). Data retrieved from Dataverse can be huge, so getting rid of this data as soon as it is irrelevant is extremely important.
A good understanding of the data model is super-important, and the metadata retrieval tool calls are they key to this understanding. That’s why the reducerar keeps these intact in the context for a prolonged amount of time, until they are finally disregarded when they reach “old age”.
In total, 119321 input tokens are spent, which is slightly worse than the ToolPreservingChatReducer for this very limited scenario. But as the number of requests rise, and if the amount of data retrieved by the tools is huge then the ContextAwareChatReducer will vastly outperform the other reducers. The transcript can be found here.
Summary
Context management is one of those things that every consumer LLM product already handles for you. ChatGPT, Claude, Gemini - they all silently summarize and compress your conversation history as it grows, and for general-purpose chat this works great. But when you’re building agents that act as natural language interfaces on top of business data - where the conversation is dominated by tool calls returning large chunks of structured data - you can’t just rely on generic summarization. The shape of these conversations is fundamentally different from a typical chat: it’s a tight loop of questions, tool calls and data, where what matters is not the prose but the results and the metadata that enables future tool calls.
For this kind of agent, you need to take control of context management yourself. The out-of-the-box reducers in Microsoft.Extensions.AI are a good starting point, but as the tests above show, a context reduction strategy that understands the semantics of your particular conversation pattern - what to keep, what to condense, and what to drop - will give you better accuracy at lower cost as conversations grow. I hope you find this deep dive into context reducers useful!
In my last blog post I explained in detail how to use the Agent 365 CLI to set up the infrastructure necessary to deploy a custom agent to Agent 365. So if you are just starting out, that post is a great way to get the prerequisites in place to be able to start developing your agent.
In this blog post I discuss how to build the actual agent, using the Agent 365 SDK, with specific focus on how to use the notification functionality in the SDK.
Our goal is to create an agent that can respond to messages from Teams and other channels, reply to comments in Word documents and respond to emails. Let’s get started!
The SDK libraries
There are quite a few SDK packages available for Agent 365. The ones of special interest for us today are:
Microsoft.Agents.A365.Notifications - a package that “provides notification services for agents, including sending and managing messages and alerts”. This package makes it possible for our agent to respond to e.g. comments in Word documents, and reply to emails.
Microsoft.Agents.A365.Tooling - a package that “provides tools for agent development, debugging, and management”. This package gives us the ability to use the first-party Agent 365 MCP Servers.
There are lots of other libraries available that handle observability and telemetry, but these were omitted from this demo for the sake of simplicity.
Bootstrapping the agent
As I mentioned in my last blog post, devtunnels is a useful tool. The post describes the setup needed to utilize devtunnels to debug your agent locally, so check it out if you haven’t done so already.
The code for the agent can be found in this repo, let’s go through it to understand how it works.
The agent is basically a .NET web app that (locally) listens to port 3978 and that accepts requests to the /api/messages endpoint. This is the endpoint that the Bot Messaging service that is deployed to the cloud routes requests to, as mentioned in my last blog post.
// Map the /api/messages endpoint to the AgentApplicationapp.MapPost("/api/messages",async(HttpRequestrequest,HttpResponseresponse,IAgentHttpAdapteradapter,IAgentagent,CancellationTokencancellationToken)=>{awaitadapter.ProcessAsync(request,response,agent,cancellationToken);});...app.MapGet("/",()=>"Agent Framework Notification Agent");app.UseDeveloperExceptionPage();app.MapControllers().AllowAnonymous();app.Urls.Add($"http://localhost:3978");
The agent is added to the pipeline:
builder.AddAgent<MyAgent>();
We inject the services we need to use the A365 Tooling Servers:
This allows the agent to load the MCP Servers that are defined in ToolingManifest.json. For our agent, these are:
mcp_MailTools that allows the agent to send and reply to emails.
mcp_WordServer that lets the agent reply to comments in Word documents, among other things.
In MyAgent.cs we wire up the three activity handlers that our agent needs:
publicMyAgent(AgentApplicationOptionsoptions,IChatClientchatClient,IConfigurationconfiguration,IMcpToolRegistrationServicetoolService,IHttpClientFactoryhttpClientFactory,ILogger<MyAgent>logger):base(options){_chatClient=chatClient;_configuration=configuration;_logger=logger;_toolService=toolService;_httpClientFactory=httpClientFactory;// Handle A365 Notification Messages. this.OnAgenticWordNotification(HandleWordCommentNotificationAsync,autoSignInHandlers:new[]{AgenticIdAuthHandler});this.OnAgenticEmailNotification(HandleEmailNotificationAsync,autoSignInHandlers:new[]{AgenticIdAuthHandler});// Handles all messages, regardless of channel - needs to be the last route in order not to hijack A365 notification handlers.this.OnActivity(ActivityTypes.Message,OnMessageAsync,autoSignInHandlers:new[]{AgenticIdAuthHandler});}
The order of the handlers is important - the notification handlers need to come before the general OnMessageAsync handler, so that this generic one doesn’t swallow the notification messages.
The notification handlers
OnAgenticWordNotification is called when the agent is @-tagged in a Word comment:
privateasyncTaskHandleWordCommentNotificationAsync(ITurnContextturnContext,ITurnStateturnState,AgentNotificationActivityactivity,CancellationTokencancellationToken){varcomment=activity.WpxCommentNotification;varattachments=turnContext.Activity.Attachments;varcontentUrl=attachments[0].ContentUrl;...varuserText=turnContext.Activity.Text?.Trim()??string.Empty;var_agent=awaitGetClientAgent(turnContext,turnState,_toolService,AgenticIdAuthHandler);...varresponse=await_agent.RunAsync($"""
YourtaskistorespondtoacommentinaWordfile.First,getthefullcontentoftheWordfiletounderstandthecontextandfindoutwhatthecommentisreferringto.UsethetoolWordGetDocumentContentforthispurpose.TheURLtothedocumentis{contentUrl}.Thenfindthetextthatthecommentwithid{comment.CommentId}isreferringtoandrespondwithananswer.""");
_logger?.LogInformation("Agent response: {Response}",response.ToString());//Note that we don't respond at the end of this method - we instead let the Word MCP Server handle the reply to the comment.}
Unfortunately the WpxCommentNotification doesn’t include all the information about the document that is needed by the WordReplyToComment tool in the mcp_WordServer. To solve this, we instruct the agent to first call the WordGetDocumentContent to retrieve this required info. This tool call also returns the full document, which enables the agent to pinpoint the exact text was highlighted in the Word comment and get the full context (at the expense of lots of tokens, of course…).
The agent then uses the WordReplyToComment MCP tool to reply to the comment, like so:
We can check the logs to understand the agent’s reasoning, as it replies to the comment:
Agent response: I’ve reviewed the full document and located the comment with ID 469179BD, which refers to the statement claiming that the Commodore 64 had built-in Ethernet networking hardware.
I’ve replied directly to that comment explaining that this is incorrect: the Commodore 64 did not include built-in Ethernet. Any networking was done via external peripherals such as modems (e.g., over RS‑232) or much later third-party network adapters. I also noted that the text should be corrected to remove the Ethernet claim.
Moving on to the HandleEmailNotificationAsync handler:
privateasyncTaskHandleEmailNotificationAsync(ITurnContextturnContext,ITurnStateturnState,AgentNotificationActivityactivity,CancellationTokencancellationToken){varemail=activity.EmailNotification;...varuserText=turnContext.Activity.Text?.Trim()??string.Empty;var_agent=awaitGetClientAgent(turnContext,turnState,_toolService,AgenticIdAuthHandler,"You are a helpful assistant.");...varresponse=await_agent.RunAsync($"""
Youhavereceivedamailandyourtaskistoreplytoit.PleaserespondtothemailusingtheReplyToMessageAsynctoolusingHTMLformattedcontent.TheIDoftheemailis{email.Id}.Thisisthecontentofthemailyoureceived:{userText}""");
_logger?.LogInformation("Agent response: {Response}",response.ToString());}
Here we simply instruct the agent to reply to the email message it has received by invoking the ReplyToMessageAsync tool in the mcp_MailTools MCP Server.
The last handler, OnMessageAsync, is for responding to messages from all other channels, for example Teams.
protectedasyncTaskOnMessageAsync(ITurnContextturnContext,ITurnStateturnState,CancellationTokencancellationToken){varuserText=turnContext.Activity.Text?.Trim()??string.Empty;var_agent=awaitGetClientAgent(turnContext,turnState,_toolService,AgenticIdAuthHandler);// Read or Create the conversation thread for this conversation.AgentThread?thread=GetConversationThread(_agent,turnState);varresponse=await_agent!.RunAsync(userText,thread,cancellationToken:cancellationToken);awaitturnContext.SendActivityAsync(response.ToString());turnState.Conversation.SetValue("conversation.threadInfo",ProtocolJsonSerializer.ToJson(thread.Serialize()));}
The handler also (de)serializes the conversation thread state, so that it can remember previous messages and keep the whole conversation “in memory”. And of course, it can use all the MCP Servers that are registered. In this example, it uses the mcp_MailTools MCP Server to send an email:
That’s pretty much all there is to it…
All the code can be found in this repo, and here is a short video of the agent replying to a Word comment:
Thanks to all of you that have been following my blog during 2025, it has been fun exploring MCP, agents, LLMs and now lately Agent 365. looking forward to more fun stuff in 2026! Until then, happy new year and happy hacking!
]]>Andreas AdnerExploring the Agent 365 CLI2025-12-26T00:00:00+00:002025-12-26T00:00:00+00:00https://nullpointer.se/exploring-agent-365-cli
Ever since Agent 365 was announced at this year’s Microsoft Ignite, I have wanted to explore this exciting technology and the possibilities it creates. Since the Model Context Protocol is a topic that is dear to my heart, I got especially interested in the Agent 365 MCP Servers, and the way they make it possible for an agent to interact with the various Microsoft productivity applications, such as Word and Teams, in different ways. Lately, I have explored this particular topic in depth in a number of videos and blog posts:
In the blog post Creating dynamic MCP Servers using Agent 365 I checked out the possibilities of dynamically creating custom MCP Servers in Agent 365, servers that can use the many out-of-the-box operations provided by Dataverse and the Graph API. I also demonstrated how to use this dynamically created MCP Server in a Copilot Studio agent.
However, the MCP servers are just one piece of the Agent 365 puzzle. Another game-changer in Agent 365 is the ability to onboard agentic users in your tenant - agents that can act on your behalf, or autonomously, in a governed and secure way.
During the last year I have written quite a bit about the need for governance when building an AI agent infrastructure, and Agent 365 is the technology in the Microsoft stack that enables this. Exciting times!
The ability to onboard agentic users and govern them in the Microsoft 365 Admin Center.
Agents that use the Agent 365 MCP Servers to interact with productivity applications, such as Teams and Word.
So, I have spent the last couple of weeks trying this out, resulting in a LinkedIn-post that shows a video of an A365-agent running in Teams that uses a few of the A365 MCP servers. Kudos to Tahir Sousa and team for helping me sort it all out!
In this blog post my goal is to explain in detail
how this was done, so you can try it out for yourself - as well as learn a thing or two about the technology that powers Agent 365.
Heads up: Agent 365 is evolving fast. Treat this blog post as a snapshot - check the official A365 docs for current info, and expect any issues that I mention here to be resolved by the time you read this.
More SDKs than you can shake a stick at
As we start exploring Agent 365, there are a number of SDKs that we should be aware of:
The Microsoft Agent 365 SDK is the new SDK that adds the cool capabilities that Robert and James demonstrated in their Ignite session, for example:
Notifications - An agent can be notified when e.g. a mail is sent to the agent, or when a comment is requested in a Word document.
Observability - tracing, caching and monitoring of agents - stuff that I haven’t tried out yet but hope to be able to soon.
Tooling - Libraries for using the A365 tooling servers from your agent.
The Microsoft 365 Agents SDK - This is the foundational SDK that the A365 SDK is built on top of, and that allows for creating agents that can be deployed to a myriad of channels. In the blog post The Teams AI Library, M365 Agents SDK & Toolkit and how to run Doom in Teams that I wrote back in October, I took a look at this SDK and the associated tooling, with specific focus on deploying chatbots to the Teams channel.
As I noted in my previous blog post, the M365 Agents SDK “comes with a steep learning curve and involves considerable ‘black box infra voodoo’”. When working with A365, that feeling is still there - though it’s somewhat less pronounced… More on that below.
Also part of A365 are a couple more interesting GitHub repos:
Microsoft Agent 365 DevTools CLI - This is the CLI that we will use to provision the infrastructure needed for our agent and to package and deploy it. This is similar to the Microsoft 365 Agents Toolkit in M365 Agents SDK - which also can be used for provisioning and deployment, but this time things are done a bit differently. The docs for the CLI can be found here.
Agent365-Samples is a repo with “starter kits” for building an agent in different languages, and agent orchestrator frameworks.
Step 0 - Setting things up locally
So where to start? The amount of SDKs, GitHub repos and resources available for A365 can be a bit overwhelming at first. So, let’s start by trying to get an agent up and running locally.
The way to test agents locally in M365 Agents SDK was to use Agents Playground and in A365 Agent SDK this is still the recommended approach. I have tried this, and it works but it is currently pretty cumbersome, because of this:
So, rather than doing that I thought I would try out debugging the agent locally using the good old devtunnel approach that I have used in days past, when tinkering with the M365 Agents SDK and Toolkit. Devtunnels makes it possible to deploy the agent to the cloud, while at the same time pointing the agent Messaging Endpoint to my local machine - pretty powerful (if it works)! More on that below…
First, let’s install the Agent 365 CLI which is a tool that simplifies setting up the infrastructure necessary for our agent:
I’m a C# guy, so the sample I am interested in is the C# Microsoft Agent Framework one. This sample project contains a simple agent that uses Microsoft Agent Framework and that utilizes some of the A365 MCP Servers.
If we open up the sample project, we can see that:
appsettings.json contains a lot of placeholders. These placeholders will be automagically populated when we run the A365 CLI to create the infrastructure for our agent. This is also described here in the docs, but is in my opinion pretty confusing…
ToolingManifest.json lists all the A365 MCP Servers that the agent uses. This file is used both by the CLI to create the correct permissions for the agent blueprint in your tenant, and also to keep the agent itself informed about which tools it has access to.
Also, let’s install devtunnels - the nifty technology that allows us to route requests from a bot running in the cloud to our local machine:
winget install Microsoft.devtunnel
We then create a devtunnel that listens on port 3978. NOTE: Don’t create anonymous devtunnels - security is important!
Make note of the public devtunnel URL, we will use this as the bot messaging endpoint when we provision the infrastructure in the next step.
Now we have what we need locally to start creating our agent, so let’s move on to infrastructure provisioning using the A365 CLI.
Step 1 - Creating the infrastructure
This is where the magic happens. We want to use the Agent 365 CLI to create the infrastructure necessary to use our agent - locally at first, and then deployed to our tenant.
The first thing we need to do is to create a new App Registration in Entra ID for the A365 CLI, as is described here. This is required to give the CLI the correct permissions to work with agent blueprints, etc. Make note of the application id of the newly created app registration, this is used in the next steps.
Then, navigate to our sample agent, and run the a365 config init command. This collects some information and creates the a365.config.json file, that will be used for infra provisioning.
Note that:
We enter the application id of the Agent 365 CLI App Registration that we created earlier.
It doesn’t matter which resource group we select, since we have no intention to deploy anything to Azure, we only want to run the agent locally.
We don’t want to create a Web App, for the same reason.
The Messaging endpoint URL is set to the URL of the devtunnel we created earlier. Note that it is not possible to change this URL later (in any simple way), but this is a requested feature.
Now we can proceed with setting up all the required infrastructure by running the a365 setup command:
First, we can run the a365 setup requirements command, to check if we are good to go:
Great, let’s proceed! We don’t have to run a365 setup infrastructure since we - as we noted above - only intend to run the agent locally in this demo. So, we continue by creating the Agent Identity Blueprint.
“All agent identities in a Microsoft Entra ID tenant are created from an agent identity blueprint. The agent identity blueprint is a key component of the Microsoft agent identity platform that enables secure development and administration of AI agents at scale. An agent identity blueprint serves four purposes… Organizations can deploy many instances of an AI agent. Each instance pursues a different goal and requires a different level of access. Each instance uses a distinct agent identity for authentication and access. However, the many agent identities used share certain characteristics. The agent identity blueprint records these common characteristics, so that all agent identities created using the blueprint have a consistent configuration.”
So let’s create the agent identity blueprint by running the command a365 setup blueprint. This command does LOADS of stuff, for example:
Creates the agentic identity blueprint, sets permissions and applies admin consent to these. Once created, the blueprint can be found as an Enterprise Application (i.e., service principal) in Entra ID, with the following inheritable permissions:
Creates a secret on the App Registration:
Updates appsettings.json of our agent and populates the placeholders.
Creates a file called a365.generated.config.json with information about everything that has been created.
Registers the messaging endpoint that points to our local devtunnel in this case.
So, we now have an agent identity blueprint that can be used to create agent instances! It has a couple of inheritable permissions, but we need to add a few more by running these commands:
a365 setup permissions mcp - To configure the permissions for the A365 MCP Servers.
a365 setup permissions bot - To configure Bot API permissions.
After running these commands, a number of new permissions are added to the service principal:
So far so good, the infrastructure is (almost) in place. Let’s continue!
Step 2 - Publishing the agent
Now we almost have everything we need to be able to create agentic identities in our tenant. We still need to:
Publish the agent to the M365 Admin Center, as is described here. We do this by running the a365 publish command. This creates a zip-file containing the agent manifest, and uploads it to Microsoft 365.
Then, we must follow the instructions here to configure our agent identity blueprint to point to the Bot that was provisioned (and that is completely managed by Microsoft, and which we have no access to unfortunately…):
Pro tip: The bot ID is the same ID as the ID of the agent identity blueprint.
Step 3 - Creating the agent identity and agent user
Now that the agent (manifest) is published to our tenant, we can go to Microsoft Teams and create an instance of the agent:
Click “Request instance”:
Now back to M365 Admin Center, where you can approve the request:
Back to Teams, where it is now possible to create an instance of the agent:
When this is completed, two things are created:
An agent identity, which is a “special service principal in Microsoft Entra ID. It represents an identity that the agent identity blueprint created and is authorized to impersonate”:
An agent user, which is a “specialized identity type designed to bridge the gap between agents and human user capabilities”:
Now when everything is created in the cloud, let’s move on to trying to test our agent locally.
Step 4 - Testing the agent locally
First, make sure that your devtunnel is running by executing the command devtunnel host new-year-tunnel (change to the ID of the tunnel you created).
Make sure to update appsettings.json so that it points to an LLM deployment in Microsoft Foundry:
Some additional tweaks need to be made to the appsettings.json:
The AuthType of the Service Connection needs to be changed to ClientSecret, instead of UserManagedIdentity - since we are running locally and don’t have a Managed Identity set up for our agent web application.
Remove all authorization handlers except the AgenticUserAuthorization handler (don’t ask me why, it just doesn’t work otherwise…):
Now let’s debug our agent! As can be seen, the agent web app responds at port 3978, which is the same port as our devtunnel points to:
The moment of truth! Let’s ask the agent a question in Teams:
Great success, we have successfully provisioned an agent in Agent 365, published it to Teams and are now able to debug it locally using devtunnels!
But what about MCP Servers? If we review the ToolingManifest.json file, we can see that the agent currently has access to two A365 MCP Servers:
Looking at the agent blueprint, we can see that the blueprint has the required permissions for these MCP Servers (which are inherited by the agent identity):
But how do we add more MCP Servers? In the documentation we see that there is an a365 develop list-available command, that can be used to list all the MCP Servers that are available in the catalog:
And we can add for example the Word MCP Server by running the a365 develop add-mcp-servers mcp_WordServer command. This updates ToolingManifest.json to include the Word MCP Server:
But we are not done yet, we also need to run the a365 setup permissions mcp command again to update the blueprint with the new permissions that are required by this MCP Server. This command parses ToolingManifest.json and updates the blueprint with any missing permissions needed to invoke the MCP Servers. We can now see that the blueprint permissions have been updated:
So let’s try the MCP Servers by asking the agent to send us a mail, by utilizing the mcp_MailTools MCP Server:
We can also ask the agent to book a meeting, which uses the mcp_CalendarTools MCP Server:
Pretty cool… But what if we want to use other MCP Servers? In a previous blog post I showed how to dynamically create MCP Servers using the Agent 365 MCP Management MCP Server. In the demo I created an MCP Server that could be used to retrieve data from Dataverse:
The question is, can this custom MCP Server be used from our agent? We can use the A365 Management MCP Server to get the URL and required scopes of the custom MCP server (see my previous blog post):
So let’s try updating ToolingManifest.json with this information:
Once again, let’s run a365 setup permissions mcp to update the blueprint with the new permission - McpServers.DataverseCustom.All - that is required by the custom MCP server.
Next, we need to add the agentic user as a user in Dataverse. Yes, amazing isn’t it? This is the power of the agentic user - that it can be added to existing applications like Dynamics 365 as a licensed user, with security roles and all. What a time to be alive!
So, let’s try and run the agent and load my custom MCP Server! Hmm… It doesn’t seem to work. After some debugging I realized there was an issue in the way that the Agent 365 SDK parses ToolingManifest.json when running locally, the method ParseServerConfigFromManifest doesn’t read the url parameter from the file, instead it defaults to a URL that works for other A365 MCP Servers, but not for our custom one.
Let’s fix this!
I forked the Agent 365 SDK repo and created this PR which updates ParseServerConfigFromManifest to also read the url parameter from ToolingManifest.json. I then rebuilt the agent using my fork. With the fix in place the agent also loads my custom MCP Server, and it can be used side-by-side with the OOB A365 MCP Servers:
So, there we have it - a custom agent using the Microsoft Agent Framework that is deployed to the Agent 365 infrastructure, Agent 365 MCP Servers working in tandem with dynamically created MCP Servers, data retrieved from Dataverse, agentic users in Teams and local debugging - feels like a Christmas miracle! ☃️🎅
It has been a real treat to explore Agent 365, and I am really looking forward to all the new cool features that will come 2026 as the platform evolves. Until then, happy new year and happy hacking!
]]>Andreas AdnerCreating dynamic MCP Servers using Agent 3652025-12-16T00:00:00+00:002025-12-16T00:00:00+00:00https://nullpointer.se/dynamic-mcp-servers
A while back I posted a video to LinkedIn that showed how to use the Microsoft 365 MCP Management MCP Server (yes, that is the name of the server) that is part of Agent 365 to dynamically create MCP Servers. In this blog post my intention is to show how this was accomplished.
My interest in this topic started when I read through the Agent 365 documentation, and found a section that described the tooling servers that is part of Agent 365. These servers are described as “…enterprise-grade Model Context Protocol (MCP) servers that give agents safe, governed access to business systems such as Microsoft Outlook, Microsoft Teams, Microsoft SharePoint and OneDrive, Microsoft Dataverse, and more through the tooling gateway”.
These are the same MCP Servers that you can use from Copilot Studio, which I tried out after it was announced at Microsoft Ignite this year. In a post on LinkedIn and in a couple of blog posts (part 1 and part 2) I explored how these MCP Servers could be used from a custom agent, using the Microsoft Agent Framework as orchestrator.
These experiments involved using the Agent 365 MCP Management MCP Server to programmatically retrieve information about these first-party MCP Servers, so I could connect to them using the MCP plumbing in Agent Framework.
While exploring the (pretty sparse, to be honest) documentation on the A365 MCP Management MCP Server, it is clear that this server has quite a lot of interesting tools, for example:
CreateMcpServer - “Creates a new MCP server instance in the current environment”.
These tools sure sound interesting, but there isn’t any real information on how to use them in the documentation, as far as I can see. The section“Build scenario-focused custom MCP servers with the Microsoft MCP Management Server” contains a high-level overview of the capabilities for creating custom MCP Servers, including the ability to create MCP Servers based on:
Existing connectors
Dataverse custom APIs
Microsoft Graph APIs
There is excellent documentation available on how to hook up the Management MCP Server from VS Code, so let’s try that and explore some of the available tools in the MCP Server.
The documentation is missing one detail - how to enable it so that the GitHub Copilot MCP Client is allowed to communicate with Dataverse. Luckily, this instruction can be found here in the Dataverse MCP Server docs.
Creating the custom MCP Server
In VS Code, we connect to the Management MCP server for one of our Dataverse environments, and ask it to provide detailed information about the CreateMcpServer tool:
So, let’s try to use this tool to create a new MCP Server with the name “AddesCoolMcpServer”.
When doing so, we get a somewhat cryptic error message - Export key attribute name for component MCPServer must start with a valid customization prefix..
Interesting… Could it be that the prefix of the logical name of the MCP Server must be associated with an existing Publisher? Let’s try to use the prefix of an existing publisher in this particular Dataverse environment - adde_. Excellent, this worked:
Looking in Dataverse, we can see that a new record has been created in the MCPServer table:
So far, so good. So, how can we add tools to this MCP Server? There was a tool in the Management MCP Server called CreateToolWithCustomAPI which we can probably use to add some Custom APIs as tools to the server. But which Custom APIs are available? We can call the GetCustomAPIs tool to retrieve the list of Custom APIs that are available in the Dataverse environment:
Quite a lot of tools - 330 to be exact! Let’s try to add the FetchXmlToSql tool to the MCP Server we just created:
We can see in Dataverse that the tool has been added to the MCPTool table:
Great, now we have a custom MCP Server with a tool! Let’s get some info about this MCP Server:
Now that we know the URL of the newly created MCP Server we can easily add it to VS Code:
Now let’s try to convert a FetchXml query to SQL using our server:
Works perfectly! Let’s also add the McpExecuteSqlQuery Custom API as a tool to our server, similar to above:
We now have two tools, let’s try them together:
That worked perfectly! But how do we call our custom MCP Server from Copilot Studio? Let’s start by configuring an App Registration in Entra ID:
Create an App Registration and make note of the Application ID. Note - make sure that the Application Registration is Multitenant.
Create a secret and make note of it.
Add the McpServers.DataverseCustom.All scope (since it is required by the tools, see the screenshot above) and consent to it. This scope can be found by adding an API Permission, clicking “APIs that my organization uses” and then search for “Agent 365”:
Using the MCP Server in Copilot Studio
Now we can create a new agent in Copilot Studio and add our MCP server as a tool. Add a new tool of type “Model Context Protocol”, enter the HTTP streaming endpoint (as can be seen from the screenshot with the tool info above) and configure it to use manual OAuth2:
Enter the authorization URL and the token URL (if you want to know how to get these URLs using MCP Inspector, check out this blog post).
The Refresh URL can be set to the same URL as the Token URL Template.
The ea9ffc3e-8a23-4a7d-836d-234d7c7565c1/.default scope is a blanket request to get all scopes that we previously defined for our App Registration (we only added one - the McpServers.DataverseCustom.All scope, which is the one that is needed here, but .default is a shorthand for getting all of them).
The GUID ea9ffc3e-8a23-4a7d-836d-234d7c7565c1 is simply the ID of the Agent 365 Tools application, which we added as an API permission to our app registration earlier.
Hit Create and a redirect URL is generated for you:
Go back to your App Registration and create a Web Redirect URL that points to this URL:
If everything worked out well, the MCP Server is now added to Copilot Studio:
Let’s try it by asking the agent to convert a FetchXML query to SQL:
…and run the resulting SQL query against Dataverse:
Great success! We now have a Copilot Studio agent that uses the MCP Server that we created dynamically. Here is a video of it in action:
It was fun tinkering around with this and the possibility to create dynamic MCP Servers is really powerful. The documentation is still catching up with all the capabilities, but that’s to be expected for such new technology. I’m excited to see how this evolves as Agent 365 matures.
Until next time, happy hacking!
]]>Andreas AdnerPart 2 - Building the agent2025-12-05T00:00:00+00:002025-12-05T00:00:00+00:00https://nullpointer.se/agent-365-mcp-servers
We start by creating a web app that exposes an AG-UI endpoint, and that implements an agent using Microsoft Agent Framework. The code for the backend can be found in this repo. To wire up the AG-UI middleware, we follow the instructions here in the docs. There is also some sample code in the Microsoft Agent Framework repo.
To implement the authorization flow with the MCP Servers, I took inspiration from the Protected MCP Client sample code in the C# MCP SDK repo.
usingModelContextProtocol.Client;usingOpenAI;usingMicrosoft.Agents.AI;...usingMicrosoft.Agents.AI.Hosting.AGUI.AspNetCore;// Two HttpClient configurations are needed because different MCP servers have different requirements:// - Most MCP servers (Agent365) work fine with standard HTTP chunked transfer encoding// - Some servers do NOT support chunked encoding and require Content-Length headerusingvarhttpClient=newHttpClient();usingvarhttpClientWithContentLength=newHttpClient(newContentLengthEnforcingHandler());
We then add the plumbing for handling the OAuth2 flow. We implement a special authentication handler - OAuthAuthorizationHandler - for this purpose, that among other things opens up a browser so that the user can authenticate and consent to the scopes that are required to access the servers.
In this particular example, we set up the authorization logic to be able to access the Agent 365 MCP Management MCP Server. See the last blog post for details on how to set up the prerequisites (App Registration, API permissions, etc) in Entra ID. In the last blog post we used Authorization Code Flow with PKCE, this time we use Authorization Code Flow - so a Client Secret is also required here. In the repo there are also examples on how to connect to the Word, Teams and Dataverse MCP Servers.
// Create OAuth handler with semaphore to serialize auth flows (they share the same redirect port)varoauthHandler=newOAuthAuthorizationHandler();// Create SSE client transport for the MCP servervarmanagementMcpServerUrl=$"https://agent365.svc.cloud.microsoft/mcp/environments/{dataverseEnvironmentId}/servers/MCPManagement";varmanagementMcpTransport=newHttpClientTransport(new(){Endpoint=newUri(managementMcpServerUrl),Name="Agent365 Management Client",OAuth=new(){ClientId=clientId,ClientSecret=clientSecret,Scopes=["ea9ffc3e-8a23-4a7d-836d-234d7c7565c1/McpServers.Management.All","offline_access","openid","profile"],RedirectUri=newUri("http://localhost:1179/callback"),AuthorizationRedirectDelegate=oauthHandler.HandleAuthorizationUrlAsync,}},httpClientWithContentLength,consoleLoggerFactory);
We connect to the MCP Server and enumerate the available tools, so we can add them to the agent that we create in the next step.
Then, we create the agent and supply the tools and map the AG-UI endpoint that can be used by our frontend UI.
AIAgentagent=newOpenAIClient(openAiApiKey).GetChatClient("gpt-5.1").CreateAIAgent(instructions:"You are a helpful agent that allows the user to perform management tasks in Agent 365 and call Agent 365 MCP Servers.",tools:[..managementTools]);app.MapAGUI("/",agent);app.Run();
However, if we run this - it fails! The reason for the failure is that Entra ID - which is securing the MCP Server - does not accept the resource parameter that is sent by the C# Model Context Protocol SDK in the OAuth2 flow. This particular problem is discussed in various places:
Here is a pull request that claims to fix the issue.
The C# MCP SDK actually follows the MCP specification, which mandates that the resource parameter should be passed when authorizing. But Entra doesn’t accept the parameter…
Actually, there is a proposal to make this parameter optional and not mandatory for MCP Clients. But rather than waiting for the MCP spec to change, and in the interest of finishing the demo, I simply forked the C# MCP SDK and did this change that simply removes the resource parameter:
With this fixed, the backend is working and we can move on to implementing the frontend using CopilotKit.
Creating the frontend
As mentioned above we use CopilotKit to create the frontend, a framework that can use the AG-UI protocol to talk to our backend. AG-UI greatly simplifies the process of building UIs for agents, by automatically handling e.g. streaming, state management and tool calling - and it is integrated into CopilotKit. CopilotKit has lots of hooks that can be used to do all kinds of cool stuff:
The frontend is based on the quickstart code for the CopilotKit/AG-UI integration with Microsoft Agent Framework, and can be found in this repo.
CopilotKit makes it easy to render tool call progress and result as custom React components. For example, this code implements a default tool calling GUI that handles all tool calls for our agent:
If the LLM calls one of the tools in the MCP Management MCP Server, it renders a custom UI:
As mentioned above, CopilotKit also has built-in support for handling “human in the loop” flows:
useHumanInTheLoop({name:"go_to_moon",description:"Go to the moon on request.",render:({respond,status})=>{return(<MoonCardthemeColor={themeColor}status={status}respond={respond}/>
);},},[themeColor],);
When we tell the agent that we want to go to the moon, the custom UI is rendered:
And when the button is clicked:
This is a video of the finished agent, that is accessing different Agent 365 MCP Servers:
This was a fun experiment, and I look forward to exploring the Agent 365 MCP Servers further. For more information, check out the CopilotKit docs and read the AG-UI specification.
Until next time, happy hacking!
]]>Andreas AdnerRunning Microsoft Agent 365 MCP Servers from a custom agent2025-12-02T00:00:00+00:002025-12-02T00:00:00+00:00https://nullpointer.se/agent-365-mcp-servers
Microsoft Agent 365
At Microsoft Ignite a couple of weeks ago, Microsoft accounced Agent 365 - the “control plane for AI agents”. Currently available only through the Frontier program, the long-term goal is that Agent 365 should be the framework for governing AI agents in the enterprise, at scale. So if you are into enterprise architecture and governance, Agent 365 is for you.
Diving into the docs for Agent 365, there are quite a few interesting nuggets also for us that are more into the tech than the enterprise governance stuff:
There is a new SDK for Agent 365, called the Microsoft Agent 365 SDK. Not to be confused with the Microsoft 365 Agents SDK, which is somewhat related - but still something completely different. Let that sink in - Microsoft has released two different SDKs with nearly identical names…
Similar to the Microsoft 365 Agent Toolkit, the SDK comes with a CLI called Agent 365 CLI that helps out with packaging and deployment of agents, as well as other things.
There are also tooling servers, described as “enterprise-grade Model Context Protocol (MCP) servers that give agents safe, governed access to business systems such as Microsoft Outlook, Microsoft Teams, Microsoft SharePoint and OneDrive, Microsoft Dataverse, and more through the tooling gateway”.
That third thing on the list is actually kind of huge. One of the main complaints from organizations adopting Microsoft Copilot has been the difficulty of doing what is arguably the most basic thing people expect - interacting with Microsoft productivity applications from an agent, creating documents, sending mails, booking meetings… And now it is possible, through first-party MCP Servers that are managed by Microsoft. What a time to be alive!
If your tenant is enrolled in the Frontier program, and if you have a M365 Copilot license, then you can easily add these MCP Servers in you Copilot Studio agent. I tried this out when it was launched and posted a video to LinkedIn, that demonstrated how the MCP Servers for Word and Outlook could be used to create documents and book meetings. Kind of neat! I expect that the list of first-party MCP Servers will grow over time, and that eventually we’ll be able to do almost anything from our agents.
The Agent 365 tooling servers
Using these MCP Servers from Copilot Studio is cool and all, but what I really wanted to try was to utilize these servers from Microsoft’s flagship agent orchestration framework - the Microsoft Agent Framework. That begs the question - how can we access these MCP Servers from our own code?
In the Agent 365 documentation, it is described how the “MCP Management Server” can be accessed from Visual Studio Code. From the docs it is clear that this MCP Server can be accessed at the following URL:
The environemnt ID should be replaced with the organization ID of your Power Platform environment.
Let’s connect to this endpoint in MCP Inspector! In this tool it is possible to initiate a guided authentication flow that consists of a number of steps, where Metadata Discovery is the first one. Executing this first step gives us some interesting information about the MCP Server:
In the metadata we can see information such as the available scopes and the authentication- and token request endpoints. We can continue to run the authentication wizard, but it fails directly in the next step, since the MCP Server doesn’t support Dynamic Client Registration, which it SHOULD according to the MCP specification. MCP Inspector is pretty strict, and since the MCP Server is not 100% up to spec, we need to explore other options.
But, in order to authenticate against the MCP Servers using OAuth2, some setup is required. We start by creating an App Registration in Entra ID. Make sure to select the second option that allows accounts in other organizations to use the API. Create the app registration and make a note of the “Application (client) ID”, which we will use later.
We are gonna be using Postman to execute the auth flow, so let’s add a Redirect URI that works with Postman. The platform type needs to be set to “Mobile and desktop applications”:
Then, we need to add some API permissions to our app registration. Go to the tab “APIs my organization uses” and find the Agent 365 API:s:
We can now select the permissions for the MCP Servers that we want to try. We’ll go for the Management, Word and Teams MCP Servers:
Now we can try to authenticate against the Management MCP Server, using Postman. Fill out the auth- and token endpoints according to what we got when we ran Metadata Discovery before. Set the scopes to ea9ffc3e-8a23-4a7d-836d-234d7c7565c1/McpServers.Management.All offline_access openid profile since we want to try out the Management MCP Server:
Click ‘Get new access token’ and you should be able to authenticate in a browser, and consent to the requested scopes:
Once this is done, you should get an access token that can be used to access the Management MCP Server!
We can now go back to MCP Inspector, and enter the authentication token:
Don’t forget to add Bearer, before the token:
Click “Connect” and you should be able to access the Management MCP Server, and list its tools:
Now we can use the GetMcpServers tool to list all available tools and their details, such as endpoint addresses:
Great, now we have the address to the Word MCP Server. Let’s try it! Do the authentication dance in Postman again, but change the scope to the one for the Word MCP Server:
Get the token, connect and we can now access the Word MCP Server:
Let’s use it to create a Word document. We call the WordCreateNewDocument tool:
And lo and behold - a Word document has been created in our Onedrive!
…with the text we supplied as a parameter:
Amazing, now we have what we need to (hopefully) be able to call these MCP Servers from an agent created in Microsoft Agent Framework! Stay tuned, in my next blog post I intend to show how this was accomplished - as demonstrated in this video.
Check out my next blog post, where I discuss how this agent is implemented.
Until next time, happy hacking!
]]>Andreas AdnerThe PPCS agent, dynamic C# code generation and the state of MCP2025-11-18T00:00:00+00:002025-11-18T00:00:00+00:00https://nullpointer.se/ppcs-and-state-of-mcp
Sara Lagerquist is the driving force behind the Power Platform Community in Sweden, and it really is an amazing community that she has built, with so many nice people and an amazing vibe overall. 14-time MVP Gustaf Westerlund held a great presentation about Principal Object Access (POA), a very techical topic that he still managed to make very entertaining and fun! Kudos to Gustaf!
In my presentation I showed a lot of demos (videos - doing live-demos is scary), basically a “best of” what I have posted to LinkedIn in the last couple of months. If you are interested, here is a “supercut” with all the demos from the event:
One of the main themes of my presentation was the creation of the “Power Platform Community Sweden” agent - a chatbot that could help Sara plan events and that can be deployed to a lot of different channels - like Claude Desktop, Teams, Copilot and a custom web app. I created a MCP Server for this purpose, that had a couple of simple tools that the agent can use:
CreateEvent
CreateSpeaker
AddSpeakerToEvent
ExecuteFetch - for querying Dataverse using FetchXml.
In the first demo I showed this MCP Server used from Claude Desktop. I gave Claude a list of past events and speakers from the PPCS website and it added them to Dataverse. The code for the MCP Server can be found in this repo. The demo:
Good thing it was a pre-recorded video that could be sped up, for the process of creating the events and speakers was painfully slow - it took almost eight minutes in total, and Claude Desktop was getting more and more sluggish as it went along, eventually almost grinding to a complete halt. Apparently, the really simple process of enumerating ~20 events and ~40 speakers and adding them to Dataverse in a loop, one at a time, using an MCP tool is real hard work for Claude. Why is that?
Perhaps this article from Anthropic sheds some light on this issue. It discusses the challenge of using many MCP Servers and tools, and the consequence this has on the LLM context window. The article led to quite a lot of discussion - and if you are into internet flamewars this YouTube video is worth a watch.
The article argues that MCP is so popular, agents often have quite a lot of MCP Servers connected to them, and the tool definitions get added to the context, potentially eating up so much context that the model spends more time parsing and interpreting tool metadata than actually solving the task at hand. And the results of tool calls, which may be large, also gets added to the context – and the result is a sluggish, barely usable agent. This sounds exactly like what happened in my demo: each individual MCP call was simple, but the cumulative overhead grew with every tool call, eventually overwhelming the context window. And it should be noted that I only had one (1) MCP Server. Not good, not good at all. Is there a better option?
The article outlines an interesting idea – instead of letting the LLM perform repeated MCP tool calls, let the LLM dynamically write code that executes the tool calls and handles the results. That way, the tool definitions and tool call results are kept out of the context window. Pure genius! But does it work?
I wanted to try it out for myself, so I rewrote the PPCS MCP Server from my demo and modified it so that it only has one tool - RunScript - that can be used to run C# code that has been dynamically generated by the LLM. The ScriptRunnerLib contains a small library that makes it possible to execute this code at runtime. The secret sauce here is the Roslyn C# Scripting SDK that makes it easy to run C# code on the fly at runtime, such a cool library!
So, I hooked up the new and improved MCP Server to Claude and the results were actually quite amazing! Instead of 8 minutes, it took only 41 seconds to add all events and speakers:
To make sure that the agent generated C# code that plays well with the Roslyn C# compiler, I gave it very detailed (and verbose) instructions - a couple of thousand tokens worth.
The execution in Claude Desktop was much faster, to be sure, but how can we know that it actually consumes less tokens? Claude Desktop doesn’t output the amount of tokens spent, so we’ll have to try it out in a different way. So, I went ahead and created two agents using the Microsoft Agent Framework, one agent that calls the tools one by one, MCP-style, and one that does the tool calls from dynamically generated code instead. The code for both the agents can be found here.
Please go through these past events and create the Events and Speakers in Dataverse. When done with all, just say 'Done!
Let’s run both agents!
Runningtoolcallingagent...-ToolCall:'CreateEvent'(Args:[eventName=MALMÖ,Fellowmind],[location=MALMÖ],[eventDate=2025-09-25T00:00:00Z]-ToolCall:'CreateSpeaker'(Args:[firstname=Danijel],[lastname=Buljat]-ToolCall:'CreateSpeaker'(Args:[firstname=David],[lastname=Schützer]-ToolCall:'CreateEvent'(Args:[eventName=STOCKHOLM,Xlent],[location=STOCKHOLM],[eventDate=2025-09-03T00:00:00Z]-ToolCall:'CreateSpeaker'(Args:[firstname=Marica],[lastname=Lagerheim]...-ToolCall:'CreateSpeaker'(Args:[firstname=Mark],[lastname=Smith]-ToolCall:'CreateSpeaker'(Args:[firstname=Chris],[lastname=Huntingford]Done!-InputTokens(Streaming):5584-OutputTokens(Streaming):1911(0wasusedforreasoning)-Totaltokens(Streaming):7495ToolCallingAgentElapsedTime:34313ms(34,31s)Runningcodegenagent...-ToolCall:'RunScript'(Args:[code=usingSystem;usingSystem.Collections.Generic;// Helper to create a speaker and collect resultstringCreateSpeakerSafe(stringfirst,stringlast){varres=CreateSpeaker(first,last);return$"Speaker {first}{last}: {res}";}// Helper to create an event and collect resultstringCreateEventSafe(stringname,stringlocation,DateTimedate){varres=CreateEvent(name,location,date);return$"Event {name} ({location}, {date:yyyy-MM-dd}): {res}";}varresults=newList<string>();// 2025-09-25 MALMÖ, Fellowmindresults.Add(CreateEventSafe("Fellowmind","Malmö",newDateTime(2025,9,25)));results.Add(CreateSpeakerSafe("Danijel","Buljat"));results.Add(CreateSpeakerSafe("David","Schützer"));...// 2019-09-05, Claremontresults.Add(CreateEventSafe("Claremont","",newDateTime(2019,9,5)));results.Add(CreateSpeakerSafe("Mark","Smith"));results.Add(CreateSpeakerSafe("Chris","Huntingford"));// Return all results so the host can see what happenedresults]Done!-InputTokens(Streaming):8902-OutputTokens(Streaming):2186(0wasusedforreasoning)-Totaltokens(Streaming):11088CodeGenAgentElapsedTime:59346ms(59,35s)
Hmm, the tool calling agent took 34 seconds, and it consumed 7495 tokens. And the code-gen agent took 59 seconds and consumed 11088 tokens. Wait, what!? Why is the code-gen agent consuming more tokens, I thought MCP (tool-calling) was bad??
Actually, the LLM (GPT-5.1 in this case) is actually super smart. What actually seems to happen here is that the LLM does parallel tool calling and lets the client do all tool calls without passing the results back to the LLM! It is smart enough to figure out that the tool calls are actually “fire-and-forget” and it doesn’t have to act on the results! Kind of clever! It seems that GPT-5.1 is doing a much better job than Claude Desktop for this particular scenario.
So, what happens if we give the LLM explicit instructions to actually evaluate the result from all tool calls? Let’s change the prompt accordingly:
Please go through these past events and create the Events and Speakers in Dataverse. After creating each Event or Speaker, make sure that it returns 'OK', before continuing to the next one. When done with all, just say 'Done!'
Let’s run it again!
Runningtoolcallingagent...-ToolCall:'CreateSpeaker'(Args:[firstname=Danijel],[lastname=Buljat]-ToolCall:'CreateSpeaker'(Args:[firstname=David],[lastname=Schützer]...-ToolCall:'CreateEvent'(Args:[eventName=SopraSteria],[location=STOCKHOLM],[eventDate=2023-05-10T00:00:00]-ToolCall:'CreateSpeaker'(Args:[firstname=Brian],[lastname=StokesochSaraLagerquist]-InputTokens(Streaming):73907-OutputTokens(Streaming):1281(0wasusedforreasoning)-Totaltokens(Streaming):75188ToolCallingAgentElapsedTime:50376ms(50,38s)Runningcodegenagent...-ToolCall:'RunScript'(Args:[code=usingSystem;usingSystem.Collections.Generic;stringCreateSpeakerSafe(stringfirst,stringlast){varres=CreateSpeaker(first,last);if(res!="OK")thrownewException($"Failed to create speaker {first}{last}: {res}");returnres;}stringCreateEventSafe(stringname,stringlocation,DateTimedate){varres=CreateEvent(name,location,date);if(res!="OK")thrownewException($"Failed to create event {name}: {res}");returnres;}// Helper to split full name into first/last (last word = last name)(stringfirst,stringlast)SplitName(stringfull){varparts=full.Trim().Split(' ',StringSplitOptions.RemoveEmptyEntries);if(parts.Length==1)return(parts[0],"");varlast=parts[^1];varfirst=string.Join(" ",parts[..^1]);return(first,last);}voidEnsureSpeakers(IEnumerable<string>speakers){foreach(varfullinspeakers){if(string.IsNullOrWhiteSpace(full))continue;var(first,last)=SplitName(full);CreateSpeakerSafe(first,last);}}// 2025-09-25 MALMÖ, FellowmindCreateEventSafe("2025-09-25 Fellowmind","MALMÖ",newDateTime(2025,9,25));EnsureSpeakers(new[]{"Danijel Buljat","David Schützer"});...// 2019-09-05, ClaremontCreateEventSafe("2019-09-05 Claremont","",newDateTime(2019,9,5));EnsureSpeakers(new[]{"Mark Smith","Chris Huntingford"});return"Done!";]Done!-InputTokens(Streaming):5795-OutputTokens(Streaming):1990(0wasusedforreasoning)-Totaltokens(Streaming):7785CodeGenAgentElapsedTime:48390ms(48,39s)
Now the tool calling agent consumes 73907 tokens! And the code-gen agent consumes 7785 tokens. That is 90% tokens saved!!! This aligns well with the “97% less tokens” claim from the article.
So, is this the death of MCP? Well, I really don’t think so and I think there should be ways to evolve the specification that could potentially address the current issues. For example making batch operations a part of the specification, and ways of doing tool calls that are excluded from to the context, among other things. And we shouldn’t forget that MCP is only part of the solution, much can probably be done at the LLM layer also with regard to tool calling.
Perhaps most important - make it possible to pass results between tool calls without polluting the context. I have the feeling that existing primitives in the MCP specification - especially Resources - have a role to play here. Imagine if an LLM could pass MCP Resource Links as parameters to subsequent tool calls, that would make parameter passing really light-weight!
So, MCP is probably not dead but it could use some new features to handle these kind of scenarios better.
Anyways, this was a fun experiment and I learned a thing or two about tool calling and context windows. As always, thanks for reading! The code for the examples above can be found here. Until next time, happy hacking!
