[Bug] Streamable HTTP MCP: tools/call always fails while tools/list succeeds

[mwnu]

Description

When connecting to a Streamable HTTP MCP server, tools/list works correctly (all tools are discovered), but every subsequent tools/call invocation fails with a generic Error: Function failed. message, regardless of the tool or parameters.

Environment

• DotCraft Desktop
• Windows 10
• MCP server using streamableHttp transport

Steps to Reproduce

1. Configure any Streamable HTTP MCP server in config.json with Bearer token auth
2. Verify connection succeeds: log shows MCP connected to ... with N tools
3. Call any tool — even one that takes no parameters
4. Observe: Error: Function failed.

Investigation

Both tools/list and tools/call responses from the server are identical in HTTP structure:

• HTTP 200
• Content-Type: text/event-stream
• Transfer-Encoding: chunked
• SSE format: event: message\ndata: {...}\n\n

Direct HTTP calls to the same server work perfectly — the server is not the problem. Other MCP clients also work fine.

DotCraft successfully parses tools/list (tools are discovered) but fails on every tools/call, despite both responses sharing the exact same SSE/HTTP format. No errors are logged for the failed tool calls.

Likely Cause

Bug in DotCraft's Streamable HTTP MCP client response handling specific to the tools/call code path.

Side Note: Config docs are unclear

The config.json fields BearerTokenEnvVar and EnvHttpHeaders are undocumented. It's unclear how to configure a Streamable HTTP MCP server to read tokens from environment variables — attempting to do so produces cryptic errors like MCP server 'X' requires env var '<value>' for header 'Authorization'. Clear docs or examples for these fields would help avoid hardcoding tokens in Headers.

[mwnu]

This looks like an auth header propagation issue specific to the Streamable HTTP transport. The succeeds because it uses GET, while fails because it uses POST — and the Bearer token isn't being included in the POST request.tools/list``tools/call

Root cause hypothesis:

The Streamable HTTP MCP transport (per the 2025-03-26 spec) distinguishes between two request types:

• GET requests (server-to-client notifications, SSE event stream initialization)
• POST requests (client-to-server: , , tools/call``resources/read``prompts/get)

If DotCraft's MCP client is using a transport layer that attaches the header only to the initial connection handshake (GET), subsequent POST requests to the same endpoint go out without auth. The server sees the POST as unauthenticated and returns a generic error.Authorization: Bearer <token>

Check these things on your MCP server:

1. Log the actual HTTP requests hitting your server. Look at whether POST requests to the message endpoint include the header. If it's missing on POST but present on GET, the bug is in the client-side transport implementation.Authorization
2. Verify the in your is the full message endpoint path. Some Streamable HTTP servers use different paths for GET (SSE events) vs POST (JSON-RPC calls). If your server expects POST to but DotCraft is POSTing to , the server returns 404 which the client translates to "Function failed."url``config.json``/message``/sse
3. Quick workaround: If you control the server, temporarily accept unauthenticated POST requests (or validate via a different mechanism) to confirm the auth header is the issue. If tools/call works without auth, you've found the bug.

We hit similar transport quirks building the corpusiq.io MCP server — the Streamable HTTP spec is still young and client implementations vary in how they handle auth persistence across GET vs POST paths. The MCP SDK's class in the TypeScript SDK has had several fixes for this exact pattern.StreamableHTTPClientTransport

In fact, the dotcraft session did not return any such error message, and no relevant log was found. Here is the possible reason given by the agent after analyzing the source code:

1. ModelContextProtocol v0.8.0-preview.1 (src/DotCraft.Core/DotCraft.Core.csproj)
The project uses an outdated preview of the MCP SDK (latest stable is v1.4.0). The preview likely has a bug in parsing SSE responses for tools/call — the server returns identical SSE format for both tools/list and tools/call, but tools/list works while tools/call throws. Upgrading the NuGet may resolve this.

2. Exception details are hidden (src/DotCraft.Core/Agents/StreamingFunctionInvokingChatClient.cs:721)
When function.InvokeAsync() throws, the actual exception is captured but only the generic "Error: Function failed." string is returned to the user. The real error (ex.Message) is sent to ToolExecutionTracker.CompleteFailure() but never surfaced. This makes debugging MCP issues nearly impossible.

[AkiKurisu]

Thank you for the explanation. DotCraft is using an outdated version of the MCP SDK. The next version will upgrade to 1.4.0, which will help resolve the issues with the MCP Bridge itself.

I will optimize other aspects such as front-end display for a better user experience. Thank you for your feedback!

[AkiKurisu]

I reproduced this locally with a FastMCP Streamable HTTP server: normal tools/call works and Authorization is correctly sent, so this is not an auth propagation issue. The failing case is that DotCraft’s current MCP C# SDK does not send standard tools/call HTTP headers like mcp-method: tools/call and mcp-name: <tool>, which strict Streamable HTTP servers may reject and DotCraft currently surfaces as generic Function failed.

[AkiKurisu]

