CCDev 2 - what you need to think about with MCP

Kevin McDonnell and Garry Trinder delve into the world of Model Context Protocol (MCP) and its implications for developers. We start with a starter overview of functionality of MCP and why it is important. However, we wanted to get beyond that initial view that is covered elsewhere and look at some of the challenges associated with using MCP and broader considerations that you need to be looking at. The conversation covers the importance of optimizing documentation for language models, governance in MCP usage, and strategies for getting started with MCP and then scaling. 

Takeaways

• MCP is a universal approach to context in AI.
• MCP servers can execute actions beyond API calls.
• Optimizing documentation for LLMs is essential for effective AI integration.
• Trust and governance are critical in using MCP servers.
• MCP can significantly enhance productivity in software development.
• Building an MCP server can be straightforward and quick.
• MCP allows for local execution of actions, enhancing flexibility.
• The future of MCP involves more robust governance and control mechanisms.
• Organizations should develop a strategy for managing MCP servers.
• Experimentation with MCP can lead to unexpected benefits and insights.

Useful links

Introduction - Model Context Protocol

Getting started with Local MCP Servers on Claude Desktop | Anthropic Help Center and For Claude Desktop Users – Model Context Protocol （MCP）

Use MCP servers in VS Code

Community built Graph MCP Server - GitHub - merill/lokka: MCP (Model Context Protocol) for Microsoft 365.

Azure AI Search:

Full text search - Azure AI Search | Microsoft Learn

Vector search - Azure AI Search | Microsoft Learn

Hybrid search - Azure AI Search | Microsoft Learn

MCP for beginners course - GitHub - microsoft/mcp-for-beginners

MCP Dev Days 29th/30th July (and available on demand after) - MCP Dev Days | Microsoft Reactor

Microsoft MCP Lab - GitHub - microsoft/mcsmcp: Lab for creating an MCP Server and using it in Microsoft Copilot Studio.

Microsoft's MCP Server collection - GitHub - microsoft/mcp: Catalog of official Microsoft MCP (Model Context Protocol) server implementations for AI-powered data access and tool integration

CLI for m365 MCP server - GitHub - pnp/cli-microsoft365-mcp-server: Manage Microsoft 365 using MCP server

GitHub - dotnet/dev-proxy: Simulate API failures, throttling, and chaos — all from your command line.

Transcript

Kevin McDonnell (00:02.316)
Welcome to the Copilot Connection. We're here to share with you all the news, insights and capabilities of the Microsoft Copilot ecosystem across the entire Microsoft stack. I'm Kevin McDonnell an MVP in Copilot and the Copilot strategy and modern workplace AI leader, Avanade, and we'll be releasing these episodes as podcasts and on YouTube with insights from experts from the community and Microsoft on what the different areas of Copilot are, the impact they can make to you and your organization.

what you need to do to prepare for them and start implementing them now and even how you can extend them. And in fact, this is one of our kind of offshoot shows where we're kind of focusing a little bit more on the agent and DevStack. So I have my co-host on this show, Garry.

Garry Trinder (00:49.998)
Hi Kevin, hi everyone. My name is Garry Trinder. I am a developer advocate at Microsoft focused on Microsoft 365 co-pilot extensibility, but AI in general. It seems like every day is AI day.

Kevin McDonnell (01:05.21)
It is through, do know it's funny, was at, they have our local place that does bring your own strawberries and every year they do for, I think it's about four or five weeks, they put on a load of music, they get a load of local bands to come and play and you can pick your strawberries, have a picnic, it's got bigger and bigger, the local breweries there and I bumped into a friend there, I haven't seen him about six months, he's Kevin, Kevin, I've got co-pilot and he was so excited.

I was like, oh, there's no escape. There is no escape from these conversations. Yeah. Well, actually, they run out of strawberries. So I wanted to drink my beer more importantly. so, yes, copilot is everywhere. And but I think this there's other things. And I say we're going to focus down not in this episode, not so much on the broad copilot, but specific areas. We talked in the last Devstream on this about

Garry Trinder (01:36.046)
I just want to enjoy my strawberries.

Kevin McDonnell (01:59.819)
of what you need to think about with extending copilot and agents and things. We said we'd pick up some particular topics. So this week I was going to propose something to you in our kind of regular catch up and you started to get to me all excited because you've been looking a lot at MCP. So it seems a good chance to talk about MCP this week.

Garry Trinder (02:19.842)
Yeah. MCP not not a master control program. We're not talking about Tron for those of a particular age. Definitely. But model context protocol, which is been the big thing for what about the last six months? feels like it's been around for ages, but it's actually probably quite young, but it's everywhere.

Kevin McDonnell (02:24.399)
I've always forget about that. She was our age.

Kevin McDonnell (02:42.489)
funny, it feels like it's been around ages, but also really recent at the same time. It's odd, isn't it?

Garry Trinder (02:47.342)
Yeah, it seems to like, I think these things come out and then people get really excited. And then eventually they start appearing in different places and then you get to use them. And it kind of, you know, it's that lag between first hearing it, actually using it, and then thinking, Oh yeah, everyone needs to know about this because this is really cool.

Kevin McDonnell (03:04.751)
And I think about the kind of tools catching up and things like that. You know, I know you're a big fan of Copilot Studio and that's had the capabilities to consume it. I think people realizing how they can build these things like authentication. before we go too much in that, what actually is it? We should probably start with that, really.

Garry Trinder (03:09.059)
Yeah.

Garry Trinder (03:24.654)
Yeah, so model context protocol is kind of a new way to bring additional context to the language models that you're using. So we've had approaches like this in the past. So plugins was one, API plugins where you wanna make an API call to a backend, bring some data back and return that as context.

And MCP kind of brings a more of a universal approach. So with plugins, there were different implementations for different systems that you'd be using. And it'd be a lot of overhead, a lot of work, and it would be tied to an API. And you don't always want just to call an API. You might have other things. You have databases, file systems, those kinds of things where an API is not actually involved. So MCP kind of brings this

approach to bring in the context in this universal way so that the idea is that you build an MCP server and that server exposes tools in a uniform way that a client can then understand and execute based on the intent or the prompt that the user has entered into that system. So that's kind of the universal element, but

What's really powerful about it is it's not just tied to APIs. You can call APIs if you want, and that is definitely a use case, but you can also run functions. You could run local functions on a local machine if you really wanted to. could, for local people, you could access the file systems again. So you access a backend database by doing queries. It takes away that, you know, it makes it more flexible.

Kevin McDonnell (05:03.919)
and local people.

Garry Trinder (05:18.897)
to be able to say, hey, here's a tool that you can use for this purpose and here is how you execute it. And it's very simple in that you have a name, you have a description, which is kind of standard these days, right? You've got to provide a good name description for the model to reason over and understand, you know, which one to do. No, you don't, no, I know. So you've got the name, the description.

of the server itself and then the tools that you expose again, the name of it, the parameters, the inputs that can be sent as well. certainly with my usage of using MCP, mainly in GitHub Copilot, I must say, in development and MCP support has been in VS Code for quite a while. It was one of the first things that kind of had that.

Kevin McDonnell (06:14.543)
Let's hold that in a sec. So this is about how you use those servers. So, MCP, as you say, is a way of describing something. It is the protocol. So an MCP isn't a thing. You have an MCP server, which is where you will, as you say, describe what it is and build those functions. It's kind of, it is an API, really. So you're...

Garry Trinder (06:17.418)
Okay. Yeah.

Garry Trinder (06:39.158)
Yeah, yes.

Kevin McDonnell (06:41.037)
Behind it, you may have another API. As you say, you may have a database, you might have a file share, but it's exposing API, a way to connect to whatever you want to connect in there. But it's that particular protocol, a bit like you have a REST API, it's defining what you need to put in there, which is that name and description that you have there. And those list of tools, of actions that it can take place along with descriptions of those. And the point of that description is really important, because if you have an API,

