OpenHands compatibility?

[jdlake]

Is anybody using this with OpenHands (1.12.0 Agent Canvas)? I just continually get:

Connection failed: McpError: Authentication failed: failed to create request: parse "**********/api/auth/login": first path segment in URL cannot contain colon

After adding the SHTTP MCP server in the OpenHands GUI. The MCP is running in a docker container with the same network as the openhands container.

If however, I run

docker exec -it openhands -i -X POST "http://mcp-umami:8080/mcp" `
>>   -H "Content-Type: application/json" `
>>   -H "X-Umami-Host: https://blank.com" `
>>   -H "X-Umami-Username: username" `
>>   -H "X-Umami-Password: password" `
>>   -d "{\`"jsonrpc\`":\`"2.0\`",\`"id\`":1,\`"method\`":\`"initialize\`",\`"params\`":{\`"protocolVersion\`":\`"2024-11-05\`",\`"capabilities\`":{},\`"clientInfo\`":{\`"name\`":\`"test\`",\`"version\`":\`"1.0.0\`"}}}"

It works fine.

[Macawls]

Thanks for the detailed report — the raw-curl-works/OpenHands-fails asymmetry made this really diagnosable.

What's happening

Two OpenHands quirks likely combine to produce your error:

1. Header entry format. The OpenHands MCP settings form parses headers as KEY=VALUE (equals-separated, env-var-style), not Key: value. A line like X-Umami-Host: https://blank.com is silently discarded (empty key). Try entering it as:

   X-Umami-Host=https://blank.com
   X-Umami-Username=<user>
   X-Umami-Password=<pass>
   

2. Redacted-secret placeholder. OpenHands wraps MCP header values in SecretStr and there's a documented bug family where the placeholder ********** leaks back as the "real" value on subsequent edits/saves (see PR #16144, SDK #4096, SDK PR #4097). The literal ********** in your error message is that constant. If you edit-and-resave a server entry, the header may go out as ********** on the next attempt.

What we're changing on our side

Even though the root cause is client-side, our current error (first path segment in URL cannot contain colon) is opaque. I've opened #31 to validate X-Umami-Host up front and return actionable messages for both failure modes — you'll get either "host must include an http:// or https:// scheme (got \"...\")" or a message specifically pointing at the OpenHands redaction placeholder.

What to try now

1. In the OpenHands settings form, re-enter each header as KEY=VALUE on its own line (with https:// scheme on the host), then save.
2. Immediately hit Test. If it fails again after the value shows as ********** in the edit view, that's the OpenHands persistence bug — as a workaround, delete and re-add the server entry rather than editing it.

Once #31 lands and we cut a release, you'll get a clear error message in either case instead of the current Go URL parse dump.

[Macawls]

Fix shipped in v1.6.2 via #31.

The cryptic net/url parse error you'd hit when X-Umami-Host was missing a scheme (or was set to the redacted ********** placeholder that OpenHands leaks back after an edit/save cycle — see OpenHands PR #16144, SDK issue #4096, SDK PR #4097) is replaced with an actionable message naming the offending value and pointing at the likely cause.

Note that OpenHands' MCP settings form still parses headers as KEY=VALUE rather than Key: value, so HTTP-style entries are silently discarded on their side — that part needs to be fixed upstream. This release just makes the failure diagnosable instead of opaque.