Tool Call Failed: Request timed out

[khteh]

@modelcontextprotocol/inspector successfully connected to the server but tool call failed as the request timed out. It's a simple Echo tool. There is no log both in the application and the @modelcontextprotocol/inspector Log tab. The MCP server is ASP.Net Core 10 deployed and run on local k8s.

When I try from Postman, connection is successful but there is no tool found on the server.

[jeffhandley]

Thanks for the report. To investigate this timeout, could you please update this issue with a more comprehensive minimal reproduction, including the Echo server implementation, the SDK package versions, client and server transport configuration, and relevant local-Kubernetes deployment details? Please let us know whether the same configuration works with a previous SDK version or a different MCP server approach, and whether Docker networking could be contributing to the timeout.

[khteh]

SDK package versions: <PackageReference Include="ModelContextProtocol.AspNetCore" Version="2.0.0" />
https://github.com/khteh/AspNetCoreWebApi/blob/master/src/Web.Api/Program.cs#L374
https://github.com/khteh/AspNetCoreWebApi/blob/master/src/Web.Api/MCPServer/MCPServerTools.cs
https://github.com/khteh/Kubernetes/tree/master/AspNetCoreWebAPI/AspNetCoreWebAPI

[ump45nose]

I can't reproduce a definitive SDK bug from the details so far, so here is a focused diagnostic checklist that should either isolate the fault or pin it to the deployment. Two of the symptoms strongly suggest the requests themselves, not the tool.

The "no tools in Postman" symptom is expected unless Postman speaks JSON-RPC

The MCP endpoint is a JSON-RPC surface, not a plain HTTP endpoint. "Connecting" in Postman (e.g. a bare GET/POST to the mapped path) does not list tools — you have to send an actual JSON-RPC request, for example:

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"probe","version":"1.0.0"}}}

then

{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}

then

{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"Echo","arguments":{"message":"hi"}}}

So "no tool found" from a plain Postman request tells us nothing about the server — only about what was sent. Could you paste the exact request body and the raw response (status + body + Content-Type) you get for tools/list?

What would make Inspector time out on tools/call but list successfully

Inspector's connect already performs initialize + tools/list (that's why it shows the tool at all). If it lists Echo but then the call times out, the likely causes are deployment-side, in rough order:

1. Session affinity. You set o.Stateless = true, which is fine — but confirm that every tools/list and tools/call request can reach any replica. If the server still uses a session (Mcp-Session-Id) on the older 2025-11-25 revision and the ingress does not pin it, the second POST can land on a replica with no such session. Stateless mode should not mint sessions — worth verifying with SessionMode = HttpServerSessionMode.Stateless explicitly and checking the response headers for Mcp-Session-Id.
2. The ingress/idle timeout. A long-running request only needs to be listed by Inspector for the call to time out. If the k8s ingress/proxy has an idle-read timeout shorter than the tool's duration, the connection stalls exactly like this.
3. tools/list vs tools/call routing. In stateless mode the server builds a fresh context per request. If WithToolsFromAssembly() does not see the tool on the call path (see below), tools/call for a missing tool would return a "tool not found" JSON-RPC error, not a timeout — unless the request is being dropped by the network, which brings us back to Race condition when running the StdioServerTransportTests.SendMessageAsync_Should_Send_Message test #1/Add Directory.Build.props, apply CPM, use NB.GitVersioning, update package publishing #2.

One SDK-side thing worth ruling out

WithToolsFromAssembly() discovers types via reflection (Assembly.GetCallingAssembly() + [McpServerToolType]). It is marked [RequiresUnreferencedCode] and documented as "might not work in Native AOT." If your k8s image is published trimmed (PublishTrimmed=true) or AOT, tool discovery can silently find zero tools. The most reliable check is to add an explicit .WithTools<MCPServerTools>() (or log the registered tool count at startup). If switching to the generic overload fixes the missing-tool symptom, that's a concrete, actionable repro.

Minimal repro that isolates the SDK from k8s

Run the same Program.cs locally and point Inspector at http://localhost:<port>/:

dotnet run

• If Echo works locally but not through k8s → the problem is the ingress/replica configuration, not the SDK.
• If Echo also times out locally → please share the local server's Mcp-Session-Id header behavior and Inspector's network tab entries for the tools/call, and we can dig into the SDK path.

What I checked

I built the SDK at HEAD (v2.2.0) and ran the stateless HTTP tests: 77 passed, 0 failed (including CallToolAsync cases against a stateless server). That doesn't rule out a bug in your specific configuration — but the stateless tool-call path itself is exercised and passing in CI.

AI assistance disclosure: AI was used to discover this opportunity and draft the change or text. The submission was checked against the prepared artifact and recorded verification evidence.

[khteh]