Garry Trinder (06:50.635)
Exactly,

Kevin McDonnell (07:09.547)
It could be SAP or something that has kind of all the databases don't actually have names, they're just IDs and you have to work out what it is and have mapping and certainly used to be like that. the point of those descriptions is to help the AI know what to use and choose what it is. So you've got a common way of defining that, which when you have plugins and...

Gosh, it's awful, I forgot many other things. You had like connectors and all sorts of other things previously. You had lots of different ways to describe that. Now with MCP, you've got a common way to do that. Whether it's taking action or returning knowledge, it can be the same way of doing that as well.

Garry Trinder (07:35.406)
Yeah.

Garry Trinder (07:51.532)
Yeah. And I think that that being able to take action part is really important because this is where we move into the, world of agents, agents that can reason, get, kind of more like, so you can expo, you could expo have a MCP server that exposes a, a tool that, the, that can be used to like search documentation, understand, okay, what do I need to do in my planning, my reasoning stage? And then.

other tools that allows the client to execute the right thing based upon all the context that it's got. And that's really quite powerful with the newer models, which then go into the reasoning steps where they will iterate over. It's not just you send in a prompt and it just gives you an answer. No, it will get an answer and go, based on this, I need to get more. I need to, for example, like,

Kevin McDonnell (08:36.847)
Hmm.

Garry Trinder (08:51.404)
The coding example is a great one. I've asked an agent to do something that has access to an MCP server. It could use a tool to get some documentation of like, you know, I want to implement X. Okay. What is X? I will go and find out about that. Now I've found out about that. I will run an MCP server that will allow me to look at your local code base so I can search across the files and

Kevin McDonnell (09:15.081)
a single prompt that the user has done, it's taken those extra steps with that in the background.

Garry Trinder (09:18.254)
Exactly. Yeah, so it might go through, like from one prompt, it might go through 10 iterations using different tools at different stages to build up a plan to then start to execute those things and to execute the tools in the MCP servers that allow it to do something like on your local machine, which might be update a file, for example, with an output. Those are the kind of, that's how the...

the communication kind of happens. all happening through these MCP servers. And that's where you get the real action and the real agentic kind of feel when you're using.

Kevin McDonnell (09:59.225)
So half our audience is going, wow, that's amazing. We can do all those cool things. And the other half's going, it can do all these things. How on do I stop it? But we will come to that slightly. So we talked about the MCP server. That's where you kind of make the magic happen. the MCP is the protocol that defines that. And then you've got the client, which is where you started talking about things like Claude and VS code, even a kind of copilot kind of.

Garry Trinder (10:08.344)
Hahaha.

Kevin McDonnell (10:28.151)
to that a little bit more in a minute, really with agents, are a way to consume those MCP servers. So that's, that's, where think you're starting to go with talking about that.

Garry Trinder (10:38.476)
Yeah. And this is the other point about the flexibility of MCP is that let's say, you know, you are, you have a product and you want to make it easier for people to, use, AI systems to maybe use your product, right? You've got the documentation, you've got the context. People are using all sorts of different systems these days. Right.

You people are using different IDs. So we've got people using VS code. You've got people using cursor. You've got people using copilot. You've got Claude. You've got all these different things, but MC if, if that, you know, if the client has MCP support, you only have to build one MCP server because it's, it can be used by all of them. So it becomes really powerful then, that you're building something once and it can be reused in lots of different systems that support that.

Kevin McDonnell (11:08.719)
Don't just use Microsoft.

Garry Trinder (11:34.062)
protocol. And, you know, as we'll see, there's different support across all the different platforms and services. And, you know, I fully expect that they will catch up and they will get some kind of level of support when that happens. We don't know. But, you know, for me, it will happen. There is that. But, you I don't you don't know what people's plans are either priorities. But, you know, from

Kevin McDonnell (11:51.535)
What you mean is you're not allowed to say it yet. Yeah.

Tree Tree.

Garry Trinder (12:01.228)
my own personal usage of using MCP servers to write code. It's an absolute game changer in the sense of you bring an MCP server in there and you have a good model that gives you these reasoning steps. And it does transform the way in which you look at AI and how it can help you do your work.

Kevin McDonnell (12:27.609)
So you mentioned using MCP servers there. And I know there's like, there's an MCP server for Dataverse. So if you've got your data with using Power Platform and Dynamics, you can expose that and take action on those things with a Dataverse server. This one for GitHub. So you can connect to that and kind of take action within there. I hope I'm not gonna get you in trouble by asking this, but what other kind of MCP servers are you using then?

Garry Trinder (12:34.19)
Mm-hmm.

Garry Trinder (12:53.326)
So the first one is there's MCP servers built into VS code. So I'm already using those straight out of that. Azure, there's an MCP, Azure MCP server.

Kevin McDonnell (13:05.44)
And they're there to kind of take action on VS code. like deploying that sort of thing you can do.

Garry Trinder (13:09.358)
Exactly. Yeah. So they're, they're already there as an example of like, you know, you're asking an agent to update some code in, in your code base. There's an MCP server that helps do that or something like, Hey, I've got an error in my terminal. You can use, there's an MCP server to get the response, get the output from that terminal and use that in the, in, in your prompt just as like, you're just referencing it. Those kinds of things.

Kevin McDonnell (13:35.469)
Ooh, I didn't know that. I always copy and paste it out, so that's a idea.

Garry Trinder (13:40.017)
Exactly. And those, those are the kinds of things where you start to go, Ooh, well, if I can use this and this tool here and this tool here, and you start then in your prompt, almost like orchestrating the different references, it starts to become very, very powerful then because you're just bringing more context in. The one which I am using and the, you know, kind of pushing my own product in a little bit is we have a dev proxy MCP server.

Now we built this MCP server as a way to reduce the complexity in our own product, because you have to create a config file, which is a JSON file. Right. And even though when I look at it and I know it inside out, I can appreciate it's complex. So we built this MCP server as a way for you to be able to use natural language to describe what you wanted from dev proxy. Like

hey, I've got an API and I want to introduce latency in there for real world simulation, or I want to simulate errors, 49s, all that kind of stuff. Before MCP, you would have to go to our documentation, you would have to figure out which plugin you needed, the shape of the configuration, you would have to work out all those things, and it wasn't the best. So we brought MCP server in to do that, so you could just use GitHub Copilot.

And what we did was we get, had MCP server with just two functions, one, which was search. So it would make a, an API call to our own search index that's running in Azure. So Azure AI search, would just do a keyword search and that would return back in.

Kevin McDonnell (15:22.984)
And sorry, what's that searching the knowledge base around the epoxy? Yeah.

Garry Trinder (15:26.57)
our documentation. So documentation that's in MS Learn that we have there in our public documentation. So we index that ourselves and then we just make an API call and we return back the information. So the MCP server then has a way of being able to understand what do you mean by latency? It can then look at the documentation and go, this is the block, the code snippet that I need or.

here's the different configurations that I've got available to me and all that kind of stuff. And another one is just simply a local function, which just detects what version of dev proxy you've got running on your machine. So that when we produce a code snippet, it's the right version for what you've got installed, which it sounds like a really simple thing, but that's really powerful to be able to do those two things. Because that means that if our documentation is slightly out of date, maybe

Our version hasn't been updated for whatever reason. The MCP server can figure out what version you've got and then overlay that into the output. So it's right for, for, for what you want. So it really shortcuts all of that, that problem.

Kevin McDonnell (16:36.559)
it? I'm going to be slightly harsh here. It's fair to say, I wouldn't say this is a gimmick, but it's kind an experiment on something you know about. is this the best use case? It's not bad, certainly, but it's allowing you to kind of explore some of the things that can happen as well.

Garry Trinder (16:43.052)
Yeah. It is.

Garry Trinder (16:50.731)
It's, yeah.

