AI Engineer
← All AI Engineer talks

AI Engineer World's Fair 2025

Building Protected MCP Servers

Den Delimarsky· MicrosoftJulia Kasper· Microsoft20:13

Read the talk

Building Protected MCP Servers

Follow a protected MCP request from its first HTTP challenge through OAuth discovery, C# token validation, Azure deployment, and authenticated tool use in VS Code.

From a talk by Den Delimarsky and Julia Kasper

Before you start: Familiarity with HTTP requests, bearer tokens, and basic ASP.NET Core configuration will help you follow the examples.

010:34 ↗

Who should be allowed to call your tools?

Should everyone who can reach an MCP server be allowed to use its tools? Clients such as Claude Desktop, VS Code, and Visual Studio can connect to servers that expose protected APIs. An internet-accessible server outside a VPN needs an authorization boundary just as those APIs do. Reachability is not permission.

Slide with a door lock photograph and three statements: not every server should be open, protection is super-important for remote servers, and not really relevant to local servers.
Not every server should be open: remote and local servers have different authorization needs.

The API behind a tool may need to know which customer is calling, what permissions that customer has, and which administrator policies apply. That user context must remain meaningful at the MCP layer: an administrator may have access to one set of tools, while a contributor receives another. Protecting the server therefore means preserving permission boundaries, not merely placing a login screen in front of an otherwise unrestricted tool catalog.

0:340:54
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:34 · section reference included

022:04 ↗

Local binaries have a different authentication boundary

A local MCP server is a program running in the machine’s execution context. It can authenticate to downstream APIs using secrets, certificates, passkeys associated with credentials on the machine, or ordinary authentication libraries. MCP does not need to prescribe one mechanism for all of those possibilities. Remote desktop and shared virtual-machine arrangements add their own identity questions, which Den Delimarsky leaves to implementers.

The precise protocol distinction is HTTP versus STDIO, rather than simply remote versus physically local. The March 26 authorization specification excludes STDIO from this HTTP authorization flow. A server listening on localhost over HTTP can still participate—which is how the later C# demonstration works.

2:042:12
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

2:04 · section reference included

033:07 ↗

Separate the resource server from the token factory

At recording time, the March 26 specification was stable and a revised authorization model was still a draft. Den describes the earlier model as making MCP developers operate a token factory: minting, signing, refreshing, and managing tokens. The historical specification did allow an authorization server to run as a separate service, so building a custom issuer was not literally mandatory; the coupling lay in authorization discovery through the MCP server’s origin. The practical concern remains substantial: implementing token issuance is a much larger security responsibility than implementing a tool.

The draft refined with Anthropic and security experts makes the roles explicit: the MCP server is a resource server, while an authorization server manages token issuance and lifetime. That authorization server can be an existing provider such as Okta, Auth0, or Microsoft Entra ID. The MCP application no longer needs to own the token factory.

3:073:28
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

3:07 · section reference included

044:32 ↗

Less security code, with clear responsibilities

Julia Kasper’s implementation question is straightforward: what must a developer still build? The server publishes metadata pointing to its authorization server, and it validates the tokens presented by clients. Existing identity services and OAuth libraries supply the machinery around that boundary. The speakers use OAuth 2.0 terminology; MCP’s authorization requirements are based on OAuth 2.1 alongside OAuth 2.0 metadata standards.

ComponentResponsibility
MCP clientComplete authorization, acquire a token, send it with requests
MCP resource serverPublish discovery metadata and validate incoming tokens
Authorization serverIssue tokens and manage their lifetime

The client completing authorization does not relieve the resource server of validation. A client’s possession of a token is not enough; the server must establish that the token authorizes access to this resource.

Three emoji-marked statements describe the client's end-to-end token dance, server token validation and metadata hosting, and minimal implementation work for developers.
Clients handle the token dance; servers validate tokens and host metadata.

This division also reduces the amount of custom security code in an MCP application. Developers can concentrate on the problem their tools solve while relying on established identity providers and framework components for security-sensitive operations.

4:324:50
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

4:32 · section reference included

056:59 ↗

A 401 response starts discovery

