Azure DevOps Remote MCP tool is not invoked after publishing Microsoft Foundry agent to Teams/Microsoft 365

Whatever Jerald told above is true and that is same response I got from my support ticket, however I am able to make it work by adding project managed identity and setting the audience for the same as https://ai.azure.com/.default

Read this article if you would want to do this without the toolbox https://learn.microsoft.com/en-us/azure/devops/mcp-server/remote-mcp-server-troubleshooting?view=azure-devops&utm_source=chatgpt.com and you would need to add azure devops mcp as your application. For me the toolbox route worked.

Hello csensoft,

Greetings! Thanks for raising this question in the Q&A forum.

What you are seeing is expected behavior with the current state of Microsoft Foundry agent publishing, not a misconfiguration on your side. It comes down to two related platform facts.

First, Foundry Playground and the Preview Web App invoke your agent through the Responses API protocol. When you publish the agent to Teams or Microsoft 365, the publishing flow switches the Agent Application to the Activity Protocol, which runs through Azure Bot Service with Channels authentication instead. MCP tool invocation that relies on identity based auth, including Project Managed Identity, currently has limited support once the agent is running under the Activity Protocol path. Several other threads report the same pattern, where the agent responds and lists the tool but never actually triggers the MCP call once published, while the identical configuration works fine in Playground.

Second, publishing an agent to Teams/M365 creates a separate Agent Application resource with its own Entra ID, distinct from the Foundry project identity that Playground uses. Permissions and identity configuration you set on the project, including the Project Managed Identity used for the Azure DevOps MCP tool, do not carry over to this new published identity. That is why you see a second service principal appear in the M365 admin portal, and why Azure DevOps rejects it when you try to add it manually. VS403283: Could not add user generated by publish occurs because that identity is an automatically generated Agent Application identity, and Azure DevOps blocks it from being added directly as a user through the normal add-user flow.

Confirm this is the protocol switch, not a config error. In Foundry tracing, check whether the published agent is invoking through the Activity Protocol. If so, this matches the current documented behavior for Teams/M365 published agents, and no change to your MCP tool configuration will fix it, since the limitation is in how the published runtime invokes MCP tools rather than in your setup.

Do not try to grant Azure DevOps access to the generated publish identity. Since Azure DevOps explicitly blocks adding it, this is not the supported path today, and pursuing it further will not restore the MCP invocation.

If your scenario requires MCP tool calls with identity based auth, keep the agent on the Responses API protocol rather than publishing it as a Teams/M365 Agent Application. You can still expose it to users by invoking the Agent Application endpoint through the Responses API protocol from your own front end, which preserves the Project Managed Identity / OAuth passthrough behavior that works in Playground.

Track this as a product limitation rather than something to keep troubleshooting locally. Multiple recent reports describe MCP tools listed but never invoked after publishing to Teams/M365, and Microsoft has acknowledged this as a current platform gap for MCP support parity between Playground and Teams/M365 channels.

Open an Azure Support ticket referencing this behavior so it gets tracked against the known limitation, and include the following in the ticket: the agent/application identifiers for both the pre-publish and post-publish service principals, the Foundry tracing output showing MCP invocation in Playground versus its absence after publish, and the exact VS403283 error text. This gives support a concrete repro to escalate to the Foundry agent applications team.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.