It's, it's a use case. And one of the things that you want to say is that we built it for one purpose and that purpose was helping people use our tool. The side benefit of that actually has now been. It helps us build our own tool because now our agents have full context of everything in our product from a user perspective. So when we go to build new features, we have an MCP server there now.

Kevin McDonnell (17:01.944)
Yeah.

Kevin McDonnell (17:09.039)
Hmm.

Kevin McDonnell (17:16.949)
interesting.

Garry Trinder (17:22.99)
And it can work out so much. So we're almost, almost getting to the point of like, well, now we're prompting our own features because we've brought the context into the model because our documentation helps us. We've got reference documentation, you know, like we need to add a new property. It knows exactly what the shape is already. So the chances of it getting it right has been massively increased because of the NCP servers.

Kevin McDonnell (17:30.639)
.

Kevin McDonnell (17:43.491)
Yeah.

Kevin McDonnell (17:48.675)
So just to reiterate, you've got your GitHub copilot running, you're in the chat there, you're saying, I want to add a property for this. It knows that you're talking about it because you can go and get that context from the knowledge and then immediately write that code based on that items in there. So you've got that front to back, you're not jumping around, kind of copying and pasting ideas between things. It's got that information to kind ground.

Garry Trinder (18:13.09)
So I'll give you a good example of this. So in DevProxy, have it's command line tool and we have a command for generating a JSON web token. And it's quite complex. There's lots of different parameters that we've got in there. I'm also building a VS code extension, which uses that command and we want you to expose it in a UI. So you could go and kind of go through the process of like, hey, what's the name? What scopes do you want? All that kind of stuff.

Using the MCP server, because we had it all documented, the agent built out the whole feature with all of the parameters that had been defined because it had that context. So from an extensibility point of view, that was amazing. That was, you know, 10x, 100x, because it was able to just do it in one prompt. There were a few little things that I wanted to tidy up, but the fact that it did so much.

really for me was it wasn't just necessarily the agent that I was using. It was the context that it had available to it because there's times when for whatever reason, the MCP server has not been running on my machine and I've got a response and it's gone, that's, that's a bit weird. And then you turn it on and it's like, okay, we're, we're, we're back to where we were now. And it just kind of shows the pre MCP kind of days. now the

Kevin McDonnell (19:28.888)
Yeah.

Garry Trinder (19:38.338)
the MCP days that we've got that context of our own product to help us build our own product, which that was a big game changer.

Kevin McDonnell (19:45.837)
And I think it's going to be a bit like Copilot and ChatGPT, the generative AI tools, that people are going to explore new ways of doing this. I think there is a certain amount of building things for its particular purpose, exactly as you said there. But then you're going to discover more around this and putting it on there. So probably a good chance for people to talk about how they build their own servers from there. it's basically these are APIs, as I said.

So you build it like you would an API within there. you could, there's various kind of starter kits for TypeScript, C Sharp, et cetera. can, it will generate these packages. on the, actually I need to put this in the show notes as well. If you go onto the model context protocol, GitHub, then there's C Sharp there, there's TypeScript, Python. I think there's a load of others, probably Java, but haven't checked for that as well. But there's a whole lot of languages.

Garry Trinder (20:40.142)
There's Java, yeah, as well. Yep.

Kevin McDonnell (20:45.007)
And there's samples of running those fairly basic web servers, to get we're not going to talk about authentication yet. Gary, don't worry. I'm not going to start hounding you on that soon, but you can spin something up very quickly on that. So if you wanted it to read from a very public file and something that you didn't think was secret, you can do that very quickly and easily. I know Dan Laskovitz absolutely loves his jokes for one of these these build that looks like it looks at a dad joke website and

gosh, who's the ninja guy? I'm gonna get so much trouble saying ninja guy, who everyone had the jokes around being harder than the kind of 2000s memes about him. I always forget his name. Chuck Norris. Thank you. It's a Chuck Norris wiki and it kind of uses that and it helps you generate things with that. It's a very

Garry Trinder (21:30.926)
Chuck Norris.

Kevin McDonnell (21:38.901)
simple way of doing that. You can use Azure Functions, there's a wrap around Azure Functions for turning those into MCP servers. My personal favourite, I love Aspire, the kind of .NET framework. Yeah, I think it's kind of hosting framework, so it can be web and many other things, and there's various MCP ways of doing that from them. So there's a whole load of different ways that you can connect and expose and

I think it's fair to say the number of ways of doing that are increasing by the day, more and more ways of doing that that simplifies a lot of those items as well. if you're a developer, I'd say it's I haven't seen any kind of low code ways yet. I'd say they're almost all more pro-code versions so far. There might be a few things out there.

Garry Trinder (22:29.1)
Yeah. mean, just to kind of put that out there, it's like building an MCP server is it sounds more than it is. Like you say server and you think, Ooh, that's quite hefty. Right. I mean, the, dev proxy MCP server is three files that are about 30 odd lines long. That's it to implement everything that we've got, because it's just a, like, it's, it's the standard shape.

Kevin McDonnell (22:36.505)
Yeah.

Garry Trinder (22:54.25)
of like, here's the server name and description, like the version, here's the tools, and then a function for whatever that tool needs to do. And in some cases, that's just an API call. So your other, like, it's kind of like the MCP server bit is not really where a lot of the work happens. In our case, it was the search index. Exactly. It was the search index. It was actually the content. So our content needed to...

Kevin McDonnell (23:15.106)
in most cases shouldn't be. Yeah.

Garry Trinder (23:23.97)
Like we kind of thought about this and it was like, well, we want to index our content in a way that we're chunking it in the way that we want. So, we want to, we don't want massive pages. You could take that approach if you really wanted, but that's kind of where you're most of our time was spent actually not building the MCP server itself. was building the thing that we were going to query and refining that. then

What is really quite interesting is from going forwards, like we'd never had to change this embassy piece over because there's no reason to, and if we do want to change things, it's going to be, it's going to be relevant. maybe, but yeah, but, the, it's the, can be down to the, again, the re how good is your content is your content optimized.

Kevin McDonnell (24:02.625)
Well, until the protocol changes or something else changes, but yeah.

Garry Trinder (24:19.278)
for use by an LLM. That's the next thing. it is, and it kind of comes back to that, know, the getting the context is great, but if the context is wrong or it's ambiguous and it's not clear, then that will have an impact on the output that you get. So this, this is kind of where, in our journey of using MCP, where we're kind of in a bit of a, our docs were written for people.

Kevin McDonnell (24:21.549)
It's a recurring copilot story.

Garry Trinder (24:49.826)
They were written to be on a platform for documentation, not necessarily to be read by LLMs. So actually, we optimize our content in a way that makes it more readable for an LLM? Because what we'll find, and I am certainly finding as a developer, is I'm going to the chat box first. I'm not going to the documentation.

Kevin McDonnell (24:59.535)
very interesting statement there.

Garry Trinder (25:16.142)
I'm going to the documentation when something goes wrong, like it goes completely off the rails. And then I might bring that context in. So, I mean, I can give you a good example here. I used an agent to integrate Tailwind CSS into a project. And there was no MCP server. There is no Tailwind CSS MCP server. So it was just coming from the model. As we know, models have a cutoff with their training data.

What happened was the integration failed. The agent couldn't get it right because it didn't understand that a new version of Tailwind had appeared. And it was giving me version three information when it needed to give me version four. My solution to that was go to the, uh, go to the website for Tailwind, copy all the content out of a page, dump it in a markdown document, and then pass that to the, uh, the agent and say, use the content inside this document to

to work it out and guess what? It worked it out. Now from my point of view, that was why is there not a Tailwind CSS MCP server? Because that would have solved my problem completely. Because I haven't built it. But from a product point of view.

Kevin McDonnell (26:26.197)
you haven't built it yet. And I suspect someone has, it's just not publicly available. And I think that's one of the things about these MCP servers is they have... there's some people like GitHub who've made them available. I think one of the big issues for me for a long time has been the lack of authentication in that protocol. So there wasn't a defined common way to authenticate against these servers.

