This example demonstrates how to use tools from a protected Model Context Protocol server with Agent Framework.
MCP is an open protocol that standardizes how applications provide context to LLMs.
For information on Model Context Protocol (MCP) please refer to the documentation.
The sample shows:
- How to connect to a protected MCP Server using OAuth 2.0 authentication
- How to implement a custom OAuth authorization flow with browser-based authentication
- Retrieve the list of tools the MCP Server makes available
- Convert the MCP tools to
AIFunction's so they can be added to an agent - Invoke the tools from an agent using function calling
- A self-signed certificate to enable HTTPS use in development, see dotnet dev-certs
- .NET 10.0 or later
- A running TestOAuthServer (for OAuth authentication), see Start the Test OAuth Server
- A running ProtectedMCPServer (for MCP services), see Start the Protected MCP Server
Set the following environment variables:
$env:AZURE_OPENAI_ENDPOINT="https://your-resource.openai.azure.com/" # Replace with your Azure OpenAI resource endpoint
$env:AZURE_OPENAI_DEPLOYMENT_NAME="gpt-5.4-mini" # Optional, defaults to gpt-5.4-miniFirst, you need to start the TestOAuthServer which provides OAuth authentication:
cd <MCP CSHARP-SDK>\tests\ModelContextProtocol.TestOAuthServer
dotnet run --framework net10.0The OAuth server will start at https://localhost:7029
Next, start the ProtectedMCPServer which provides the weather tools:
cd <MCP CSHARP-SDK>\samples\ProtectedMCPServer
dotnet runThe protected server will start at http://localhost:7071
Finally, run this client:
dotnet run- The client attempts to connect to the protected MCP server at
http://localhost:7071 - The server responds with OAuth metadata indicating authentication is required
- The client initiates OAuth 2.0 authorization code flow:
- Opens a browser to the authorization URL at the OAuth server
- Starts a local HTTP listener on
http://localhost:1179/callbackto receive the authorization code - Exchanges the authorization code for an access token
- The client uses the access token to authenticate with the MCP server
- The client lists available tools and calls the
GetAlertstool for New York state
The following diagram outlines an example OAuth flow:
sequenceDiagram
participant Client as Client
participant Server as MCP Server (Resource Server)
participant AuthServer as Authorization Server
Client->>Server: MCP request without access token
Server-->>Client: HTTP 401 Unauthorized with WWW-Authenticate header
Note over Client: Analyze and delegate tasks
Client->>Server: GET /.well-known/oauth-protected-resource
Server-->>Client: Resource metadata with authorization server URL
Note over Client: Validate RS metadata, build AS metadata URL
Client->>AuthServer: GET /.well-known/oauth-authorization-server
AuthServer-->>Client: Authorization server metadata
Note over Client,AuthServer: OAuth 2.0 authorization flow happens here
Client->>AuthServer: Token request
AuthServer-->>Client: Access token
Client->>Server: MCP request with access token
Server-->>Client: MCP response
Note over Client,Server: MCP communication continues with valid token
The client is configured with:
- Client ID:
demo-client - Client Secret:
demo-secret - Redirect URI:
http://localhost:1179/callback - OAuth Server:
https://localhost:7029 - Protected Resource:
http://localhost:7071
Once authenticated, the client can access weather tools including:
- GetAlerts: Get weather alerts for a US state
- GetForecast: Get weather forecast for a location (latitude/longitude)
- Ensure the ASP.NET Core dev certificate is trusted.
dotnet dev-certs https --clean dotnet dev-certs https --trust - Ensure all three services are running in the correct order
- Check that ports 7029, 7071, and 1179 are available
- If the browser doesn't open automatically, copy the authorization URL from the console and open it manually
- Make sure to allow the OAuth server's self-signed certificate in your browser