[BUG] Tool call completes on server but response never reaches client (4-min timeout) in Claude Desktop

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The powerbi-modeling-mcp server (v0.1.9.0) executes tool calls
successfully and returns a result, but the response never reaches the
model. The client reports "No result received from the Claude Desktop
app after waiting 4 minutes" for calls the server completed in ~70 ms.

The server log confirms this
(%APPDATA%\Claude\logs\mcp-server-powerbi-desktop-mcp.log):

ConnectionOperationsTool.ListLocalInstances completed: Count=2
method 'tools/call' request handler completed.
Message from server: id=3 result(1 blocks)

The server detected both Power BI instances and delivered the response.
The client still reported a timeout.

Reproduced with ListLocalInstances, ListConnections, and Connect with an
explicit localhost:<port>, so it is not related to instance discovery.

Environment: Windows, Claude Desktop as MCP host (claude-ai 0.1.0),
Claude Opus 5, two .pbix files open (ports 60306 and 50554).

error.mcp.log

What Should Happen?

The MCP server response should reach the model and be displayed in the
conversation — in this case, the list of the 2 detected local Power BI
Desktop instances, within a few seconds.

Additionally, when the transport fails, the error message should not
state that the server is unresponsive. The server did respond. The
misleading error led to an hour of troubleshooting in the wrong
direction (permissions, .NET runtime, zombie processes) when the actual
failure was in the response transport between the MCP host and the model.

error.mcp.log

Error Messages/Logs

Client side (shown to the model):

  No result received from the Claude Desktop app after waiting 4 minutes.
  The local MCP server providing this tool may be unresponsive, crashed,
  or not running.

Server side, same call, from
%APPDATA%\Claude\logs\mcp-server-powerbi-desktop-mcp.log:

  [powerbi-desktop-mcp] [info] Message from client: method="tools/call" id=3
  info: ModelContextProtocol.Server.McpServer[570385771]
        Server (powerbi-modeling-mcp 0.1.9.0), Client (claude-ai 0.1.0)
        method 'tools/call' request handler called.
  info: PowerBIModelingMCP.Library.Tools.ConnectionOperationsTool[0]
        ConnectionOperationsTool.ListLocalInstances completed: Count=2
  info: ModelContextProtocol.Server.McpServer[1867955179]
        method 'tools/call' request handler completed.
  [powerbi-desktop-mcp] [info] Message from server: id=3 result(1 blocks)

Timestamps: request at 22:35:17.535, response at 22:35:17.606 (~70 ms).
The client reported the 4-minute timeout for that same call id.

Same pattern for id=4 (ListLocalInstances, Count=2), id=5
(ListLocalInstances, Count=2), and id=6 (ListConnections, Count=0).
No errors or exceptions anywhere in the server log.

Steps to Reproduce

1. Open two .pbix files in Power BI Desktop on Windows (any model;

AdventureWorks Sales works). Confirm two local instances exist:

Get-Process msmdsrv | ForEach-Object {
$p = $_
Get-NetTCPConnection -OwningProcess $p.Id -State Listen |
Select-Object -Unique @{n='PID';e={$p.Id}}, LocalPort
}

Expected output: two rows, e.g. PID 21376 -> 60306, PID 25492 -> 50554

1. Configure powerbi-desktop-mcp as an MCP server in Claude Desktop

(claude_desktop_config.json) and restart the app fully (the app stays
in the system tray; closing the window does not restart MCP servers).

1. In a conversation, ask the model to list connected Power BI instances,

so it calls ConnectionOperations with operation=ListLocalInstances.

1. Observe: the model waits and receives a 4-minute timeout.

1. Open %APPDATA%\Claude\logs\mcp-server-powerbi-desktop-mcp.log and

compare. The server logged "ListLocalInstances completed: Count=2"
and "Message from server: id=N result(1 blocks)" ~70 ms after the
request.

1. Repeat with operation=ListConnections (pure in-memory, does not touch

Power BI) and with operation=Connect and dataSource=localhost:60306.
Both behave the same: server completes, client times out.

Notes: the server process was alive throughout; the only "Server
transport closed" entry in the log corresponds to a manual taskkill
performed later during troubleshooting. No admin elevation involved,
Power BI Desktop and Claude Desktop both running as the same
non-elevated user.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

N/A — not using Claude Code. This issue occurs in Claude Desktop on Windows. claude --version returns CommandNotFoundException because Claude Code is not installed on this machine. Client identifies as "claude-ai 0.1.0" in the MCP handshake, per the server log. MCP server configured via claude_desktop_config.json.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Terminal.app (macOS)

Additional Information

Additional context:

• Troubleshooting already ruled out on my side:
• Power BI Desktop instances confirmed alive via PowerShell

(msmdsrv listening on ports 60306 and 50554)

• Full restart of Claude Desktop via taskkill /F /IM claude.exe

(not just closing the window, which leaves the app in the tray)

• No zombie MCP server process
• No admin elevation mismatch — Power BI Desktop and Claude Desktop

both running as the same non-elevated user

• Server log shows no exceptions, no crashes, no transport errors

during the failing calls

• The failure is consistent across three different code paths inside the

server (instance enumeration, in-memory connection listing, and direct
connect by explicit port), which points to the transport rather than to
any specific tool.

• Impact note: the timeout message states the server "may be unresponsive,

crashed, or not running". That is incorrect here and actively misleading
— it sent me down an hour of troubleshooting on the server side while
the server was healthy the whole time. Surfacing the server's own log
state, or distinguishing "no response from server" from "response not
delivered to model", would have made this diagnosable in minutes.