were fantastic. If you've got some like GitHub, especially for Reeds or even the dev proxy for Reeds, in some ways, I'm hesitating to not bring up our argument before we started, but in some ways, there's no real authentication needed to that. Anyone could go in there and get that information from there. But certainly, someone who works with a lot of enterprise clients, that's a pretty limited step to it. So I think there was a lot of excitement, but it kind of

sort of made people hesitate. Now that authentication is in there, we've got things like the Dataverse MCP server. We've got the, as you know, it's a public one, but the Microsoft Learn has got an MCP server. I think we'll see people start to build those. But people want to know, you want to be able to throttle, you want to make sure that you haven't got, you you talked about making dev proxy available for AI, available for agents. You don't want people going hammering these MCP servers.

to pull the information out automatically and ruin it for everyone else or ramping up huge as your AWS bills. So to me, I think we'll start to see authentication come through purely as a way to control know who's doing what, see volumes, help throttle on a per person basis, et cetera, et cetera. I think now, I think it was literally only two or three weeks ago that they started to build, they put the protocol out for authentication.

about six-ish weeks ago and it started to come through into the samples, into the frameworks. I know it's hit the C sharp one. people are able to start building things with that and building that authentication, which means you can have this lovely MCP server, but only allow it to people you want to allow it or even only allow people to do certain things. So you might allow everyone who is authenticated to read, but only certain people to do some of the rights and those actions within there.

Kevin McDonnell (28:50.799)
how you get people to sign off on that is an interesting thing. I was having a chat with someone the other day, because you don't want them popping up and having to kind of signing all the scopes and things on there. But I think this is where some of the issues are, that kind of excitement of I can do anything like I could with an API. APIs, especially REST APIs, have evolved an awful lot on how to manage that. And MCPs...

Garry Trinder (28:53.582)
You

Kevin McDonnell (29:17.151)
doing that much faster because it's got that history to learn from, it's starting to, it's starting to have to do those things. then similar to what you're saying there, people are also looking at what's different, which may not be necessarily a technical difference, but a use difference. It's the way people use it. The patterns of that are going to be different to APIs on there. It's probably not going to be a kind of things being hit on a regular basis. They're missing and get

whammed when you're kind of recreating, like in your case, a dev proxy item, and then it may not get touched for a while. So I think people start to see the different ways this gets used. I think it will change, change some of the functions that need to be created and the styles of those they in many ways, they can be a bit more flexible. Whereas with an API, you'll kind of get you almost get into a very specific thing. And I think they'll still be there in some cases.

Yeah, for example, with things like the graph where you have like filters and selects, know, which columns you want, you could that's a lot more flexible, you can almost allow the LLM to kind of do that. And your your function itself may not care about that, you may allow it to define what you want to get. And let the LLM for the MCP server define that select statement, you might not need to put it in there yourself.

as well. I think people will evolve an awful lot as they go around on how they use that. So I think the issue is the moment, auth and working out how you do this effectively.

Garry Trinder (30:50.594)
Yeah.

Garry Trinder (30:55.298)
Yeah, I think there's definitely, there's a few things that you mentioned. One of them is trust. Definitely. I had that same thing with the tailwind example. Like I went straight away. I know the value of MCP servers. I want one. And yes, I could have gone to a community one and got one. Do I trust those?

That was then the next question of, well, okay, for what I needed at that point, I was able to solve it myself. I would like to see an official MCP server.

Kevin McDonnell (31:22.572)
Just when you said, just very quick, so there was an interesting comment. You could go to community and get an MCP server. Are you talking about getting the code and running that yourself or connecting to an existing one?

Garry Trinder (31:34.414)
It could be anything. So in this scenario, it was a repo on GitHub that had the code there or it's published to MPM. And then I could just run, know, MPX and then the package and that would run the MCP server on my local machine. And that's.

Kevin McDonnell (31:46.105)
Mm-hmm.

Kevin McDonnell (31:52.397)
Yeah. But you have no way or you have to do quite a bit of work to be sure on where that's going from.

Garry Trinder (31:58.734)
Yeah, exactly. It's due diligence, right? It's when you bring it in in packages, you're bringing it in from a source that you trust and that you use. Those are the kind of things that went through my head when I was doing that. And that should be applied to anything that you do anyway. The authentication side, absolutely.

Kevin McDonnell (32:16.334)
Hmm.

Garry Trinder (32:24.278)
In our case, you know, we using dev proxy for public documentation with a public API. We don't need to authenticate people. It's just a request. It's getting back some, some, some data. But if you're using enterprise data, you know, again, you're calling graph, then you're going to need that authentication. If you just got an API, you know, you're going to want to think about what authentication methods you do support. And there are different ways of going about that.

You can go to the code level, could use services like API management as well. So API management has got actually a really cool feature that there's a feature to expose APIs as MCP servers. So if you already have something, yep.

Kevin McDonnell (33:03.555)
Hmm. Sorry, just in case people on API manager, that's the Azure service that you're talking about there.

Garry Trinder (33:09.73)
The API management service. Yeah. So then you can take those APIs. You can put policies around them, do the things which you were saying, Kev, about subscriptions, throttling policies, authentication methods as well. And you can wrap around your APIs. So you've got that as a potential solution. I think it's interesting with MCP because before we were having the discussions of, you

Kevin McDonnell (33:18.507)
throttling. Yeah.

Garry Trinder (33:39.116)
You want to connect the language models to your data, right? The more it's connected to your data, then the more relevant, accurate the answers are going to be. And we were in a world where it was like, well, that has to be an API now. But with MCP, that's kind of moved that away a bit. It's like, yeah, it can be an API.

Kevin McDonnell (33:59.843)
You could do RPA and have it, you know, type in a thing, go and have a robot that pulls a piece of paper and reads that. But if your data's there, that is possible these days. But generally, yeah.

Garry Trinder (34:04.718)
Yeah.

But it does open up the different possibilities, like querying directly to a database, going straight to the file system, all that kind of stuff, doing things locally on your machine as well, is another powerful thing, being able to just execute something locally and get that context without having to push that to the cloud or anything. Obviously, the context goes into the chat, so be wary of that.

Kevin McDonnell (34:33.22)
Yeah.

You could, you you were talking about this before the show, there's, we think it's called Windows Foundry coming, isn't it? Which is basically exposing an MCP server for your Windows instance, only for you, I hope. That better have authentication and make sure that's not let down. But you could do things like, I want to go into dark mode, I want to find these files and then move them to this place.

Garry Trinder (34:43.682)
Yeah

Kevin McDonnell (35:01.119)
amazing. You could have that natural language. I want you to find all files like with this sort of pattern, then move them into this folder, and it would kind of generate the script for you. And then you can run your local LLMs. You've got Azure Foundry Local. You could do all these things without going to the cloud, running your local stuff, which I think is huge.

Garry Trinder (35:22.51)
Yeah. And that's the thing. It's like, again, kind of getting out of the mindset of MCP is just another way to query a database or something like that. It's like, it's a way of doing activity or actions and the, the, the windows AI foundry, foundry local approaches, then keeping everything on, on your box, right? Using language models on your box. You're not even going to Azure in the cloud.

but using the models locally to then be able to use MCP servers on your machine, like examples of interacting with applications on Windows through an MCP server.

that's where the automation and being able to use, you know, the planning, the reasoning, like capabilities of, of language models. Obviously you're going to be running a model locally on your machine. there's certain limitations around, you know, what.

what power your machine has, what it can run effectively. But a lot of the smaller models, know, phi as an example, and lots of other small language models, they're getting better all the time as well. So again, as those models get better,

Being able to hook into MCP servers to instrument actions, get extra context, do processing locally on your machine. I think that's going to be a super interesting kind of future.