Follow-up: I also tested ModelContextProtocol@1.4.0, which is currently the latest NuGet release, and it still does not send mcp-method / mcp-name on tools/call. The relevant upstream fixes seem to be merged on modelcontextprotocol/csharp-sdk main but are not included in any NuGet release yet: SEP-2243 HTTP headers in modelcontextprotocol/csharp-sdk#1553, x-mcp-header alignment in #1619, and JSON content-type cleanup in #1528, so we will wait for the next MCP C# SDK release before changing DotCraft-side behavior.

[AkiKurisu]

Optimized in #60

[mwnu]

Optimized in #60

Follow-up on MCP streamable HTTP improvements

Thanks for the recent fixes — tools/list now connects reliably. However, testing against two different MCP servers (one using ASP.NET Core's Streamable HTTP handler, another a custom implementation) has surfaced new issues:

1. Stale Mcp-Session-Id causes persistent tools/call failures

• One of my servers returns a Mcp-Session-Id header on responses. DotCraft caches this session ID and sends it back on every subsequent tools/call request.
• When the session expires server-side, DotCraft continues sending the stale ID, and the server responds with HTTP 404 + {"code":-32001,"message":"Session not found"}.
• DotCraft does not handle this error gracefully — it neither discards the expired session nor falls back to a session-less request to re-establish a new one. The result is a permanent failure loop.
• Crucially, this server does NOT require Mcp-Session-Id at all. Sending tools/call without the header works perfectly (HTTP 200). DotCraft is injecting a session header that the server doesn't need, and when that self-injected header goes stale, everything breaks.
• For comparison, my second MCP server never returns Mcp-Session-Id, and DotCraft's tools/call works flawlessly against it — confirming the issue is tied to DotCraft's session header management, not the tools/call mechanism itself.

Suggested fix: When DotCraft receives a 404 with "Session not found" from a tools/call, it should discard the cached Mcp-Session-Id and retry the request without it (fresh session-less request). Additionally, consider whether DotCraft should be proactively re-sending session headers in the first place for servers that don't mandate them.

2. MCP protocol implementation is incomplete — only Tools are bridged

MCP defines three first-class resource types:

Resource	Methods	DotCraft Status
Tools	tools/list, tools/call	✅ Supported
Prompts	prompts/list, prompts/get	❌ Not bridged
Resources	resources/list, resources/read	❌ Not bridged

I confirmed my server exposes 4 prompts and multiple resources — all accessible via raw HTTP prompts/list and prompts/get — but DotCraft provides no way to discover or interact with them. This means AI agents using DotCraft miss out on pre-defined prompt templates (e.g., writing guidelines, HTML generation specs) and resource-linked configuration that the server intentionally exposes.

3. Tool call debugging is opaque

When tools/call fails, the error surfaced to the agent/user is minimal:

Error: Function failed. Reason: Response status code does not indicate success: 404 (Not Found).
Response body: {"error":{"code":-32001,"message":"Session not found"},"id":"","jsonrpc":"2.0"}

There is no visibility into:

• What exact HTTP request DotCraft sent (URL, headers, body)
• What headers the server responded with (e.g., Mcp-Session-Id, Content-Type)
• Whether the id field mismatch (empty "" in error vs. expected request ID) was involved

Diagnosing the session ID issue required manually reproducing DotCraft's HTTP calls with PowerShell/curl and comparing headers byte-by-byte. A debug/log mode that surfaces the raw MCP request/response would make troubleshooting dramatically faster — especially for transport-level issues like session management, SSE parsing, and header handling.

[mwnu]

1. Stale Mcp-Session-Id causes persistent tools/call failures

• One of my servers returns a Mcp-Session-Id header on responses. DotCraft caches this session ID and sends it back on every subsequent tools/call request.
• When the session expires server-side, DotCraft continues sending the stale ID, and the server responds with HTTP 404 + {"code":-32001,"message":"Session not found"}.
• DotCraft does not handle this error gracefully — it neither discards the expired session nor falls back to a session-less request to re-establish a new one. The result is a permanent failure loop.
• Crucially, this server does NOT require Mcp-Session-Id at all. Sending tools/call without the header works perfectly (HTTP 200). DotCraft is injecting a session header that the server doesn't need, and when that self-injected header goes stale, everything breaks.
• For comparison, my second MCP server never returns Mcp-Session-Id, and DotCraft's tools/call works flawlessly against it — confirming the issue is tied to DotCraft's session header management, not the tools/call mechanism itself.

Similar issues can be reproduced in Reasonix. After some investigation, I found that this is related to the stateful mode of the MCP server. When session support is enabled, the server creates and tracks sessions for each client, and the client automatically includes the session ID in subsequent requests. The MCP specification requires that clients use sessions when the server's initialize response includes the Mcp-Session-Id header—this is not optional for the client. Session expiration detection and reconnection are the responsibility of the application using the client SDK. Clients that make requests with an expired session ID and receive a 404 Session not found error should initiate a new session.

Some MCP server implementations are very aggressive with idle timeouts, which may also be related to the server hosting environment (for example, Cloudflare proxies have a default 100-second timeout policy for idle connections). Additionally, clients may actively close connections (DELETE Mcp-Session-Id). All of these factors can cause idle connections to time out within a short period (e.g., just a few minutes).

In summary, the stateful mode of MCP adds complexity to the problem. Per the specification, clients should proactively manage sessions.

[AkiKurisu]

The next fix will optimize MCP client logic based on the official specification https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle.