20 min read

Why My AI Agent Stops Responding When Multiple MCP Tools Are Selected – Debugging the Root Cause

This article documents a step‑by‑step investigation of an AI Agent that fails to return results when it selects multiple MCP services, detailing log analysis, network packet capture, MCP protocol behavior, the discovery of tool‑name conflicts, and both temporary and permanent remediation strategies.

Go Programming World

Jul 7, 2025

Why My AI Agent Stops Responding When Multiple MCP Tools Are Selected – Debugging the Root Cause

This post records a complete troubleshooting case where an AI Agent, when choosing multiple MCP services for a chat, fails to receive any response, serving as a reminder to avoid repeating the same mistake.

Origin

In an AI Agent project, the Agent can call MCP tools during a conversation. One type of MCP service is generated by the open‑source Higress project, which converts HTTP interfaces into MCP tools using an OpenAPI document. The Agent sends MCP requests to the Higress gateway, which forwards them as HTTP calls to the original endpoints and returns the data via the MCP protocol.

NOTE: For details on converting HTTP interfaces to MCP services, see the article "Using MCP Gateway to Convert Your HTTP Interface into an MCP Server".

During testing, a colleague reported that the Agent works fine when a single MCP (e.g., Gaode Map or weather) is selected, but when both are selected simultaneously, the Agent returns no result and the WebSocket eventually times out.

Phenomenon

Using the Cherry Studio client as an example, the screenshot below shows the chat window when two MCP tools are selected. The Agent sends repeated HTTP requests with a 202 status code but never receives tool results.

The Agent configures two MCP tools, allowing the large model to invoke external tools. When only one tool is checked, the conversation works; when both are checked, the Agent continuously retries without returning any result.

NOTE: The Agent instantiates an MCP client; when the model needs to call a tool, the client communicates with the MCP server.

Idea

Since the issue is likely in the Agent code, the first step is to check logs. However, because the Agent is built on the OpenAI Agents SDK, which abstracts MCP interactions, logs alone may not reveal the problem.

The plan is to examine Agent logs, then Higress logs, and finally the source code if needed.

Practice

Agent Logs

The logs show repeated lines like:

INFO:   2025-07-01 10:25:22,628 - _client.py:1740 - HTTP Request: POST http://higress-gateway.higress-system.svc.cluster.local/mcp-server/mcp-server-54?sessionId=722661db-c271-4ce4-82bd-cf8c07e4e736 "HTTP/1.1 202 Accepted"

This indicates the Agent is constantly retrying MCP calls.

Higress Logs

No useful clues were found in the Higress logs.

Validate MCP Services

Using the official MCP Inspector tool, each MCP service was called manually and confirmed to work correctly. However, the Inspector can only call one MCP at a time, so it cannot reproduce the multi‑MCP issue.

MCP Protocol Call Flow

The MCP client first establishes an SSE connection, receives a route URL, then POSTs tool‑call requests to that URL. The server returns 202 immediately; the actual tool result is pushed later through the SSE channel.

The client sends a GET request to the SSE endpoint (e.g., http://127.0.0.1:8000/sse).

The server replies with the route URL (e.g., /message?sessionId=...).

The client POSTs the tool name and arguments to that route.

The server returns 202 and later pushes the result via SSE.

Capturing the network traffic confirms this flow.

Stuck in a Loop

Analysis suggests that Higress may fail to deliver messages over the SSE endpoint, causing the Agent to keep retrying POST requests without ever receiving tool results.

Packet Capture

Because the Agent runs in a Kubernetes pod, a debug container (netshoot) was injected to capture traffic with tcpdump. The capture file was later examined with Wireshark.

# View the agent pod
$ kubectl get pod
NAME    READY   STATUS    RESTARTS   AGE
agent   1/1     Running   0          16s

# Debug container command
$ kubectl -n default debug agent -it --image=nicolaka/netshoot:latest --target=agent

# Capture packets
# tcpdump -i eth0 -w capture.pcap

Filtering for the Agent’s IP and HTTP traffic revealed the SSE connection requests and the POST requests that never produced tool results.

All POST requests returned a JSON‑RPC response with an empty result, e.g.:

{
  "jsonrpc": "2.0",
  "id": "2025-07-01T12:57:49Z",
  "result": {}
}

Since no tool was actually invoked, the suspicion turned to a naming conflict.

Root Cause

Two MCP services contained a tool with the same name. According to the MCP specification, tool names must be globally unique. When the Agent sees duplicate names, it cannot determine which tool to call, resulting in repeated 202 responses and no result.

Solution

Temporary Fix

Delete or rename the duplicate tool in one of the MCP services, then regenerate the MCP server via Higress.

The tool name is derived from the OpenAPI operationId. If omitted, Higress generates a name from the URL path.

Permanent Fix

Enforce uniqueness when converting OpenAPI documents to MCP services. Possible strategies include:

Prefix each tool name with the service name (e.g., web1___search_web).

Add a random prefix (e.g., jrwxs___search_web).

Use the server URI as a prefix (e.g., web1.example.com:search_web).

These approaches guarantee global uniqueness across all MCP services.

Summary

The investigation showed that the AI Agent’s failure to return results when multiple MCP services are selected was caused by duplicate tool names. Making tool names unique—either by adjusting the OpenAPI operationId or by applying a systematic naming scheme—resolves the issue.

NOTE: The official MCP documentation explicitly states that tool names must be unique.