Kevin McDonnell (36:53.721)
So I want to get cynical now and talk about problems a little bit. Because you kind of trigger me think so. So one of things we got in the notes is talk about how does this scale? You've talked about it's pretty easy to build up your own MCP server. We can go and pull those and run those as MPX and things. So for an organization, I could have 20 different versions of that tailwind. So I think there's a discussion which we'll go on to in a minute about.

How do we manage all these MCP servers as APIs and those change? How do we manage all the clients consuming those and making sure they're using the right one? There's a huge challenge I see coming for that as that evolves. But one other thing, was when you were talking about local, because one of the big benefits I see to it is that you can start to cascade. We talked about that deep research, building up a plan and executing that. So that example I said, go and find me these files, rename them.

from there. Now, if I was building an agent or a multi agentic system, then I would put kind of boundaries within this and I'd make sure this agent only spoke to this MCP server, I'd make sure this agent only spoke to them and I defined within there, you should only do these things as well. But if you're building all these MCP servers, especially some of these local ones, and your local agent equivalent, whether that's Claude or whatever is talking to those,

How the hell do you stop it doing things? How do you stop it going too far?

Garry Trinder (38:26.412)
Yeah. I mean, at the moment it's there's a big stop button and you hit the big stop button when you see it going off the rails, but that's kind of the, in some cases that, you know, you're able to do that because you can see it and you can see it's reasoning. You've got something we're in the background, some background process. You're not necessarily going to see that, either. so yeah, there is absolutely, I would say still some way to go in terms of scaling these things out. like.

Kevin McDonnell (38:30.703)
and

Kevin McDonnell (38:44.655)
Hmm.

Garry Trinder (38:55.69)
How do you know how much your MCP server is being used? Who's using it? What telemetry do you have on that? Those kinds of things.

Kevin McDonnell (39:02.391)
Yeah. Hopefully on your local machine, just you, but that's it.

Garry Trinder (39:07.566)
Yes, there is that, but obviously if you want to distribute that, yes, you've got different ways of distributing it. We've used NPM and NPX. The reality is you download the NPX and you run that on your machine. There are different approaches to that. There are hosted approaches as well. So it's not just running a package on your machine that's executing there. It's a cloud service, right? And there's different things that you want to kind of

Kevin McDonnell (39:31.405)
Hmm.

Garry Trinder (39:37.946)
have in mind, on, on that, think one of the things is though it's like, it's like, if you see the value in it, like as a proof of concept in a small way, like, Hey, we've got this content. How's this going to change the way that we write documents for whatever reason, because we've got this context, right? That might be something that you can implement on a small level quite easily, quite fast.

then go from there and go, okay, now we've proved the value that we can then scale up. Because I think there's sometimes an element that we like to blow things up and we like to make things really big and really complex and then forget about that. Well, will this thing actually change something for us? Now what I've seen is it has, but yeah.

Kevin McDonnell (40:24.141)
Yeah, I think it's similar to the microservices discussion again, isn't it? It's same thing, you know, do I need to build this? Does everything need to be this microservice? How big does it need to be? It's getting back to some of those discussions and some things will go wrong. I'm sorry, when I say some things go wrong, some people will design things that aren't optimal, is what I'm thinking more from that rather than...

any Terminator scenarios or anything like that. But it's kind of, we'll need to work out, no, this is too small, this is doing too discreet a thing versus this is too big and doing too many things. I think it's experimenting at this stage, isn't it?

Garry Trinder (41:04.492)
Yeah, yeah, it's experimenting and thinking about, you know, testing, but testing in a different way. So testing from a perspective of like testing MCP servers, for example, you're kind of testing the tools, like given this input, what is the output? So you're doing unit testing really on the MCP server, but you're

Kevin McDonnell (41:25.327)
Would you, I suppose there's, there'll be some MCP servers that will be very deterministic exactly as you say there, your caller tool, you'll get a response back. And then some, may build AI into that and you've got it more non-deterministic within there. So it would cover both those scenarios really, wouldn't it?

Garry Trinder (41:34.316)
Yeah.

Garry Trinder (41:44.438)
It would, but you're looking at different things. like traditional testing usually is like it works or it doesn't work. Right. It's a failure. Whereas with language models, that's nuanced in the, you can get a response, but it's still a failure because the response is just wrong. And, and this is kind of.

Kevin McDonnell (41:52.495)
Yeah.

Kevin McDonnell (42:07.727)
So maybe DevProxy is an example. You could write a unit test for hitting the search server that says, have got a response. That will give you that atomic piece that says that bit works. But exactly as you say, if I say, I want to know how to create the login, what's the login? I was about to say prompt, that's a real word. But what's the login text I should use?

And it might bring something completely different or very niche scenario, not the more generic one that you'd expect within there. So testing those kind of things is very non-deterministic.

Garry Trinder (42:42.04)
Yeah.

Garry Trinder (42:47.24)
yeah. So you can still, you can still test the non-deterministic things in the sense of you can like with LMG, not always going to get the same answer, right. In its response. And you might want to say, well, actually we want to evaluate the behavior of the MCP tool being used in the agent or whatever that we've built. Right. So you want to do the end, almost like the end to end testing that

your, you know, in your testing that this agent has access to this tool and given this prompt, it should provide this expected output and you try it. And then for some reason you don't get an expected output. kind of get a, it's all right, but it's not optimal. And you might class that as like.

Kevin McDonnell (43:34.061)
that could be like it could be a sentence that answers a question but doesn't it wouldn't fit an exact pattern but if you looked at that and you could always use an LLM to say is this answering that question?

Garry Trinder (43:46.038)
And, and that's the thing. you start to then look at using LLMs to evaluate the responses that came from an LLM.

Kevin McDonnell (43:54.735)
And then use the LLM to evaluate the LLM's responses and then use another LLM to evaluate, yeah.

Garry Trinder (43:58.19)
Yeah. So, so then it's kind of, you know, you get into a bit of a cycle, but the idea is that you should be able to kind of come up with some kind of scoring or benchmarking system that is maybe relevant to your scenario that then you can go, okay. This didn't work as we expected. Where can we optimize here? And one of the things that we find is for hours, it was the content.

Kevin McDonnell (44:03.554)
you

Garry Trinder (44:26.444)
what was coming back. So a really good example was we've got an internal API that you can call to stop, start, manage a dev proxy instance. What we found was the LLM was looking for proxy management API. We didn't call it that in our docs. So it got things wrong. it was like, was, but then that was our clarity in our documentation that we just called it proxy API. But what does proxy API actually mean?

Kevin McDonnell (44:40.547)
Yeah.

Yeah.

Garry Trinder (44:53.93)
It really is a proxy management API. That's what it does. the, but the, the LLM didn't, wasn't able to figure that out at first. So then we're looking at from an evaluation perspective, we need to go to our docs and we need to make some changes there so that when that does happen again, it's more, we've added additional clarity into our documentation, which helps the agent and MCP search.

Kevin McDonnell (44:57.047)
Interesting, isn't it?

Kevin McDonnell (45:17.625)
And that's a really important comment there. And it's something we're hitting, working on a big virtual assistant at the moment. I haven't sworn so far, but we're basically at the arse end of the project. So there's a whole load of things. There's the interim information system that's managing tickets of some kind. There's knowledge. That knowledge is being built. The system to maintain that knowledge is being built. There's a load of other systems.

Garry Trinder (45:30.572)
You

Kevin McDonnell (45:45.091)
And basically, because we're the virtual assistant connecting to all these things, all these things could be wrong. But from testing, vast majority of users testing are testing that virtual assistant. And then making determination, especially with the knowledge as to what's wrong, is interesting because...

it could be the orchestration, is it getting to the right thing? Is it getting to the right type of knowledge? It's a multinational organisation, so there's different languages, there's different regions and there's different content that's relevant to those that's not permissioned, but the agent effectively is designed to get you to the correct one first. And I could ask for other countries ones, but if I ask for that...

