How to fix Connected Agent fails to invoke connected agent with MCP server in Azure AI Foundry?

Question

How to fix Connected Agent fails to invoke connected agent with MCP server in Azure AI Foundry?

Robin Ganpat 0

Bug description

I have two agents deployed in Azure AI Foundry (Switzerland North), both using a shared GPT-4.1 model deployment:

Agent 1: apples-agent Has an MCP server configured The MCP server exposes one tool: returns the number of apples in my basket Works correctly when invoked directly - returns expected results

Agent 2: orchestrator-agent Has the apples-agent configured as a Connected Agent Instruction: "Use the apples-agent when the user wants to know the amount of apples in the basket" Intended to act as an orchestrator that delegates tasks to other agents

The Problem

When I ask the orchestrator-agent "How many apples are in my basket?", the request consistently times out after 60+ seconds and fails, both in the Azure AI Foundry Agents Playground and when using the .NET SDK. However, when I ask the apples-agent directly the same question, it works perfectly and returns the correct result immediately using its MCP server. The issue only occurs when trying to invoke the apples-agent through the orchestrator-agent via the Connected Agents feature.

Expected behavior

When a user asks the orchestrator-agent about the number of apples in the basket:

The orchestrator-agent should recognize the query matches its instruction to delegate to apples-agent
The orchestrator-agent should successfully invoke the apples-agent
The apples-agent should use its MCP server to call the tool and retrieve the apple count
The result should be returned through the orchestrator-agent to the user
Total response time should be reasonable (under 10-15 seconds)

Actual behavior

In Azure AI Foundry Playground:

Query is sent to orchestrator-agent
UI displays "Looking for references using..." message
Request hangs for 60+ seconds
Eventually displays error message: "Error: There was a problem with the request. Please try again."
No result is returned

Using .NET SDK (Azure.AI.Agents.Persistent 1.2.0-beta.5):

Request times out after 60+ seconds
Response indicates inability to connect to the apples-agent
Error suggests connection or invocation failure

Direct invocation (baseline for comparison):

Querying apples-agent directly returns correct results immediately
MCP server tool invocation works as expected

Reproduction Steps

Setup:

Deploy GPT-4.1 model in Azure AI Foundry (Switzerland North)
Create Agent 1 (apples-agent):
- Configure with GPT-4.1 model
- Add MCP server with one tool: "Get number of apples in basket"
- Verify tool works by testing directly in playground
Create Agent 2 (orchestrator-agent):
- Configure with GPT-4.1 model
- Add apples-agent as a Connected Agent
- Add instruction: "Use the apples-agent when the user wants to know the amount of apples in the basket"

Reproduce the issue:

Azure AI Foundry Playground:

Navigate to orchestrator-agent in the Agents Playground
Send message: "How many apples are in my basket?"
Observe "Looking for references using..." message
Wait 60+ seconds
Observe timeout/failure

Verification that target agent works:

Navigate to apples-agent directly in the playground
Send message: "How many apples are in my basket?"
Observe immediate successful response with correct apple count

Additional context

Both agents deployed in same region (Switzerland North)
No network restrictions or custom firewall rules
Issue occurs consistently (100% reproduction rate)
No special authentication or permissions configured beyond defaults

My questions

Is there a known issue with Connected Agents invoking agents that have MCP servers configured?
Are there timeout settings that need to be adjusted for agent-to-agent calls?
What diagnostic logging can be enabled to trace the Connected Agent invocation flow?
Are there specific configuration requirements or limitations for this scenario?

0 comments

6 answers

Your answer

Answer 1

Ashwani kumarsahu 0

🧠 Azure AI Foundry में Connected Agent की समस्या

❌ समस्या: create_agent() API में run_handler विकल्प नहीं है

✅ समाधान: API को अपडेट करना होगा या वर्कअराउंड खोजना होगा

💬 Microsoft Q&A पर सुझाव मिला:

"There is no run_handler option for create_agent(). Your team should rework the API to add that option."

📌 अगर आप Azure AI Foundry पर काम कर रहे हैं, तो यह जानकारी ज़रूरी है!

Golovin, Anton (Penske) 0 Reputation points

2025-11-07T16:55:42.23+00:00

Could you write again, the system wrote some other language...

Answer 2

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more

