Share via

Foundry MCP tool with OAuth Identity Passthrough fails to call MCP tool after auth

John Neubecker 86 Reputation points
2026-03-12T15:10:14.9866667+00:00

I've been trying to get oauth identity passthrough working in my foundry agent following https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/mcp-authentication?view=foundry#oauth-identity-passthrough.

I am using the foundry agent playground chat for testing.

My setup is a foundry agent with a single mcp tool with oauth consent enabled. The mcp tool is an azure function app I have deployed. The oauth provider is Okta.

I've tried this with a few different models gpt 4.1, gpt 4.1 mini, gpt-5 and none work. Is there a specific set of models oauth identity passthrough was tested with and works with?

Without oauth identity passthrough configured everything works.

With oauth identity passthrough configured when I ask a question that invokes the tool I see the consent link, then after going through consent I see the consent link again, then after following it a second time that agent hallucinates the tool invocation and returns a made up result without invoking the tool.

Here's an example response using gpt 5.2. It knows about the tool because it shows me the consent link but it seems like it loses sight of it after consenting.

After some more debugging I can see that the first response output includes a McpListTools section that references the correct mcp server and server but the tools list in the output is empty. This might be start of the issue. I don't know why the tools list is empty when oauth identity passthrough is configured.

Sign in to mcp_poc in order to allow the AI agent use mcp_poc MCP tool. If you are using a Third-Party Tool, it is a Non-Microsoft Product. Use at your own risk and subject to third-party terms and data handling practices.
Sign in successful

Sign in to mcp_poc in order to allow the AI agent use mcp_poc MCP tool. If you are using a Third-Party Tool, it is a Non-Microsoft Product. Use at your own risk and subject to third-party terms and data handling practices.
Sign in successful

I can’t actually call MCP/tools from this chat or display a real tool response. I also don’t have any MCP server details (tool name, endpoint, auth) to invoke.
If you tell me the MCP tool name and the request you want to make (inputs/args), I can format the exact call you’d run and show a
Foundry Tools
Foundry Tools

Formerly known as Azure AI Services or Azure Cognitive Services is a unified collection of prebuilt AI capabilities within the Microsoft Foundry platform

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Karnam Venkata Rajeswari 565 Reputation points Microsoft External Staff Moderator
    2026-03-25T15:37:26.59+00:00

    Hello John Neubecker,

    Welcome to Microsoft Q&A and Thank you for reaching out.

    Based on the behavior described, this does not appear to be related to the model in use. OAuth identity passthrough is handled by the Foundry Agent Service layer and is model agnostic. Consistent behavior across GPT-4.1, GPT-4.1 mini, and GPT-5 variants indicates that model compatibility is not the root cause.

    In the Foundry Agent Playground, the OAuth consent continuation flow is handled automatically by the platform. After consent is completed, the agent is expected to rediscover the MCP server tools and invoke them using the authenticated user context.

    The key indicator in the scenario is that the MCP server is discovered, but the tools array is empty after authentication. This suggests that tool discovery is not completing successfully under the authenticated context.

    This also explains the remaining behavior:

    • Repeated consent prompts indicate that the authenticated session is not being retained or applied correctly
    • An empty tools list preventing tool invocation
    • The agent falls back to a language-only response when no callable tools are available

    Given that the same MCP tool works correctly when OAuth identity passthrough is disabled, this points to an issue with authentication propagation rather than the MCP tool itself. Common causes include the access token not being applied to MCP requests after consent, token validation failing at the MCP endpoint, or required scopes not being present in the OAuth configuration.

    At this stage, please:

    • Confirm that the MCP endpoint is receiving the Authorization header after consent
    • Verify that the token includes the expected audience and scopes
    • Review MCP server logs for authorization or discovery-time failures

    References:

    Connect to MCP Server Endpoints for agents - Microsoft Foundry | Microsoft Learn

     

    Thank you!

     

    Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.

    0 comments
  2. John Neubecker 86 Reputation points
    2026-03-13T19:50:40.03+00:00

    The reason this was happening is because the access policy I have on the auth server required certain scopes to be requested. After adding one of the scopes to the oauth identity passthrough config it works. So the "sign in successful" message was very misleading.

    0 comments
  3. Q&A Assist
    2026-03-12T15:10:37.2433333+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    OAuth identity passthrough requires a specific multi-step flow and configuration. The behavior described (seeing the consent link twice and then no real tool invocation) usually indicates that the consent flow isn’t being completed correctly from the agent side, or that the MCP connection isn’t fully configured/validated.

    Use the following checklist and flow to correct the setup:

    1. Verify OAuth identity passthrough configuration

    For a custom MCP server (such as an Azure Functions app):

    • Ensure the MCP tool in Foundry is configured with Authentication = OAuth Identity Passthrough.
    • For a Functions-hosted MCP server with built-in auth, use a Microsoft Entra app registration and configure:
      • Client ID: Application (client) ID of the Entra app.
      • Token URL: https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token
      • Auth URL: https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/authorize
      • Refresh URL: same as token URL.
      • Scopes: the Application ID URI or API scope of the Entra app (for Functions, typically api://<client-id> or the scope copied from Expose an API).
    • After saving the MCP tool configuration, copy the Redirect URL that Foundry gives and add it as a Web redirect URI in the Entra app under Authentication.

    If the redirect URI isn’t added to the Entra app, the consent flow can’t complete correctly and the agent will keep asking for consent.

    1. Confirm the consent flow is handled correctly in the agent

    The OAuth identity passthrough flow is per user, per tool, per project:

    1. First tool invocation:
      • The agent response includes an oauth_consent_request item in response.output_item with a consent_link.
      • The client UI must surface this link and the user must complete sign-in and consent.
    2. After the user closes the consent dialog:
      • The client must send another request to the agent using the previous response ID.
      • Only after this second request should the agent actually call the MCP tool with the user’s token.

    If the second request isn’t sent with the previous response ID, the agent will not have a completed consent state and may:

    • Re-issue the consent link (what is being observed), or
    • Fall back to answering from the model only, which appears as hallucinating the tool call.

    Ensure the client or integration that hosts the agent:

    • Detects oauth_consent_request in the response.
    • Waits for the user to complete consent.
    • Then calls the agent again with the previous response ID so the tool call can proceed.
    1. Validate the connection after fixing configuration

    After updating configuration and client handling:

    1. Trigger the MCP tool from the agent with a prompt that should use the tool.
    2. Confirm:
      • A new user gets a consent link once.
      • After consent and the follow-up request, the tool is actually invoked and its output appears in the agent response (no auth errors, no repeated consent link).
    3. Test with another user to verify that each new user is prompted once and subsequent calls work without further consent prompts.
    4. Additional checks specific to Azure Functions MCP server

    For a Functions-hosted MCP server using OAuth identity:

    • From the Function App in Azure portal, under Settings > Authentication, open the linked Entra app and copy:
      • Application (client) ID
      • Directory (tenant) ID
      • Application ID URI
    • Use the tenant ID to construct the Auth/Token/Refresh URLs as above.
    • Under Expose an API, copy the existing scope and use it as the scope in the Foundry MCP tool configuration.
    • After Foundry returns the redirect URL, add it as a redirect URI in the Entra app and save.

    Once these are in place and the client correctly performs the “second call with previous response ID” after consent, the tool should be invoked with the user’s identity instead of the agent hallucinating a result.

    References:

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.