it'll take me there. If I don't specifically say what, it should take me to the right one. So it exactly your comment. It's pulling back right content. How do I validate that there's that? And exactly as you said there with the proxy management API, it could be your knowledge is badly written, whether for humans and it could be that it's wrongly there or exactly as you say, is it badly written for AI to be able to consume effectively? Which suddenly becomes a whole new world of looking at some of these things.

there as well. And I think it's, it's really important with we've also found with this system with things like the ticketing, the routing of the tickets, trying to determine whether it's the intent and the orchestration of the agent to get to the right place, whether the rules are wrong, whether the configuration of those cues have been set up. It's a lot of fun to be had with all this. It's, it's got to be said. And even with those kind of in the individual

Garry Trinder (47:04.533)
Yeah.

Garry Trinder (47:27.753)
Yeah, that's.

Kevin McDonnell (47:32.751)
kind of tests at each layer, pulling those all together still is surfacing problems.

Garry Trinder (47:39.052)
Yeah. And you know, we, it's, it's almost like you.

What was quite interesting is, know, you can kind of, we've got docs, so we've got this context. We'll just throw it in there and it's fine. And then you'll, start to use it and you're a bit like, I thought this would be better than it was. Or why did it get that bit wrong? Like, cause that's what you want, right? That's our kind of the dream, right? You put something in, you prompt it, bang, it's done. You're onto the next thing. You don't want to sit there and go, well, I prompted this thing and it just got it wrong. And now I need to find out why it got it wrong. And then you're like, I wish I'd have just done this myself. But then if you kind of look at.

Kevin McDonnell (47:55.471)
.

Garry Trinder (48:14.04)
and step back of like, well, how did it get it wrong? And I think that this is where we always got these things wrong. They're just now being surfaced to us more. the impact is we don't get what we want because of these problems that we've had. How many times where you go to different places and you read some documentation and go, I have no idea what this thing actually does. Are you being...

Kevin McDonnell (48:25.998)
Hahaha

Garry Trinder (48:43.214)
Are you being straight to the point? Are you being concise? That is what an LLM wants. It just wants to ask a question and get an answer. Um, and if you can't find it, then it's going to struggle, um, to give you a, a good answer. Um, it, you know, the chances of it going in a loop, maybe doing something you don't expect it to then start to increase. Um, so yeah, I find that, um,

The whole thing about optimizing for LLMs and there's, a big thing now about optimizing docs for LLMs is really when you look at it, a lot of things are common sense and things that we've already defined from a usability perspective a long time ago.

Kevin McDonnell (49:29.091)
Which is really important because some people listening to this, my initial reaction is, yes, but humans need to read this as well. It can't just be good for LLMs. But a lot of what is good for LLMs is a nice methodical way of getting it for humans as

Garry Trinder (49:45.536)
Exactly. Yep. Yeah. So a perfect example, and this is the one that we always kind of go to is, I just want to do a thing, right? I'm in the middle of my work. I'm going to the documentation to get an answer, to do something, to get on with my day. Right. I don't, I'm not interested in reading a novel and sitting down and doing two hours of learning to just solve this one problem that I have. Right.

Kevin McDonnell (50:12.813)
Tailwind, know, great example.

Garry Trinder (50:14.83)
Exactly. I just, I just want to get this thing done and be on with my way. And if you're hitting docs and you are having that problem, the LLM will have the same problem. and, and, and that's the thing. it's like optimizing for that and putting the thought into, okay, here are the different permutations of how we can use these things and having them clear in docs as very like concise how tos, is like, maybe it might even be like,

a sentence and a code snippet in from, from our perspective with dev proxy, but that's just getting straight. The answer is like FAQs, right? The more that you have of those, I think the better the LLM performance is going to be. I say that because that's something that, you know, I'm looking to test at the moment and experiment with how we can update our documentation to be

readable for humans, also better for everyone.

Kevin McDonnell (51:14.595)
I find that interesting and funny when you were talking about this earlier, I was kind of going through a flashback of our old of life of Greyhatbeard Princess and we built up a lovely repository of etiquette. So how you can use Microsoft 365 in the most effective way by following good etiquette. We came up with lots of kind of snippets, which actually I think would be fantastic for things like an MCP server.

Garry Trinder (51:26.158)
Yep.

Kevin McDonnell (51:44.803)
because they consume those little bits. So depending on what it's asked, it will kind of combine those together to get an answer from those little snippets. It was rubbish to consume as a user because you have bits all over the place. So to find the answer didn't work very well. That was one of the things that bugged me. And I'm now thinking, actually, we should go back to that content, revise it and kind of put an MCP server around it. That would be really nice. the...

The one problem I can see with that is how you may get even more things that are quite similar and you end up with a lot of overlaps. So making sure you don't supply the wrong answer because the kind of questions and answers are quite similar as well. think that that is a one-time. Maybe maybe that's a challenge of humans kind of building those that you end up creating questions and answers that overlap quite a lot.

Garry Trinder (52:17.581)
Hmm.

Yeah.

Kevin McDonnell (52:36.821)
and that kind of causes problems. Whereas if you're writing as a very human readable single document in lots of flow, you see that flow and you kind of generally see less of those overlaps versus the more atomic side. So that would be interesting to see how that comes through as well. The other one that I think would be interesting is, know Copilot does this well as a kind of end point.

Garry Trinder (52:54.552)
Yeah.

Kevin McDonnell (53:01.111)
But how do you know that things are good? Once you've gone into live, and we talked about testing, but when you've gone into live, I don't think there's a, and as you know, it might be wrong, get hub copilot, you have the thumbs up and thumbs down, but that wouldn't feed back to your MCP server at all, it? To be able to get that, that's going to be an interesting thing to look at. How do you know your MCP server continues to work effectively? How do you know your content is right without manual feedback?

Garry Trinder (53:13.784)
Correct.

That is... no it does not. Yeah, yeah.

Garry Trinder (53:29.602)
Yep. And that is definitely a problem that, that we have. We have an MCP server out there. We have no idea how it's being used, whether it's good, whether it's bad. If there's any feedback, we hope that people will just get in touch with us through our GitHub repository because there is no mechanism built into the protocol that helps you do that. know, that's

Kevin McDonnell (53:30.793)
That'll be interesting to see how they bring those links together.

Kevin McDonnell (53:38.328)
Mm.

Kevin McDonnell (53:53.987)
I sense a pull request coming.

Garry Trinder (53:58.135)
Yeah, but it's kind of in a way it's kind of like, well, that's a client problem. It's down to the client and how that implements there. it's like, if...

Kevin McDonnell (54:06.112)
True, but you could define that in the protocol to earning in same way of authentication. That's also a client problem, but there's a protocol on how to fit that that makes it common.

Garry Trinder (54:15.214)
Yeah. But these are definitely the things that, yeah, as you kind of get into it, it's then, okay, do what do we need to track? And then when you are tracking things, obviously, you need to make sure that what you're tracking and you're storing is relevant to what you're using.

Kevin McDonnell (54:25.848)
Yeah.

Kevin McDonnell (54:35.843)
And I guess think about your dev proxy as an example again. There you've got a search server effectively over the top of the dev proxy. So someone down the votes. How do you link what's returned from the search server all the way back to the actual article? You know, there's quite a few challenges.

Garry Trinder (54:51.884)
Yeah. And, and the other thing is in a prompt that has 10 iterations of different requests, your thumbs up thumbs down is of the whole thing. It's not a specific bit, which is the other thing. So again, it kind of goes back to invest in your own evaluations of using it yourself.

Kevin McDonnell (54:58.711)
Yeah. Yeah.

Which bit?

Garry Trinder (55:16.244)
seeing where things fall down, coming up with scenarios, testing them to then make those improvements. You know, from a documentation point of view, that's either changing the way that we chunk our documents in our indexes, whether we move from keyword search to semantic search, then to hybrid search, because we haven't gone through that process. We just did