The authorization flow begins with an ordinary request that lacks user context:

  1. The MCP client requests data from the protected server.
  2. The server returns HTTP 401. Its WWW-Authenticate header points to a Protected Resource Metadata document, or PRM.
  3. The client retrieves that document and discovers which authorization server to use. The provider could be Entra ID, Okta, Auth0, or Keycloak.
  4. The client completes OAuth discovery and authorization to obtain a token.
  5. The client retries the resource request with that token. The MCP server validates it before returning data.

The talk’s diagram’s authorization step compresses an entire OAuth flow into one interaction. It does not mean the MCP server performs that flow on the client’s behalf.

Token validation also has a destination boundary. The subsequent June 18 specification requires validation that a token is intended for the MCP server and prohibits token passthrough to upstream APIs. Preserving downstream user context therefore requires appropriate, separate upstream credentials—not forwarding the MCP client’s bearer token unchanged.

PRM supplies the information needed to bootstrap discovery. In the explanation, it is a JSON document hosted by the MCP server that identifies the resource, lists its authorization servers, and can declare supported methods for bearer tokens and scopes. Den also mentions a JWT variation, but the demonstration uses JSON. The document tells a client where and how to begin authorization; it is not itself a credential.

6:597:05
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

6:59 · section reference included

069:09 ↗

Protect an ASP.NET Core MCP server

The C# demonstration uses an ASP.NET Core application and the official MCP C# SDK. The OAuth integration shown here was still in a pull request. Den begins with AddAuthentication, selecting the MCP authentication scheme and framework-provided validation. After repairing the screen sharing, he walks through the configuration again with the code visible.

The configuration has distinct layers:

  • Authentication and validation: MCP authentication defaults select the scheme, while framework JWT components validate the incoming token.
  • Discovery: Metadata events and the demonstrated AddMcp configuration supply PRM, including header-based bearer authentication and Entra ID authorization metadata.
  • Request processing: UseAuthentication and UseAuthorization add the middleware that applies authentication and authorization to requests.

For the JWT-validation layer, the following C# helper makes the trusted issuer and intended resource explicit. It complements the MCP-specific discovery configuration described above:

csharp

using Microsoft.AspNetCore.Authentication;
using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.IdentityModel.Tokens;

public static class TokenValidationConfiguration
{
    public static AuthenticationBuilder AddResourceTokenValidation(
        this AuthenticationBuilder authentication,
        string authority,
        string audience)
    {
        return authentication.AddJwtBearer(
            JwtBearerDefaults.AuthenticationScheme,
            options =>
            {
                options.Authority = authority;
                options.Audience = audience;
                options.TokenValidationParameters =
                    new TokenValidationParameters
                    {
                        ValidateIssuer = true,
                        ValidateAudience = true,
                        ValidateLifetime = true,
                        ValidateIssuerSigningKey = true
                    };
            });
    }
}

The JWT handler supplies validation machinery; the application still supplies the identity provider and resource it trusts. The server then starts locally for the end-to-end test.

In the browser, the localhost PRM identifies login.microsoftonline.com as the authorization server and declares scopes and header-based bearer authentication. On the client side, Den configures a generic OAuth provider with a client ID and scopes, then uses the normal transport setup to connect to the test server. The client’s authorization logic is not specific to Microsoft.

The client run finishes quickly because Den is already authorized; it does not show a fresh interactive sign-in. He reports that the client discovers metadata, acquires a token from Entra ID, and sends it to the server. The server verifies the token and invokes the weather tool, which returns no alerts. This completes the protected request path using the pending SDK integration.

9:099:25
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

9:09 · section reference included

0712:51 ↗

Put a gateway in front of the deployed server

Moving from localhost to a deployed service introduces another place to enforce protection: a gateway. Julia, who works on Azure API Management, recommends placing it between clients and the remote MCP server. She starts a public sample deployment with the Azure Developer CLI:

bash

azd up

The command provisions the sample’s Azure resources while she explains the architecture.

Azure API Management fronts an Azure-hosted MCP server with three implemented tools. The architecture slide shows the server in Azure Functions, with VS Code and MCP Inspector as clients. The Azure Remote MCP Proxy arrangement includes an OAuth API that coordinates Entra ID login and consent, alongside the MCP API that exposes the backend.

Architecture diagram connects VS Code and MCP Inspector to an Azure API Management gateway, an Azure Function with three MCP tools, and Microsoft Entra ID below.
Azure API Management sits between MCP clients and an Azure Function MCP server, with Microsoft Entra ID handling identity.

