Connecting an MCP Server to Microsoft Foundry Agent Service
Part 9 of Taiseer Joudeh's MCP series shows how to attach an existing ASP.NET Core MCP server to a hosted Foundry agent without changing its code. The setup covers a Foundry project, an Entra app registration, a custom MCP connection using OAuth identity passthrough, and a toolbox. It matters for .NET teams that want the agent loop in Azure while user-based authorization still works.
Key points
- Foundry Agent Service only needs a public remote MCP endpoint; the Part 8 server works unchanged.
- Assign Foundry User and Foundry Project Manager at the project scope, not the account or resource group.
- Use a separate web-type Entra app registration for Foundry and add the redirect URI generated by the connection.
- Make the scope fully qualified: the Application ID URI followed by /Expenses.Access, with offline_access separated by a space.
- When patching the Entra api object, send the whole object, because a PATCH replaces properties and can remove existing scopes.
- Publish one MCP configuration to several agents through a Foundry toolbox instead of repeating it in each agent.
The ninth part of Taiseer Joudeh's series on building MCP servers in .NET moves the agent loop into Azure. Instead of a console app, VS Code or Claude driving the conversation, a Foundry Agent Service agent calls the MCP server directly. The server itself stays as it was in Part 8: no new package, endpoint or code, only Azure configuration and a small console application.
Identity is the real problem. A hosted agent has no person in front of it, yet the expense approval tool relies on the caller's token to identify the user. The fix is OAuth identity passthrough: a user signs in once, and Foundry stores the credential against the connection. The guide creates a Foundry project in the existing account, assigns the Foundry User and Foundry Project Manager roles at project scope, and registers a separate web-type Entra app for Foundry. It then introduces toolboxes, which share one MCP configuration across several agents.
Real-world use
- A company running several Foundry agents that all call the same expense API and need per-user authorization.
- An internal assistant in Azure that calls a line-of-business MCP server while enforcing the signed-in employee's permissions.
- A platform team that wants to rotate MCP credentials in one place instead of in every agent configuration.
Why it matters
If your MCP tools make decisions based on the caller's identity, hosted Foundry agents need OAuth identity passthrough rather than a managed identity, or those checks will fail. The server code itself does not need to change.