Kevin McDonnell (55:24.386)
Mm.

Garry Trinder (55:44.438)
Straightforward traditional keyword search and that's been working fine. But you know, we, we might have to move to.

Kevin McDonnell (55:50.083)
just, okay, there were three words there that I kind of get, but I wonder if people want, are they all related to Azure AI search effectively? So if you don't know what those are, maybe that's something we'll drill into on a future show. I'll scribble a note on that, but go and have a look at Azure AI search around keywords semantic and hybrid, sorry.

Garry Trinder (56:00.418)
Yes.

Garry Trinder (56:12.802)
Yeah, there's different ways of being able to tweak these things. It could just be changing the content and you go through the same process or it could be, actually we need a different way of indexing. But you have to kind of figure out how you're gonna understand that, whether that is direct feedback from customers. If you've got it internal in your organization, you might have a...

bit more push of, of getting feedback directly for people. because the tools are not necessarily there to provide that feedback loop to you as an MCP provider. it's more of the here's how you. Yeah.

Kevin McDonnell (56:55.779)
mean, Microsoft learned a great example. I bet that's been hammered from all sorts of directions, how people know what's coming back there. It's going to be very hard. So we've covered an awful lot there, and I hope we've kind of dug at it in different ways to what people have heard about a lot of MPCS. I really want to bring out some of those kind of challenges on that. So we've gone from kind of, this is how you start with it, this is how you can build a very small server to talk about how you can run this as a kind of...

Garry Trinder (57:04.376)
Yeah, so.

Kevin McDonnell (57:25.251)
I wouldn't say as ISV, but something public facing within your enterprise, how you manage all these together. And one thing we've missed in the notes that we jumped a step within that, that I think will be fascinating in the way and something you mentioned when we talked earlier, you can't remember what it is yet, I love seeing your face on this, is the maturity model from this. And I think something certainly for Simon Hudson and Simon Doyle listening, I know they do great work with the M365 maturity model.

I would love to see a kind of almost definition of maturity model for MCP for organizations, rather than for a single server. It's about how you manage that. Because I think there's also a bit like Power Platform as well. You're going to, there should be citizen developers. I know I touched on low code. I can't believe there won't be a place where people can start to build very simple MCP servers, pointing at specific things that will then evolve into

the massive ones that need to manage, that bring in Azure AI search, that talk about some of the things I'm talking about with the agent. There's a scale of different things. An organization should be able to manage those and kind of help guide people on when you need to move through the different things. In the same way, when you look at Copilot Studio, building custom things, whether it's with Foundry or bigger Azure AI, there's lots of complexities and people are learning with that.

think it will be the same with MCP. I think that maturity model looking about kind of one to five and thinking about the different things that people need to manage. just remember one other thing we didn't talk about is version, not version control. Yeah, versioning. So let's say you've got the GitHub API and they add a new feel to that. At what point do you update all the clients that they have to update immediately? Do you allow people to kind of update that bit by bit?

I think this is again something that's been, you mentioned the API manager tool, part of Azure has got a great way of managing different versions that you can then subscribe to the different bits. I don't think we've seen that same evolution happen with MCP as well. So I think there's a lot to think about with some of these things. shouldn't, and you touch this, this doesn't mean you need to go right to the end and solve that before you get started, but starting to think about getting moving.

Kevin McDonnell (59:49.919)
starting to build up those different bits and maybe something we'll start to sketch together is what are those kind of scales you need to think about.

Garry Trinder (59:58.848)
Yeah. So, MCP feels very much like API APIs in the past. Like obviously MCP can use API APIs. can use things. Yeah, exactly. But it's the, you know, as a company, what is your strategy? Do you even have a strategy? Do you know? Yes. The first one that you build might be, you know, what not it might be in a way that you don't want to build them.

Kevin McDonnell (01:00:05.421)
Like Snoop.

Kevin McDonnell (01:00:11.043)
Yeah.

Garry Trinder (01:00:21.186)
but get that done first with the mindset of we want to standardize this. So, you know, what technology do we want to use? Like you mentioned, you could write an MCP server in many different languages, different frameworks, which one works for you?

try them, formulate a understanding of what you want as an organization to then start say, okay, our next level is when we build MCP servers, we use this technology for this reason. And then add in things like when we do authentication, is the process that we're gonna go through. actually,

Kevin McDonnell (01:00:57.537)
Okay, okay. No, no, start with authentication. anyway.

Garry Trinder (01:01:02.082)
But you, you know, you, it's the things that you just want to standardize because if you do like, if you have different ways of authenticating across different MCP servers, then you know, you're kind of shooting yourself in the foot there. Yes, that's fine at the beginning because you don't know any better. You're working that out.

Kevin McDonnell (01:01:09.345)
Check.

Garry Trinder (01:01:18.636)
But once you do work that out, have that as a standard, the same with APIs, right? You would have API councils in organizations that would, they would determine the design and the requirements for APIs. You could have exactly the same for MCP servers. How do you host them? Tools like API management, you don't go straight to them. You get there. You scale, exactly. You scale them. There are services out there in Azure that...

Kevin McDonnell (01:01:27.363)
shit.

Kevin McDonnell (01:01:34.456)
Hmm.

Kevin McDonnell (01:01:41.315)
how do you scale them as they get more popular?

Garry Trinder (01:01:48.366)
help you scale. you've got APIs already, you can immediately expose them by using API management and get the benefits of a service. But it depends of where you are, you know, on that maturity model, the different levels, but you it's you don't jump straight to 400. For me, it's very much we're in a world of seeing the value. No, exactly.

Kevin McDonnell (01:02:13.464)
And some people may never get to 400 as well, because there is no need to. Yeah.

Garry Trinder (01:02:17.87)
There's no need to, but having that level 100 level 200, least of like, have a standard that we're going to follow is really gonna, really gonna help you then evolve to then get to the next step. If things grow and you know, you need to maybe take things in a different direction, but I always go back to, and this is the big thing we always talk about it is value in AI and it's value in MCP. So having a use case of.

Kevin McDonnell (01:02:42.423)
Mm-hmm. Yeah.

Garry Trinder (01:02:47.374)
using MCP, seeing how it works, seeing how this universal way of getting context to a language model helps you in different ways that you may have not intended when you first set out. You solve one use case, but actually the benefits to us is now in my mind, I can't see why you wouldn't build an MCP server if you had a product that had documentation. I just...

Kevin McDonnell (01:03:03.581)
important.

Garry Trinder (01:03:16.352)
If for me, it's a no brainer, because it's a, you know, it's a shortcut to all of the information that the language model needs about that thing. Right. That that's, that's how good it is.

Kevin McDonnell (01:03:28.087)
Yeah. Just just on that value, I think it's that your comment, I thought you were going to say, make sure you look at value. I think you should, but you should also explore it almost with that level of uncertainty. It was a bit like the early days of copilot. You had to explore, you had to experiment. You're not necessarily going to guarantee the value you get straight away. You should think about it, but also say, right, we need to stretch this try out because we're seeing with this just

Garry Trinder (01:03:36.334)
Hmm.

Kevin McDonnell (01:03:56.694)
different things happen to what was expected and different benefits come out. just be a bit broader with your thinking on it because you'll see different capabilities come out. And by putting all this, I'm truly fascinated and terrified about what's going to happen with all these different MCP servers automatically coordinating together.

Garry Trinder (01:04:06.732)
So, yeah.

Kevin McDonnell (01:04:19.299)
It's going to be very... And for me, the way I see it is to put agents around those servers. So don't just expose those, have agents that kind of narrow down the scope. So you're kind of narrowing down from an orchestrator agent connecting to another one that has a limited scope. It's not going to guarantee it doesn't go everywhere, but it helps focus that down a lot more as well. And I think that that will help you will get a bit of control.

Garry Trinder (01:04:19.308)
Yeah