Julia estimates that this sample deployment takes “maybe five minutes max.” That is an estimate for her demonstration, without measured timing conditions. Provisioning also creates an App Service plan and Log Analytics for hosting, monitoring, analysis, and logging. These are the operational components behind her description of the example as production ready; they do not establish that an arbitrary deployment has passed a security review.

Before connecting a client, Julia checks API Management’s APIs tab for both expected endpoints: the MCP API and the OAuth API. She also notes that the samples will evolve with the specification. This deployment check establishes that both the resource path and the authorization path are present before testing consent.

12:5113:08
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

12:51 · section reference included

0917:52 ↗

Expose existing REST operations as tools

A custom MCP implementation is not the only starting point. Julia next demonstrates API Management’s ability to expose selected operations from an existing REST API as MCP tools. Instead of rewriting those operations, a developer configures which endpoints should become tools and connects the generated MCP endpoint to a client.

Julia copies that endpoint into VS Code and starts it, explicitly reminding developers to implement authorization. API Management can secure the interface as well as host it. Copilot detects the server, and VS Code lists three tools backed by the REST API. This final example reaches discovery and readiness to interact; the recording does not show a completed invocation of those REST-backed tools.

17:5218:14
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

17:52 · section reference included

1019:28 ↗

Build against the specification and security guidance

The closing guidance returns to the security contract beneath the demos. Den points developers to the authorization specifications and to Security Best Practices, which he says was developed with Anthropic. Those documents matter whether the interface comes from a handwritten server or an existing REST API: the implementation still needs a sound authorization boundary.

Slide lists modelcontextprotocol.io links for the dated authorization specification, draft authorization specification, and draft security best practices beside a castle photograph.
MCP authorization specifications and security best practices provide further guidance.

At recording time, VS Code Insiders supports the new authorization model and provides a concrete client for trying it. Den encourages developers to install it, test their servers, and provide feedback, with Harold available at the conference to help debug problems. The next step is to exercise the full path—discovery, consent, validation, and tool access—with an actual client, not stop once the endpoint responds.

19:2819:30
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

19:28 · section reference included

Resources

From the talk

Further reading

Updates since the talk