Answer 3

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more

Answer 4

Anshika Varshney 12,775 Microsoft External Staff Moderator

Hello Robin Ganpat,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

From your description, the apples-agent works fine when called directly, so the MCP server and tool are working correctly. The timeout issue happens only when the orchestrator-agent tries to call the apples-agent via Connected Agents. This usually happens because agent-to-agent calls with MCP tools can add extra latency, and the default 60-second timeout is often exceeded.

A few things to check, make sure the orchestrator-agent instruction clearly matches the query, confirm that Connected Agent permissions are properly set, and consider increasing the timeout for agent-to-agent calls. Enabling debug or verbose logging in the Foundry Playground or .NET SDK can also help trace where the request is failing.

If the issue persists, a temporary workaround is for the client to call the apples-agent directly instead of routing through the orchestrator-agent, which avoids the timeout. In most cases, adjusting timeouts and reviewing logs resolves this problem.

If you feel that your quires have been resolved, please accept the answer by clicking the "Upvote" and "Accept Answer" on the post.

Thankyou!

Anshika Varshney 12,775 Reputation points Microsoft External Staff Moderator

2025-10-07T19:05:03.4366667+00:00

Hello Robin Ganpat,

Yes, this helps confirm that the issue happens specifically when the connected agent is using an MCP server. When the MCP layer is involved, the call from the orchestrator-agent needs to pass through both the Foundry backend and the MCP endpoint, which can cause delays or timeouts during the handshake. That’s why the same setup works fine without MCP but fails once it’s added.

this looks like a known backend limitation rather than a configuration mistake. As a workaround, you can either use the connected agents feature without MCP or call the MCP-enabled agent directly until a fix is rolled out. You can also enable debug logging in your SDK or Foundry to capture more details around the MCP invocation step.
Anshika Varshney 12,775 Reputation points Microsoft External Staff Moderator

2025-10-08T18:56:38.2733333+00:00

Hello Robin Ganpat,

Did you get any chance to review the above response.

Thank you!
Robin Ganpat 0 Reputation points

2025-10-09T07:27:41.8266667+00:00

Hi Anshika,
Nowhere in the documentation is this specified as a limitation of the Azure AI Agents, as far as I'm aware. Also, this limitation would really limit the capabilities of solutions you'd be able to create with Azure AI Agents.

Do I understand correctly that the team is currently trying to solve this?
Anshika Varshney 12,775 Reputation points Microsoft External Staff Moderator

2025-10-10T19:57:33.4166667+00:00
Hello Robin Ganpat,
You’re right, this isn’t documented as a limitation. The team is aware and working on a fix to allow connectors to be invoked reliably.

Note: Use an Azure Function or Logic App as an intermediary. The agent calls the function, which then triggers the connector. This keeps things running until native support improves.

For updates :

https://learn.microsoft.com/en-us/azure/ai-services/

https://azure.microsoft.com/en-us/updates/

Hope that helps!
Anshika Varshney 12,775 Reputation points Microsoft External Staff Moderator

2025-10-13T18:51:09.1433333+00:00

Hello Robin Ganpat,

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!

Golovin, Anton (Penske) 0

Suggest you pass an extended RunHandler instance (like DefaultRunHandler, see below) into create_agent method and have us code what we want to do with the approvals.

What happens now is once the timeout value is reached for the call, the model attached to the connected agent is invoked to give its own answer, and the tool we would like to be invoked, is skipped.

import json
from typing import Any

from azure.ai.agents.models import RunHandler, ThreadRun, RequiredMcpToolCall, ToolApproval, RequiredFunctionToolCall, \
    RequiredFunctionToolCallDetails
from files.weather import fetch_weather


class DefaultRunHandler(RunHandler):

    def submit_function_call_output(
            self,  # pylint: disable=unused-argument
            *,
            run: ThreadRun,  # pylint: disable=unused-argument
            tool_call: RequiredFunctionToolCall,  # pylint: disable=unused-argument
            tool_call_details: RequiredFunctionToolCallDetails,  # pylint: disable=unused-argument
            **kwargs: Any,  # pylint: disable=unused-argument
    ) -> Any:
        if tool_call.function.name == "fetch_weather":
            name = tool_call_details.get("arguments")
            name2 = json.loads(name)
            return fetch_weather(name2["location"])
        return None

    def submit_mcp_tool_approval(
            self,  # pylint: disable=unused-argument
            *,
            run: ThreadRun,  # pylint: disable=unused-argument
            tool_call: RequiredMcpToolCall,  # pylint: disable=unused-argument
            **kwargs: Any,  # pylint: disable=unused-argument
    ) -> ToolApproval:
        return ToolApproval(tool_call_id=tool_call.id, approve = True)