Postman does have native MCP support:

However, I encountered connection issue sometimes as my previous post and I have never received the tools list.

[khteh]

I get further with NODE_TLS_REJECT_UNAUTHORIZED="0" env but hit the following error message in the inspector window both when connecting to localhost (dev run) as well as when o.SessionMode = HttpServerSessionMode.Stateless; is not used to connect to the MCP server running in local k8s. In fact, when I update and restart the app in k8s (both statefulset and the Service), @modelcontextprotocol/inspector hits this error:

Failed to connect to "aspnetcorewebapi-localhost"
Version negotiation probe failed: Dynamic Client Registration rejected (HTTP 404):

Postman error:

Couldn't run the request: SSE error: Non-200 status code (405)

In any case that it successfully connects to the MCP server, I still don't receive the tools list in both clients - Postman and @modelcontextprotocol/inspector.

[khteh]

app.MapMcp("/mcp").RequireAuthorization(); was the culprit. However, I still don't get the tools list in both clients.

Without o.SessionMode = HttpServerSessionMode.Stateless; or with the line commented out, the connection sometimes succeed and sometimes failed. I don't believe this should cause the connection to fail at all since otherwise, the product won't be able to support the stateful connection as claimed in https://github.com/modelcontextprotocol/csharp-sdk/blob/main/docs/concepts/transports/transports.md#streamable-http-server-aspnet-core

Set SessionMode = HttpServerSessionMode.Stateful explicitly when your server needs stateful sessions for unsolicited notifications, resource subscriptions, or per-client isolation.

and therefore, it is a BUG.

[ump45nose]

Two of the three symptoms have concrete explanations in the SDK source; the third still needs one raw response.

Dynamic Client Registration rejected (HTTP 404) — expected for this setup

MapMcp maps only the MCP transport endpoints: POST always, and GET/DELETE only when SessionMode is not Stateless. The only OAuth surface the SDK adds is protected-resource metadata: McpAuthenticationHandler intercepts /.well-known/oauth-protected-resource[...] and answers it, and challenges carry WWW-Authenticate: Bearer resource_metadata="...". There is no dynamic-client-registration endpoint and no token endpoint, so a client that tries to self-register gets a 404 unless your app hosts its own authorization server and advertises it. That failure is about OAuth discovery, not about your tool.

SSE error: Non-200 status code (405) — that is the GET/SSE probe, not the tool call

In Stateless mode the GET endpoint is deliberately not mapped ("Resuming streams via GET is currently not supported in Stateless mode"), so an SSE GET gets 405 Method Not Allowed; StatelessServerTests asserts exactly that for both GET and DELETE. In stateful mode a GET without Mcp-Session-Id is refused with 400 Bad Request. Either way, a 405 on GET says nothing about whether tools/call can work.

Stateful intermittency points at session affinity, not at SessionMode

In Stateful mode initialize mints an Mcp-Session-Id, and every later POST must carry it; a POST that lands on a replica that never saw the initialize is rejected with 400 ... Missing session ID. With more than one replica behind the Service and no session affinity, that reproduces as "sometimes succeeds, sometimes fails". The check that separates this from an SDK bug is: pin affinity (or run one replica) and look at the Mcp-Session-Id header plus status on the failing response.

Empty tools/list while connected — the one thing worth checking next

WithToolsFromAssembly() defaults to Assembly.GetCallingAssembly() and is [RequiresUnreferencedCode]. If the tools live in a different assembly than the call site, or the published image is trimmed/Native AOT, discovery finds zero tools, and the client gets an empty list over a healthy connection. Either .WithTools<MCPServerTools>() or .WithToolsFromAssembly(typeof(MCPServerTools).Assembly) fixes the symptom or rules it out.

What would settle it: the raw tools/list POST response for a connection that "succeeds" — status, Mcp-Session-Id, Content-Type, and body. The inspector and Postman UIs do not distinguish "empty list" from "error body", and that distinction is the whole remaining question.

One more thing worth ruling out: if the client is also on 2.0.0, #1848 tracks the v2.0 discover→initialize fallback being unreachable for POST-only servers, which fails the connect outright rather than returning an empty list.

For reference, on current main I ran the stateful fallback, authorization-attribute, stateless-server, and session-migration suites locally (net10.0, Release): 53 passed, 0 failed. That covers SessionMode and tool-level authorization, but not end-to-end RequireAuthorization() on MapMcp behind an ingress — a minimal repro of that path would still be genuinely useful.

AI assistance disclosure: AI was used to discover this opportunity and draft the change or text. The submission was checked against the prepared artifact and recorded verification evidence.

[khteh]

Empty tools/list while connected — the one thing worth checking next

Not an issue here as both Program.cs and the tools are in the same assembly.