LangChain4j StreamableHttpMcpTransport: protocol detection for Sume

Java teams reach Sume's hosted MCP server through LangChain4j's Streamable HTTP transport. The LangChain4j MCP tutorial describes a builder with url, logRequests and logResponses, plus a protocol detection step on connect, read 2026-10-03. Sume's server speaks Streamable HTTP at https://mcp.sume.com/mcp, per the Sume MCP overview, so the transport is the right match. What needs care is startup behaviour and what the logs capture.

What the tutorial says about detection

The tutorial states that protocolDetectionTimeout defaults to the initializationTimeout, which is 30 seconds, and that detection costs one extra round trip. Setting protocolVersion explicitly skips it. It also says subsidiaryChannel(true) is off by default. This post does not claim which protocol versions Sume's server accepts, because the Sume docs do not list them; test against the server before pinning a value.

Be careful with request and response logging

logRequests and logResponses are useful while you wire things up, but a Sume tool call carries an idempotency_key, prompts and result URLs. Turn them on in a test profile, not in production, and check what your logging backend does with headers before you add a credential. Sume accepts either Authorization: Bearer or x-api-key, but not both on the REST API.

Long jobs from a Java client

Sume's create tools return a job id quickly, and jobs_wait holds for 50 seconds by default with a 55-second cap, according to the tools and gates page. Keep your tool-call timeout above that, loop on wait_slice_expired with the same ids, and never resubmit the create. A transport error such as 524 says nothing about the job.

If the JVM exits mid-wait, the job continues. Persist the job id returned from the create and resume with jobs_result or another jobs_wait later.

• Pin protocolVersion once you have tested it.
• Keep initializationTimeout modest so a bad URL fails fast.
• Log only in tests.
• Persist job ids before the first wait.