MCP Gateway v0.1.8: tools/call still returns HTTP 400 for Streamable HTTP backends

[lupinthe14th]

Summary

After upgrading to gh-aw v0.53.2 (MCP Gateway v0.1.8), the tools/list request to HTTP-based MCP servers now succeeds (thanks to the fix in gh-aw-mcpg#1559). However, tools/call requests still fail with HTTP 400: Bad Request.

Environment

• gh-aw: v0.53.2
• MCP Gateway: v0.1.8
• Backend: Datadog MCP Server (Streamable HTTP transport)

Steps to Reproduce

1. Configure an HTTP-based MCP backend (e.g., Datadog MCP Server)
2. Run a workflow that calls a tool from the HTTP backend

Expected Behavior

tools/call should succeed using the session established during tools/list.

Actual Behavior

• tools/list succeeds and returns the full tool catalog
• tools/call fails with HTTP 400: Bad Request (same error code -32603)

Gateway Logs

tools/list (success)

[INFO] server session connected session_id=""
[INFO] session initialized
[DEBUG] rpc datadog←resp {tools: [...]} // Full tool list returned

tools/call (failure)

[DEBUG] GetOrLaunchForSession called: server=datadog, session=***
rpc datadog→tools/call search_datadog_monitors
MCP error 0: backend error: code=-32603, message=HTTP 400: Bad Request

Analysis

The fix in gh-aw-mcpg#1559 removed the fake session ID injection in registerToolsFromBackend(), which resolved the tools/list issue. However, the tools/call code path may have a similar issue where the session ID from the initial initialize handshake is not correctly propagated to subsequent tools/call requests.

The GetOrLaunchForSession call at tools/call time suggests the gateway may be creating a new connection/session instead of reusing the one established during tools/list, which would cause the Datadog server to reject the request with HTTP 400 (invalid session ID).

Related

• gh-aw-mcpg#1559 (fix for tools/list, merged)
• Copilot CLI does not recognize HTTP-based custom MCP server tools despite successful gateway connection #18712 (original issue, closed)