DotNetCode, part 7: One MCP tool library, three hosts — WebApi, Azure Function, and .NET Framework 4.8
The Model Context Protocol (MCP) is the open standard that lets AI assistants call your tools — a JSON-RPC protocol with transports for different environments. The Mcp folder of DotNetCode is the best study of the protocol's shape I know, because it exposes the same tools from three different hosts sharing one library.
The three hosts
| Host | Transport | Notes |
|---|---|---|
| .NET 10 Web API | Streamable HTTP | The modern default; MapMcp wiring over HTTP |
| .NET 10 Azure Function | MCP extension webhook | [McpToolTrigger] attributes become tools; no hub class needed |
| .NET Framework 4.8 console | stdio | How desktop AI clients launch local tools — the classic MCP stdio host |
What the tools do
Two generic capabilities — get_status (GET a resource from a downstream API)
and send_update (POST a JSON payload to it) — implemented once in the shared
McpServerLibrary behind IGenericApiClient, with credentials resolved
through an IKeyVaultCredentialProvider backed by Azure Key Vault and
DefaultAzureCredential. Constructor injection puts the same implementation inside
every host.
The multi-targeting lesson, revisited
This is the one folder where part
1's four-framework rule bends: the library targets net48;net8.0;net10.0
because the MCP SDK 2.x dependency chain requires .NET 8+, and its netstandard2.0
asset is what the .NET Framework 4.8 stdio host consumes. Real repositories have exactly this
kind of nuance — the README documents it instead of hiding it.
Try it
Each host folder has its own README with a copy-settings-then-run path (local settings
sample, az login for the credential chain, then run; the Function exposes
/runtime/webhooks/mcp locally). Point any MCP client at the endpoint and list
tools — seeing your own HTTP API appear as an AI-callable tool is the moment the protocol
clicks.
Repository: github.com/bobhuang1/DotNetCode/tree/master/Mcp