Foundry ADO MCP tools connection (with Custom OAuth identity).

Question

Foundry ADO MCP tools connection (with Custom OAuth identity).

Rajender Akula 55 Microsoft Employee

Hi Team,

User's image

I am wondering if this "Custom" option is available today in foundry to connect to ADO MCP. Because, when I give the details and save the connection for "Custom". It just defaults to the "Managed" option back.

Can someone let me know if this is something intended for future usage or some known issue with foundry?

Thanks,
Rajender

Anshika Varshney 15,625 Reputation points Microsoft External Staff Moderator

2026-05-22T04:52:23.8133333+00:00

Hi @Rajender Akula

Thanks for your question. This scenario with ADO MCP tools and custom OAuth can be a bit tricky, so let me explain it in a simple way.

First, about authentication options in Foundry Azure Foundry supports multiple authentication methods for MCP tools such as key based, Microsoft Entra ID, and OAuth. When using OAuth, it is typically configured as identity passthrough where each user authenticates with their own account.

Now coming to your issue with custom OAuth and ADO MCP tools

The main challenge usually comes from how Foundry handles tool discovery and authentication.

Important behavior to understand When you connect an MCP server, Foundry first calls the tools list operation to discover available tools. This happens before any user interaction.

In case of OAuth OAuth tokens are user based and are only available after a user starts interacting with the agent. So during initial tool discovery, no token is available yet.

This can lead to the following problem If your MCP server expects a valid OAuth token for all requests, it may reject the tools discovery call. As a result, Foundry may show no tools or connection issues even though your OAuth setup looks correct. [linkedin.com]

This is a common reason why custom OAuth works in testing tools like Postman but not in Foundry agent scenarios.

What you can check

Make sure your MCP server allows tool discovery without strict OAuth validation The tools list call should ideally not require a user token, otherwise Foundry cannot discover the tools.

Separate discovery and execution logic Allow tools list without authentication or with relaxed validation Enforce OAuth only during actual tool execution

Try alternative authentication if possible Microsoft Entra authentication is recommended when supported because it avoids token handling issues and works better with Foundry identity model. [learn.microsoft.com]

Also validate ADO side configuration Check if your Azure DevOps MCP server supports the selected OAuth flow in your environment Some environments like headless or remote setups may not handle interactive OAuth properly

In simple terms Your OAuth setup might be correct But the issue usually comes from timing and how Foundry performs tool discovery before user authentication

This is why tools may not appear or connection seems to fail.

In short: Custom OAuth is supported But you need to ensure your MCP server supports unauthenticated discovery and authenticated execution

I hope this helps clarify the behavior. Do let me know if you have any further queries.

Thankyou!
Anshika Varshney 15,625 Reputation points Microsoft External Staff Moderator

2026-05-25T17:27:35.1333333+00:00

Hi @Rajender Akula

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

Thankyou!
Rajender Akula 55 Reputation points Microsoft Employee

2026-05-26T02:53:05.56+00:00

Thanks for your followup, yes the given response is helpful.

I am reading https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/mcp-authentication
Here it mentions for Custom Auth, it expects the client secret right along with app id? I believe using secrets is not a recommended approach for any resources.
Is there any other way of getting around this Custom OAuth thing?
Anshika Varshney 15,625 Reputation points Microsoft External Staff Moderator

2026-05-26T10:54:06.3266667+00:00
Hi,

You’re right, using secrets directly is not recommended if not handled properly.

For Custom OAuth, a credential is required, so it expects either a client secret or certificate. Instead of plain secrets, the recommended approach is to store it securely (like Azure Key Vault).

If you want to avoid secrets:

You can use certificate-based authentication (more secure than secrets)

Or Managed Identity, but that depends on whether the MCP integration supports it for your scenario

So currently, there isn’t a way to bypass credentials entirely for Custom OAuth, but you can use more secure alternatives.

Hope this helps. If these steps resolve your issue, please confirm.

Thankyou!
Anshika Varshney 15,625 Reputation points Microsoft External Staff Moderator