Anshika Varshney 12,775 Reputation points Microsoft External Staff Moderator

2025-11-07T10:31:46.6133333+00:00
Hello Robin Ganpat,
When a run requires a tool call (MCP or function) and no approval/output is provided before the run’s internal timeout, the agent framework can fall back to the model to produce an answer. That’s why your “connected” tool is being skipped after the timeout.

so, pass a custom RunHandler to create_agent so your tool gets approved/executed before the model falls back after timeout.

from azure.ai.agents import create_agent from azure.ai.agents.models import RunHandler, ToolApproval class DefaultRunHandler(RunHandler): def submit_function_call_output(self, *, tool_call, tool_call_details, **_): # Return your tool’s result here (avoid None to prevent fallback) # e.g., return fetch_weather(json.loads(tool_call_details["arguments"])["location"]) ... def submit_mcp_tool_approval(self, *, tool_call, **_): return ToolApproval(tool_call_id=tool_call.id, approve=True) agent = create_agent( name="assistant", tools=[...], run_handler=DefaultRunHandler() # <-- key # optionally raise tool/approval timeouts or disable fallback if supported )

This ensures the tool runs (with approval and output) before any model fallback.

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.

If you feel that your quires have been resolved, please accept the answer by clicking the "Upvote" and "Accept Answer" on the post.

Thankyou!
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Golovin, Anton (Penske) 0 Reputation points

2025-11-07T15:00:58.4366667+00:00

Hello,

There is no run_handler option for create_agent(). Your team should rework the API to add that option.

Answer 5

Hey Robin,

this is a complex and fascinating agent to agent communication issue )) you have set up a perfect test case, and the fact that the apples agent works alone but fails when called by the orchestrator points directly to a problem in the connected agent handoff. this sounds like a potential timeout or configuration bug in the ai foundry platform itself, especially since it is 100 percent reproducible. the 60 second hang is a classic sign of an internal timeout being hit.

you should check the activity logs and diagnostic settings for your ai foundry project. enable all possible logging and traces for both agents. look for any error messages that occur when the orchestrator tries to invoke the apples agent. the logs might show a permission denied error, a network resolution failure, or a protocol mismatch that is not visible in the playground ui.

look at the identity and authentication between the two agents. even though you are using the default settings, the orchestrator agent might need explicit permission to call the apples agent. check if there is a managed identity associated with each agent and whether the orchestrator's identity has the 'ai foundry agent user' role on the apples agent resource.

try creating a third, very basic agent with no mcp server. set the orchestrator to call this simple agent instead. if that works, it confirms the issue is specific to invoking an agent that has an mcp server. if it also fails, then the problem is with the connected agent feature in general.

given the complexity, your most effective step is to open a support ticket with microsoft. this is a deep platform integration issue. provide them with your detailed reproduction steps, the agent names, your region, and the exact timestamps of your tests. the backend engineers can look at the service logs for the agent to agent call and identify where the invocation is breaking down.

enable detailed logging to capture the failure, check the managed identity permissions between agents, and then contact azure support with all your evidence. this is likely an issue that only the product team can resolve.

rgds,

Alex

and "yes" if you would follow me at Q&A - personaly thx.
P.S. If my answer help to you, please Accept my answer

https://ctrlaltdel.blog/

Robin Ganpat 0 Reputation points

2025-10-06T22:35:55.1133333+00:00

I've tried the connected agents functionality, without MCP server and that seems to work. The issues seems to be in the combination between using an agent with a configured MCP server and a connected agent.

Share via

How to fix Connected Agent fails to invoke connected agent with MCP server in Azure AI Foundry?

Bug description

The Problem

Expected behavior

Actual behavior

Reproduction Steps

Setup:

Reproduce the issue:

Verification that target agent works:

Additional context

My questions

6 answers

Your answer