The Model Context Protocol (MCP) enables seamless integration between AI applications and external data sources. When working with MCP servers in C#, you'll often need to pass parameters to configure server connections, specify endpoints, or provide authentication details. This post walks you through the practical approaches to handling URL parameters when connecting to MCP servers.
Understanding MCP transport mechanisms
Before diving into configuration, it's crucial to understand the two primary ways MCP servers communicate, as this fundamentally impacts how you pass parameters.
- STDIO Transport involves running the MCP server as a child process that communicates through standard input/output streams. Your MCP client launches the server (typically a Node.js script or executable) and exchanges messages via stdin/stdout. This is the most common approach for local development and desktop applications.
- Hosted MCP Servers run as independent web services that expose Server-Sent Events (SSE) or HTTP streaming endpoints. Your MCP client connects to these servers over HTTP/HTTPS as a client, similar to consuming any web API.
The transport mechanism dramatically affects how you pass configuration:
| Aspect | STDIO Transport | Hosted Server (SSE/HTTP) |
|---|---|---|
| Connection Method | Launch process locally | Connect to remote URL |
| Parameter Passing | Environment variables, command-line args | URL, query parameters, headers, request body |
| Lifecycle | Managed by your application | Independent service |
| Authentication | Usually not needed (local) | API keys, OAuth tokens, headers |
| Configuration Location | Process startup | HTTP request/connection |
This means that for an MCP server using STDIO transport, passing configuration data is simple:
When using a hosted MCP server, you need to fallback to the standard API mechanisms like headers, query parameters or the root URL:
Extract parameters in your C# based MCP server
Let’s focus on a concrete example. We created our own internal MCP server to interact with our on-prem Azure DevOps instance(what immediately explains why we aren’t using the MCP server provided by Microsoft).
This MCP server can be scoped to a specific project and optionally to a specific team, so 2 parameters are expected. We decided to include this information as part of the URL.
This means that the MCP URL configured in the client looks like this:
https://development/devopsmcpserver/<ProjectName>/
Or if we want to further scope to a specific team:
https://development/devopsmcpserver/<ProjectName>/<TeamName>/
Let me walk you through the steps how we got this working inside our MCP server.
First we updated the routing so that the MCP server is listening to the right location:
Now we need a way to extract the parameters from the URL. We tried different ways but ultimately landed on using the IHttpContextAccessor to fetch the information directly from the HttpContext:
We created a ProjectContext abstraction that allows to fetch the projectname and teamname from the HttpContext (with a fallback to a local config file for testing purposes):
You can easily adapt this approach if you want to fetch the information from a query string parameter or an HTTP header.
Now we can register multiple MCP servers each using a different project and teamname:
Best practices
When passing parameters to MCP servers, follow these guidelines:
Security: Never hardcode sensitive information like API keys or passwords. Use secure configuration management systems like Azure Key Vault, AWS Secrets Manager, or environment variables.
URL Encoding: Always properly encode URL parameters to handle special characters.
Validation: Validate all parameters to catch configuration errors early.
Error Handling: Implement robust error handling for connection failures and invalid parameter scenarios.
Documentation: Document which parameters your MCP server expects and their acceptable values.