2026-05-27T16:02:17.57+00:00

Hi @Rajender Akula

Please let me know if there are any remaining questions or additional details, I can help with, I’ll be glad to provide further clarification or guidance.

Thankyou!
Rajender Akula 55 Reputation points Microsoft Employee

2026-05-28T03:01:18.0166667+00:00

Thanks for your followup, I can see you are suggesting to use MI or certificate instead of using secrets.
But on Foundry UI, I see only option to mention Client ID and Secret for Tool connectivity option.
So, for other options do I have to do it through the code and deploy as hosted agents?
Anshika Varshney 15,625 Reputation points Microsoft External Staff Moderator

2026-05-28T12:29:38.28+00:00
Hi @Rajender Akula

Yes, you are correct, in the current Foundry UI, the tool connectivity option primarily supports Client ID and Secret for authentication, and other authentication methods like Managed Identity (MI) or certificate-based authentication are not directly exposed through the UI.

To use more secure options such as Managed Identity or certificate-based authentication, you would need to implement this through code and configure it as part of a hosted agent or custom integration. This approach allows you to handle authentication outside of the UI and use more secure credential mechanisms.

UI-based tool integration → supports Client ID + Secret

Managed Identity / certificate-based authentication → requires code-based implementation (for example, via hosted agents or custom services)

Let me know if you need any guidance or confirm whether it's alright to close this thread?

Thankyou!
Rajender Akula 55 Reputation points Microsoft Employee

2026-05-29T14:38:45.2566667+00:00

Thanks for the details, Anshika,
I spoke to ADO MCP team and they are enabling on Foundry UI to use the Managed Identity using "Project Managed Identity".
I believe On Foundry it has Authentication mechanisms enabled is limited for ADO MCP today. So, sometime next week we can see that option on Foundry UI.

Thanks for all the info you have provided, this doc is helpful to learn on Authentication mechanisms https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/mcp-authentication.

Answer accepted by question author

Anshika Varshney 15,625 Microsoft External Staff Moderator

Hello @Rajender Akula

You're very welcome! I'm glad the information was helpful. Thank you for the update and for reaching out to the ADO MCP team.

Aspect	Current Status	Upcoming Feature
Authentication Method	Limited to Custom OAuth identity today	Project Managed Identity will be available
--------	--------	--------
Authentication Method	Limited to Custom OAuth identity today	Project Managed Identity will be available
Availability	Currently restricted	Expected next week in Foundry UI
Location	Foundry UI	Project Managed Identity option in Foundry UI

You'll soon be able to connect Foundry ADO MCP tools using Managed Identity instead of Custom OAuth identity passthrough, which is:

More secure (no need to manage OAuth credentials)
Simpler to configure
Native Azure integration

Helpful Documentation:

The documentation you shared is indeed valuable for understanding authentication mechanisms: MCP server authentication - Azure AI Foundry[learn.microsoft]

Since you now have confirmation from the ADO MCP team and know the feature is coming next week, please consider marking this question as answered/resolved by accepting this answer. This will help others facing the same issue find the solution faster.

If you encounter any issues when the Project Managed Identity option becomes available next week, feel free to comment here and I'll be happy to help further.

Thank you for following up with the team and sharing this update it's very helpful for the community!

0 comments

1 additional answer

Your answer

Anshika Varshney 15,625 Reputation points Microsoft External Staff Moderator

2026-05-25T17:27:35.1333333+00:00

Hi @Rajender Akula

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

Thankyou!
Rajender Akula 55 Reputation points Microsoft Employee

2026-05-26T02:53:05.56+00:00

Thanks for your followup, yes the given response is helpful.

I am reading https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/mcp-authentication
Here it mentions for Custom Auth, it expects the client secret right along with app id? I believe using secrets is not a recommended approach for any resources.
Is there any other way of getting around this Custom OAuth thing?
Anshika Varshney 15,625 Reputation points Microsoft External Staff Moderator

2026-05-26T10:54:06.3266667+00:00

Hi,

You’re right, using secrets directly is not recommended if not handled properly.