Read the complete timestamped transcript
  1. 0:00

    [upbeat music] Welcome, folks, uh, to the Building Protected MCP Servers session.

  2. 0:20

    Uh, I'm Den Delimarsky. I'm a Product Engineer at Microsoft, uh, and member of the MCP Steering Committee.

  3. 0:25

    And I'm Julia, and I work in Azure API Management at Microsoft. And the both of us are part of an MCP squad at Microsoft, so I guess that's why we are here.

  4. 0:34

    Yeah. Um, so we're gonna... Again, talking about protected MCP servers, and, uh, why, why is this even important? Why is this even a topic? Well, the thing is, when we talk about MCP servers and MCP servers that folks connect to their whatever clients, whether it's Claude Desktop, VS Code, VS, not every server should be open because there's

  5. 0:54

    a bunch of different APIs that might require authorization. They're protected. So naturally, your MCP server needs to be able to do the same. Uh, it is super important for remote MCP servers because anybody can access them, and especially if the servers are open to the broad internet, not behind a VPN.

  6. 1:10

    Uh, but it's not really relevant for local servers, uh, and mainly because locally you can do a bunch of stuff already because it's just a binary, and we'll get to that in a second.

  7. 1:20

    Now, um, if you're building MCP servers and remote MCP servers specifically, one of the things that you're connecting to are likely third-party APIs, uh, whether it's your own or somebody else's, and that API requires user context.

  8. 1:33

    That API needs to know who's invoking it because different customers have different permissions. You might have different admin policies. Uh, so while your API does control, through the help of an identity provider, as you...

  9. 1:46

    who actually has access, uh, this needs to be somehow exposed to the MCP layer. Uh, and of course your API will act differently depending on the credentials that you give it.

  10. 1:56

    If I'm an admin, I get access to a certain set of tools. If I'm somebody that's just a contributor, I get a- access to a, a bunch of different tools.

  11. 2:04

    Now, all these things considered, one of the questions I get asked a lot is like, "Well, okay, th- this is all great for remote, but why not local? Why...

  12. 2:12

    What's the story for authorization for local servers?" And the answer is kind of simple. Local servers are binaries on the box. They're binaries that run within the context of whatever machine you have.

  13. 2:24

    That means that they can do auth in any way you can possibly have. Like, it doesn't need to be auth. You can have credentials that are secrets. You can have certificates.

  14. 2:32

    You can have passkeys that are bound to whatever credential you have on the box. Like, it's just... Like, you don't have any constraints whatsoever. Um, that means that any APIs you connect to can also be done, you know, in any way with any of the off-the-shelf libraries.

  15. 2:46

    Uh, there's of course special cases here if you do things like remote desktop and all sorts of kind of multi-user scenarios on VMs. Uh, but that's kind of out of scope for MCP.

  16. 2:56

    That's something that we've left to implementers. Now, remote servers, let's get back to that. So one of the things that if you've browsed kind of the MCP specs, you might know that we have two different specifications.

  17. 3:07

    There's one that is stable, that is March twenty-sixth, uh, and there's one that is draft that we worked very closely with a bunch of security experts to refine. So for the previous specification, the one that is currently marked as stable, MCP required people that are building MCP servers to essentially spin up their own authorization server.

  18. 3:28

    That means you are building your own token factory. So if you wanna issue, um, tokens to an MCP client to authorize users, you're the one that has to craft those tokens and manage them and refresh them and sign them.

  19. 3:41

    Very complicated. It required people to actually be OAuth experts. Like, if you wanna build an MCP server that does OAuth, you need to understand how Auth works end to end, including to the point of minting those tokens, which is very complicated.

  20. 3:55

    So the draft spec that we worked with Anthropic and a bunch of security experts to refine actually does this clean separation between the server, the MCP server, which we call the resource server, and the authorization server.

  21. 4:07

    So things like token minting and managing token lifetime actually is not done by the MCP server anymore. It's done by whatever authorization server you're using. So if you're using Okta, Auth0, Entra ID, it doesn't really matter.

  22. 4:20

    You can just plug it in into your MCP server, and it's gonna work with the clients that those servers can connect to. And the spec, by the way, is gonna be stable very soon.

  23. 4:28

    Now, I wanna hand it off to Julia to talk about the fact that-

  24. 4:32

    Not every developer wants to be a security expert, right? Like, we've seen the current draft, now the new one that's about to go live into production. But not everyone, we have some exceptions here, um, who do wanna become security experts, who actually wanna focus on building the remote MCP server, right?

  25. 4:50

    You wanna solve a real problem. So this is why the new authorization spec, um, and that's why Den, why a pe- why a bunch of people at Microsoft, we partner- partnered with Anthropic in a security, um, committee to get this new Auth spec out there.

  26. 5:08

    So let's see if I paid attention. What are some of the core things that's gonna change now moving forward? First of all, no need to implement the authorization servers anymore.

  27. 5:18

    So, um, that means we can now just rather than implementing it from scratch, we can actually ex- at- attend it or append it to our server overall. We can use the standard ways.

  28. 5:30

    We only need to reference metadata that are gonna point to our authorization servers, and they are... that's where we're gonna get the token, and then on server side you're gonna have the token, that information here.

  29. 5:41

    And all of this is still gonna continue standard OAuth 2.0, so we can actually, as developers, we can rely on all of the libraries that are already out there, all of the services.

  30. 5:51

    So it's gonna make our lives a lot, a lot of easier. What does this also include on client side? So on client side, they are now, in a way, responsible for the end-to-end token dance.

  31. 6:01

    So this means if the authorization code comes in, um, we can validate it or the client validates, first of all, is the token, has it been, um, acquired successfully?

  32. 6:11

    And then on server, it's gonna pass it through to the server, and on server side, which is still very important, um, you're gonna have to make sure if it's been validated correctly.

  33. 6:21

    Um, and also, of course, on server side we have to implement, um, the metadata, which we, which I previously just talked about. So again, a lot, a lot of, um, yeah, enhancements now moving forward with the new spec.

  34. 6:33

    Saving effort. Saving or sa- saving keystrokes. As developers, they don't need to write a lot of security code because, again, it's ... The risk is higher.

  35. 6:40

    Exactly.

  36. 6:41

    If you're not a security expert and you start implementing security code, what are the chances that you're gonna get it right on the first shot?

  37. 6:46

    100%. And you can start relying on these off-shelf identity providers like Microsoft Entra, Okta, so all of these things, and you, it's just gonna be less work for the developer.

  38. 6:57

    But yeah, how does it work in practice, Dan?

  39. 6:59

    Yeah, so let, let's talk a bit ... We talked about the new spec and the, for folks that might be a little confused, like, what the heck is the new spec and how exactly it works.

  40. 7:05

    So, in a new spec, um, there's a very clear separation of interaction between the MCP client, MCP server, and the authorization server. So, in this case, what happens is your MCP client, like let's say Claude Desktop, is gonna request data from the MCP server.

  41. 7:21

    The MCP server at that point, because the MCP client doesn't have any user context yet, is gonna respond back with a standard HTTP 401 saying, "I have no idea who you are and my server is protected."

  42. 7:32

    But here's a pointer to something that we call the PRM, the Protected Resource Metadata document, that's embedded in one of the headers in WWW-Authenticate, that's gonna say, "But you can go here and learn more about how to authorize against me, the MCP server."

  43. 7:47

    So the MCP client, again, Claude Desktop or VS Code or any other variation, will then talk to the, uh, the, take the PRM, extract from that PRM information about what authorization server it's using, whether it's Okta, Auth0, Entra, Keycloak, it doesn't really matter, and is gonna then ...

  44. 8:06

    I, again, I abstracted this out in a very simplistic way, step four, complete flow, but basically the client is gonna do the whole OAuth discovery step by step, go through the dance, get the token, and then it's gonna request data with a token from the server, and the server's gonna return it back.

  45. 8:21

    The client is responsible for completing this entire OAuth dance where the server now doesn't actually need to manage tokens. You only need to make sure that you're validating them.

  46. 8:31

    I call out th- this thing called the PRM, and the PRM is something hosted by the MCP server that is essentially a JSON document where there's variation. It could be a JSON web token, but for the purpose of this conversation, it's basically a JSON document that says, "Hey, I am this resource.

  47. 8:48

    I am this server. And by the way, my authorization servers are the following." And it can give a list of servers. It can specify things like bear method supported as well as scopes.

  48. 8:58

    So the client, when it gets this document, knows exactly how to bootstrap the end-to-end authorization flow with OAuth against standard OAuth. You can use, again, off-the-shelf libraries for, for doing this.

  49. 9:09

    Uh, let's see it in action in C#, and because we're Microsoft, of course it's gonna be C#. Uh- [laughs] You know. Uh, so, uh, this is currently in a, uh, in a pull request for the C# S- for the official MCP C# SDK, by the way.

  50. 9:25

    Uh, to show you just how easy it is to set up an MCP server that is protected by an OAuth provider, by an identity provider, I have essentially an ASP.NET Core application.

  51. 9:36

    It could work for any other application, but what I'm doing is all I'm configuring is @authentication to make sure that I'm actually adding Auth to my server. I'm saying that it's using the MCP Auth scheme.

  52. 9:48

    I'm adding some validation logic that, again, is built into the framework. Excuse me, we don't see it on the screen. Oh. No. Uh, I see, I see what the problem is.

  53. 9:58

    I s- That's in simple C#. Great call-out. Yeah. [laughs]

  54. 10:02

    See? It's a fantastic demo. I'm gonna duplicate my screen. That's, that's I think what it's gonna do. There we go. All right. So, say it again. Uh, I'm adding authentication.

  55. 10:13

    I'm adding MCP authentication defaults here because it's all baked into the framework. I'm adding some logic to validate the Jot, the token, and this is again, standard embedded into the framework components.

  56. 10:26

    Uh, I have some metadata events that are relevant here, and then I'm saying, @MCP. And within @MCP, I'm saying that I'm adding some PRM metadata that I just talked about, which is my server supporting header Auth.

  57. 10:39

    And because I'm using Entra ID, can be again Okta, Auth0, I'll specify the metadata and that's it. And then I'll say use authentication, use authorization. There's a lot of boilerplate code here because it's an MCP server that uses, again, the, the stock SDK.

  58. 10:53

    But the Auth, that's the complexity. That's all. I needed to add this metadata, and that's kind of it. When I start the server, so it's gonna run locally. Let's take this on.

  59. 11:04

    And what I'm gonna do now is I'm gonna go to the browser here, gonna refresh this, and you'll notice that this is the PRM that I talked about. I have a local host server.

  60. 11:15

    It says my authorization server is login.microsoftonline.com because I'm using Entra ID. Again, it could be any of them. I define the scopes, and I say that it's using header.

  61. 11:25

    That's it. That's what the server says to the client in terms of Auth. Now, I have another instance here that is the client, and the client definition with the C# SDK, again, is super, super simplistic.

  62. 11:36

    What I have here is I'm essentially on the client side say, saying that I'm using a generic OAuth provider. There's nothing Microsoft specific here. It's generic OAuth. I'm specifying the client ID for my MCP client, some scopes, and that's kind of it.

  63. 11:52

    The rest is standard boilerplate for transport setup as you would with any other client. This client is already set up to connect to my test server, my local server, so if I run this

  64. 12:04

    Let's see. Is it gonna connect? It's gonna go ahead and discover the metadata document. It actually went really fast because I'm already authorized here. Perfect demo. Um, but behind the scenes it actually, what it did is it did request the token from Entra ID.

  65. 12:21

    It verified, it sent the token to the server, the server verified it, and then invoked a tool that I had on the MCP server and said that there's no alerts, it's a simple weather example.

  66. 12:30

    It's nothing too complex here. But the end-to-end developer experience here is extremely simple. Like, we worked very, very hard to not expose any of the security intricacies to developers.

  67. 12:40

    You just, that, that's all you do. So C# SDK, it's there. It's, it's in a PR. It's gonna be in production very, very soon. So, uh, Julia, do you wanna talk about VS Code and API Management?

  68. 12:51

    Yeah, totally. So okay, we saw this working locally now. We've used the libraries. So what if you now wanna take it to prod- production? I might be biased because I'm part of the Azure API Management team, but I always recommend putting a gateway in between to make it more secure, and actually use it to protect, um, and

  69. 13:08

    secure your remote MCP servers. Um, so what I'm gonna show you today is, um, for this we have a public available GitHub repository out there. Um, it's gonna help you and it's gonna spin up an example.

  70. 13:21

    Um, and in our example, let's scroll down and go to the overview here, um, we're gonna use Azure API Management in the middle to do and help with, um, authentication.

  71. 13:32

    Um, the beauty about this example is it only uses an ACD up. So we wanted to give developers especially, we've heard a lot of, um, complaints about sometimes it takes some time, so we want it to go super fast.

  72. 13:44

    So with an ACD up, it will spin up all of the resources. So while I'm doing this and everything is gonna be, um, deploying here, let's talk a little bit about what is gonna be set up under the hood and what's gonna help make our remote MCP server, um, more secure.

  73. 14:00

    So as I've mentioned, Azure API Management, Azure Remote MCP Proxy, um, we h- we are hosting it, our remote MCP server on Azure, where we have three tools implemented.

  74. 14:11

    We wanna make sure the connection here is secured, and that's where we're gonna use the gateway in between to help us do the dance. And for this, we have an OAuth API that's gonna help the play between our identity provider, in our case it's Microsoft Entra ID, that's gonna help essentially with the login, and also the consent

  75. 14:31

    flow here to truly make sure that the, um, connection here is secured to our back end, to our remote MCP server, right? All right, so let's see, um, how the deployment of my resources, resources are looking.

  76. 14:45

    I told you it truly only takes maybe five minutes max. Um, it does spin a bunch of other things like, um, an app service plan, log analytics, to make sure that this is truly production ready, and it, um, gives you a way to monitor and also analyze and log it.

  77. 15:02

    So I'm gonna copy my endpoint here. Before I'm gonna do something with it, let's just check on Azure API Management side if all of the things have been implemented correctly.

  78. 15:10

    Because what we should see now in my APIs tab is we should see the re- the endpoint to my remote MCP server, which is the MCP API, and also the endpoint that's gonna help us handle OAuth.

  79. 15:24

    And of course, while the spec evolves, we are also gonna evolve the samples and all of it that comes with it. So let's test it. I'm gonna start MCP Inspector here.

  80. 15:33

    Um, let's open MCP s- um, Inspector, um, and provide the URL endpoint. So once I connect, now what I should see is, um, if I click the Connect button here, this is gonna pop up my consent page, right?

  81. 15:49

    So it's gonna show the application name. It's gonna make sure that I'm providing the right consent. I'm gonna allow access to it. The first time I'm doing it, I also have to, um, provide the right permissions, so I'm gonna, gonna accept this here.

  82. 16:03

    And once I'm back, now you can see I'm actually connected, and now I'm gonna list the tools, and as we talked about it, I currently just have three tools implemented here.

  83. 16:13

    All right. VS Code, how does it work actually now in VS Code, for example? VS Code has MCP support as well. I'm just gonna provide the endpoint, um, I'm gonna find a name for my MCP remote server here, which let's call it AI Engineer, and it's gonna add it to my user settings, and immediately it's gonna start

  84. 16:33

    running it. And you can see now in VS Code, because they now also support OAuth, they're gonna pop up the window. They're gonna show a notification about, "Hey, let's authenticate towards it."

  85. 16:44

    I'm gonna open it, and we're gonna see the same consent page, right? This time with VS Code. Different application name here, where we are again, we're gonna, um, provide our, um, consent.

  86. 16:55

    We're gonna allow it, and now back I'm authorized. I'm a- allowed to use it in VS Code Insider. So once that's done, you saw now I have access to the three tools here in VS Code.

  87. 17:07

    So let's test this. What it's gonna do in Copilot Studio, uh, Co- uh, GitHub Copilot. Um, so first I'm gonna select and see. Perfect. It's, um, it was able to select my tools, and it's g- um, able to detect these.

  88. 17:22

    And now once I start interacting, I s- I have my text prompt here, and just kind of do the Hello Worlds, um, very simple example. Um, GitHub Copilot is now gonna run it.

  89. 17:34

    It's gonna detect the tool. Because I've been, am authenticated, it's gonna run it, um, hopefully successfully. Perfect. And now we can also double-check. So if I open the tool calling here, I can see that the output of, "Hello, I'm an MCP tool," has been successfully, um, provided.

  90. 17:52

    Um, something new, and I know the world is spinning very, very fast, so... As being part of Azure API Management, we wanna make it easier as well. So we know the similarities between MCP servers and APIs, so one of the latest announcements that we have done is you can now also start transforming your REST APIs into remote

  91. 18:14

    MCP servers using our tools, u- using our, um, platform here. And you can configure your already existing endpoint, REST endpoints, into tools that you want to expose to get, like, um, the VS Code.

  92. 18:29

    Um, and we're gonna do this all with our platform because we wanna make it easier for enterprise customers, but also developers, to get started with this. So here in my use case, um, I just copied the endpoint that was provided by me, um, by API Management.

  93. 18:43

    I'm gonna hit Start and Running. Um, of course, always make sure to implement auth, and that's the beauty about our platform. You can use it for securing it, um, but also for hosting in this case.

  94. 18:55

    And now I'm able to also just immediately call it. Um, let's just check if, um, GitHub Copilot was able to detect the MCP server here. Perfect. You can see it right under my Service AI Engineering one.

  95. 19:08

    I'm seeing the three tools. That is all based on my REST API in VS Code, and now I'm ready to go and interact with it, um, in VS Code right here.

  96. 19:20

    With this being said-

  97. 19:22

    Yeah

  98. 19:22

    ... um, lots of things are changing in this space. Any, um, good words for the people out there-

  99. 19:28

    Yeah

  100. 19:28

    ... who wanna get started with remote MCP server then?

  101. 19:30

    Yeah. So, uh, there's links on the screen that you can go to. These are the specification documents, uh, that you can learn more about how MCP auth works. We also have a document that we partnered with Anthropic on.

  102. 19:40

    It's called Security Best Practices that outline what are the best practices that you should be adopting in your MCP servers, so you wanna make sure that you're not pwned.

  103. 19:48

    Uh, very, very important. And then I'll also mention that, uh, starting with VS Code Insiders, we do support the new authorization spec. So you should check it out, download it, install it, give us your feedback, and if anything doesn't work, we have Harold at this conference who can help you debug it.

  104. 20:03

    So thank you, folks.

  105. 20:04

    Yeah.

  106. 20:04

    This was great.

  107. 20:04

    Stop by at the booth. [audience applauding]

  108. 20:06

    Yeah. [upbeat music]