Garry Trinder (01:04:44.204)
Yeah. And I think the problem that you're talking about is something that, you know, it's no different to, let's say the power automate problem that we had in the past. You could build a workflow with many different actions. could class an MCP server as an action. You don't want a workflow that contains these two actions, like as a policy, you highlight that and you stop it. that's something that, yeah, it's, it's been a, it was a problem in the past. There's been solutions put in there for different services.

For me, it's exactly when you mentioned it, I was like, that's exactly the same thing. It's like, that's where you want that kind of, control from a governance point of view of you never use these things together. Now that's an interesting thing because then you're not, you're not talking about MCP. You're talking about the agent and you're talking about instructions and behaviors and building in those.

the governance instructions into the agent so that it makes the right decisions. Like, I can't do that. Like that's a no-no in the way that I work. Therefore I won't do it because at the moment it's just, I need to go and get data and here's something that can help me. I need to perform this action. Here's an action that can do it. And it's on the end user to determine whether that action happens or not. So one of the things that we haven't mentioned is, you know,

If you're in VS code, for example, you will always get that message of, I'm going to use this MCP server and I'm going to send this data. I'm going to do this. Do you allow it? So you're consenting in there. Obviously, if you trust it, you can just say, yeah, just do it, right? I'm fine.

Kevin McDonnell (01:06:15.959)
Hmm. That's a really good point. Really good point. Yeah. Yeah.

Kevin McDonnell (01:06:25.559)
And you can turn off the different servers at different points in time as well.

Garry Trinder (01:06:28.78)
Yeah, you can. So you can do that. I think at the moment it's just a maturity thing that, you know, it might be that we have presets that you have that you can switch different presets of like, here's a collection of MCP servers that are enabled for this scenario and I disable them for others. So, you know, I think that will probably happen. But yeah, it's always gonna change. It's always gonna evolve. It's not without.

problems and I'm sure that people will be looking to solve them as well. So yeah, but I think if anything, it's quite exciting with MCP. Once you've used it, I think you get it.

Kevin McDonnell (01:07:11.671)
So that's a lovely way to wrap up. How do we get people started on this? And we'll put some links into the show notes. Hopefully you've listened to us waffle on and you want to go and open your laptop and have a look. I mean, to me, I love Claude with MCP. I love Visual Studio Code as well with MCP is some really good ways and we'll put some links on how to get started with that. I mentioned Dan Laskovic has his joke MCP server, which very easy to use.

Garry Trinder (01:07:22.574)
you

Garry Trinder (01:07:28.396)
Mm-hmm.

Kevin McDonnell (01:07:40.627)
a link to that. For those who are C sharp, I'll put a link to the Aspire ones. I'll try and dig out the one about putting MCP around your Azure functions. Are there any other sort of particular areas you think, Gary, to get people started?

Garry Trinder (01:07:55.47)
So one thing is Microsoft, we've produced the MCP for beginners course, which is on GitHub. So whether you're .NET, Java, TypeScript, Python, whatever, there's content in there that we'll go through.

from the beginnings to advanced topics on MCP. What's actually interesting as well, there's some Dev Days happening as well on 29th and 30th of this month in July. So you can register for MCP Dev Days. So if you're looking to get involved, build, they're all virtual as well. So it's a two day event, then that will go through.

Kevin McDonnell (01:08:35.779)
And they're all virtual, aren't they?

Garry Trinder (01:08:44.174)
all of the topics that we've actually discussed today, but in great more detail with people who know more about them than what I do and folks from the product groups as well. So definitely check out that repository so you'll get everything that you need on that.

Kevin McDonnell (01:09:02.883)
That's great. And I think also if you look at the main MCP site, again, we'll put a site in there, there's a lot of links to servers that are out there, which are the ones running like the GitHub, know, non-Microsoft ones as well, ones you can download and run yourself. So there's a whole world out there. This isn't a Microsoft thing. Microsoft's fantastically adopting it, but there's so many other things out there as well to get out and try with it, which is really useful.

Garry Trinder (01:09:10.915)
Yeah.

Garry Trinder (01:09:25.774)
Yeah. There is also a repo which is on GitHub. So it's Microsoft slash MCP, which is a list of Microsoft MCP servers. So that's where you'll find MCP servers for like Azure DevOps for Dataverse, which you'd already mentioned as well, Microsoft docs. Yep. There's Playwright MCP in there as well. Even the M325 agents toolkit is in there as well. So that's

Kevin McDonnell (01:09:44.675)
they should develop when it's there.

Kevin McDonnell (01:09:52.109)
Thank

Garry Trinder (01:09:54.114)
might be useful as well if you're building the Clarity of Agents in VS Code.

Kevin McDonnell (01:09:56.331)
I'll put one. Gosh, I've forgotten his name, but it will be in the notes. But someone's built a Microsoft graph, one that's open source. So it's an open source version. Meryl. Yeah.

Garry Trinder (01:10:06.144)
be Merrill I think Merrill yeah so that'd be Kafka I think it's Locker, Locker that's it where have got Kafka from? Kafka's something else that's Apache. Too many names.

Kevin McDonnell (01:10:12.565)
a Yeah, that's the Apache one. Yeah. And again, it's open source. It's not officially supported, but I know a fair few Microsoft people you've had looking at. Ooh, that's quite nice. So, just knowing, knowing people, I know that's the scenarios like, but I want to go in the graph and I want to be on to write to SharePoint and generate teams and things.

Garry Trinder (01:10:28.226)
Yes. Yeah.

Garry Trinder (01:10:40.142)
So another mention, and this is little bit of the last one. So there's now the CLI for Microsoft 365 MCP server as well, which is a wrapper for CLI for Microsoft 365. You get 850 commands available in natural language across SharePoint, Power Platform, Exchange, Graph, Yammer.

Engage, sorry, Yama. And that's been announced as well and that's been distributed. that's a really interesting thing because this is something taking a tool that's been built for the command line and now plugging that into natural language and exposing all of the tools, the commands that have been available there. I find that fascinating and really excited to see how people are going to be able to use that.

just to kind of manage tenants.

Kevin McDonnell (01:11:34.08)
And are those open source? can people effectively see how that's built as well? So, yeah.

Garry Trinder (01:11:37.582)
wholly open source. So the dev proxy MCP server, ours is open source, CLI for Microsoft 365, the CLI and the MCP server, all open source as well. So it's a really good way as well of taking a look at the code. You will be surprised how little there is. I will put it that way. And that's one of, I think, the really good things about MCP is that it does not take a lot to build one and just try it.

It really doesn't. think it's so fast that it's worthwhile trying.

Kevin McDonnell (01:12:13.859)
Yeah, I know from my own experimentation using Aspire, I've spent about 90 % of my time trying to get Aspire bits working and getting distracted on building a web interface for it and the APIs and then about 10 % at very most look at the MCP side of things. But that's the joy of coding for fun is that you can get very easily distracted and enjoy it.

Garry Trinder (01:12:32.782)
was the way.

Garry Trinder (01:12:37.282)
Yeah. Yes.

Kevin McDonnell (01:12:40.707)
And guess I just ask people, please let us know how you get on. Have you have you experienced some of these issues? you? More importantly, have you experienced other issues or things that we haven't thought about? We'd love to hear that from people. So let us know. Ping us on on socials or I think you can get to us via the site as well. So have a look on that and just let us know what you think. And are there any areas you'd love to hear more? We can we're trying to keep this as a podcast, so we're not showing demos and things like that.

trying to link off to things like the Dev Days where there are more demos and I know Gary does various bits and pieces like that but if there is something you'd like to hear, see more of then let us know and we'll see we can make that happen.

but otherwise it is Friday afternoon. It is very, very hot out here, so I'm going to go and get something cold and turn my fan off, which is far too noisy. Thank you very much for joining us at Copilot Connection again and see you soon.

Garry Trinder (01:13:41.166)
All right. Cheers. Thank you. Bye bye.