For Custom OAuth, a credential is required, so it expects either a client secret or certificate. Instead of plain secrets, the recommended approach is to store it securely (like Azure Key Vault).

If you want to avoid secrets:

You can use certificate-based authentication (more secure than secrets)

Or Managed Identity, but that depends on whether the MCP integration supports it for your scenario

So currently, there isn’t a way to bypass credentials entirely for Custom OAuth, but you can use more secure alternatives.

Hope this helps. If these steps resolve your issue, please confirm.

Thankyou!
Anshika Varshney 15,625 Reputation points Microsoft External Staff Moderator

2026-05-27T16:02:17.57+00:00

Hi @Rajender Akula

Please let me know if there are any remaining questions or additional details, I can help with, I’ll be glad to provide further clarification or guidance.

Thankyou!
Rajender Akula 55 Reputation points Microsoft Employee

2026-05-28T03:01:18.0166667+00:00

Thanks for your followup, I can see you are suggesting to use MI or certificate instead of using secrets.
But on Foundry UI, I see only option to mention Client ID and Secret for Tool connectivity option.
So, for other options do I have to do it through the code and deploy as hosted agents?
Anshika Varshney 15,625 Reputation points Microsoft External Staff Moderator

2026-05-28T12:29:38.28+00:00

Hi @Rajender Akula

Yes, you are correct, in the current Foundry UI, the tool connectivity option primarily supports Client ID and Secret for authentication, and other authentication methods like Managed Identity (MI) or certificate-based authentication are not directly exposed through the UI.

To use more secure options such as Managed Identity or certificate-based authentication, you would need to implement this through code and configure it as part of a hosted agent or custom integration. This approach allows you to handle authentication outside of the UI and use more secure credential mechanisms.

UI-based tool integration → supports Client ID + Secret

Managed Identity / certificate-based authentication → requires code-based implementation (for example, via hosted agents or custom services)

Let me know if you need any guidance or confirm whether it's alright to close this thread?

Thankyou!
Rajender Akula 55 Reputation points Microsoft Employee

2026-05-29T14:38:45.2566667+00:00

Thanks for the details, Anshika,
I spoke to ADO MCP team and they are enabling on Foundry UI to use the Managed Identity using "Project Managed Identity".
I believe On Foundry it has Authentication mechanisms enabled is limited for ADO MCP today. So, sometime next week we can see that option on Foundry UI.

Thanks for all the info you have provided, this doc is helpful to learn on Authentication mechanisms https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/mcp-authentication.

Answer 1

The Custom OAuth option is supported for MCP tools in Microsoft Foundry, including when connecting MCP servers with OAuth identity passthrough. Custom OAuth is used when bringing an app registration instead of relying on a Microsoft-managed OAuth app.

For MCP tools in general, the documented flow is:

In Foundry, go to Tools and connect the MCP server.
Choose OAuth identity passthrough for Authentication.
Select Custom OAuth and provide:
- Client ID (app registration ID)
- Client secret (if required)
- Authorization URL
- Token URL
- Refresh URL (or reuse the token URL)
- Scopes
Save the connection; Foundry then returns a redirect URL that must be added to the Microsoft Entra app registration.

This pattern is explicitly supported for:

Microsoft MCP Server for Enterprise, where the guidance is to select Custom as the OAuth provider and supply the app registration details.
Custom MCP servers, where OAuth identity passthrough (OBO) with custom OAuth parameters is the documented option.

If the UI reverts from Custom back to Managed after saving, that behavior is not described as expected in the documentation and is likely a product issue rather than by design. Given that Custom OAuth is a supported configuration path, the connection should persist as Custom once all required fields are valid.

Recommended next steps:

Verify all required Custom OAuth fields are populated exactly as required (Client ID, Token URL, Auth URL, Refresh URL, and any required scopes). Incomplete or invalid values can prevent saving.
If the configuration is valid but the selection still flips back to Managed, treat this as a Foundry UI or service bug and raise a support ticket so the product group can investigate.

References: