vMCP health probe uses HTTP GET, breaking backends that only accept POST (e.g. Tableau MCP)

[yoojiyeon-ktc]

Bug description

VirtualMCPServer health probes use HTTP GET against backend URLs and treat non-200 responses as unhealthy. However, in the MCP Streamable HTTP transport, GET is defined as an optional mechanism for opening server-initiated SSE streams. Servers that do not support SSE streams may legitimately return 405 Method Not Allowed (per spec) or 400 Bad Request (e.g. when session management is enabled and no session ID is provided). A GET failure therefore does not imply that the MCP backend is unavailable.

The backend is then marked unavailable and excluded from tool routing, even though POST-based MCP calls (initialize, ping, tools/list, tools/call) all succeed.

Root cause: vMCP is using a transport-level GET response as a backend health signal, although GET semantics are optional/use-case-specific in Streamable HTTP and do not indicate whether the backend can process MCP JSON-RPC requests.

This is distinct from #6339 (probing unadvertised capabilities) — here the probe method itself produces a false-negative health signal.

Steps to reproduce

1. Deploy Tableau MCP (ghcr.io/tableau/tableau-mcp) as a standalone Deployment with TRANSPORT=http, listening on port 3927 at path /tableau-mcp.
2. Register it via MCPServerEntry with remoteUrl: http://tableau-mcp.<ns>.svc.cluster.local:3927/tableau-mcp and transport: streamable-http.
3. Observe VirtualMCPServer status:

$ kubectl get virtualmcpserver mcphub -o jsonpath='{.status.discoveredBackends[?(@.name=="tableau-mcp")]}'
{"name":"tableau-mcp","status":"unavailable","message":"Backend unavailable"}

4. Verify the backend is actually healthy:

# MCP ping — succeeds (no authentication or session required)
curl -X POST http://tableau-mcp:3927/tableau-mcp \
  -H "accept: application/json, text/event-stream" \
  -H "content-type: application/json" \
  -d '{"jsonrpc":"2.0","id":"1","method":"ping"}'
# → {"jsonrpc":"2.0","id":"1","result":{}}

# HTTP GET — rejected (this is what the health probe sends)
curl http://tableau-mcp:3927/tableau-mcp
# → HTTP 400: "Invalid or missing session ID"

The flow:

vMCP health probe
 │
 │ GET /tableau-mcp
 ▼
Tableau MCP → 400 (no session ID on GET)
 │
 └─→ vMCP marks "unavailable"
     └─→ tools/list excludes Tableau tools

But actual MCP communication works:

MCP Client
 │
 │ POST /tableau-mcp {"method":"ping"}
 ▼
Tableau MCP → 200 + {"result":{}}

5. Tools from this backend do not appear in the vMCP's tools/list response to clients.

Why GET fails on this backend

In Streamable HTTP, a server that supports GET uses it to open an SSE stream for server-initiated messages. A server that does not support SSE streams returns 405 Method Not Allowed per the MCP spec. Tableau MCP returns 400 because it requires a session ID (issued during initialize) for all requests, and a bare GET without a session context is meaningless.

Both 405 and 400 are legitimate responses from a healthy backend that simply does not offer SSE streams or requires session context.

Expected behavior

The health probe should use an MCP-level check (e.g. POST with {"jsonrpc":"2.0","id":"healthcheck","method":"ping"}) rather than HTTP GET. The MCP specification defines ping as a standard utility method that requires no authentication or session, making it the natural health check primitive.

Alternatively, allow per-backend health probe configuration (method, path, or disable).

Actual behavior

The health probe sends GET to the backend URL. Backends that legitimately reject GET (no SSE support, or session-managed endpoints) return 400/405, and vMCP marks them unavailable, blocking all tool routing to that backend.

Workaround

None that preserves correct health semantics. An nginx sidecar returning 200 on GET masks real failures and defeats the purpose of health checking.

Environment

• ToolHive: v0.46.0 (operator + CRDs)
• Kubernetes: v1.33.7
• Backend: ghcr.io/tableau/tableau-mcp:latest (v4.7.1)
• Resource type: MCPServerEntry (also reproducible with MCPRemoteProxy)

References

• MCP Streamable HTTP spec — GET returns 405 Method Not Allowed when SSE is not supported: https://modelcontextprotocol.io/specification/draft/basic/transports/streamable-http
• Tableau MCP deployment guide — GET returns "Method not allowed" as expected behavior, recommends ping for health checks: https://github.com/tableau/tableau-mcp/blob/main/docs/docs/enterprise/tableau-cloud.md
• Related: vMCP marks backends degraded for capabilities they never advertised #6339 (vMCP marks backends degraded for capabilities they never advertised)
• Related: Prefer CIMD over DCR when the proxy acts as OAuth client to remote MCP servers #4826 (CIMD upstream support, which would allow using hosted mcp.tableau.com directly)

[jstar0]

I'd like to work on this issue. I plan to keep the first slice narrow: align the vMCP health signal with an MCP-level request and add focused regression coverage for healthy POST-only backends. Please assign the issue if this scope is appropriate; I'll wait for maintainer confirmation before starting implementation.

[blkt]

@jstar0 feel free to open a PR! 🚀

[blkt]

Thanks for the detailed report. The protocol concern is valid: a failed bare GET is not a reliable MCP health signal. MCP revisions through 2025-11-25 allowed servers without a standalone SSE stream to return 405, while 2026-07-28 removes the GET endpoint entirely.

One correction: ping is not universally sessionless or unauthenticated, and it was removed in 2026-07-28. Health checks need to be protocol-version aware.

Current ToolHive main uses ListCapabilities for health checks and disables standalone SSE GET for that path, so the reported GET behavior does not appear to apply to the current implementation.