Goose stuck "thinking" calling Jenkins MCP server after upgrading from Goose 1.2.0 to 1.3.0

[batmat]

I configured Goose 1.1.4 a few weeks back to use https://github.com/jenkinsci/mcp-server-plugin using Streamable HTTP, it was working great.

I upgraded to latest 1.7.0 and saw Goose was getting stuck.

So I went on checking precisely when it started breaking, and it is on 1.3.0 that this stops working for me. (and is still broken with latest 1.7.0)

A clear and concise description of what the bug is.

To Reproduce Steps to reproduce the behavior:

1. Install the Jenkins MCP server plugin onto a Jenkins instance
2. Create an access token
3. Run Goose 1.2.0
4. Create a Goose Extension for the Jenkins MCP server using Streamable HTTP (pass a typical base64 encoded password after creating an access token)
5. Ask "list jenkins jobs"
6. this works
7. Upgrade Goose to 1.3.0+
8. This loops forever with "Goose is thinking"

Screenshots If that helps, here's what the config looks like:

Please provide following information:

• OS & Arch: [Mac M4 pro, Sequoia 15.6.1]
• Interface: [UI]
• Version: [e.g. v1.3.0]
• Extensions enabled: [Jenkins MCP server plugin]
• Provider & Model: [gtp-4-o]

Additional context I'm happy to provide more info or details or anything on how to reproduce .

[rsandell]

Looks like the 0.6.1 release of rmcp has a "fix" related to this? https://github.com/modelcontextprotocol/rust-sdk/releases/tag/rmcp-v0.6.1 https://github.com/modelcontextprotocol/rust-sdk/pull/390

[batmat]

I just saw something that caught my eyes on the Jenkins logs when Goose starts. Interestingly, note how version=1.2.0 for Goose 1.2.0, but is always 0.1.0 for Goose 1.3.0 or 1.7.0

With Goose 1.2.0 (which works)

2025-09-02 11:28:03.737+0000 [id=95]	INFO	i.m.server.McpAsyncServer#lambda$asyncInitializeRequestHandler$5: Client initialize request - Protocol: 2025-03-26, Capabilities: ClientCapabilities[experimental=null, roots=null, sampling=null, elicitation=null], Info: Implementation[name=goose, title=null, version=1.2.0]

With Goose 1.7.0, which does NOT work:

2025-09-02 11:29:07.459+0000 [id=16]	INFO	i.m.server.McpAsyncServer#lambda$asyncInitializeRequestHandler$5: Client initialize request - Protocol: 2025-03-26, Capabilities: ClientCapabilities[experimental=null, roots=null, sampling=null, elicitation=null], Info: Implementation[name=goose, title=null, version=0.1.0]

[cbruyndoncx]

there is a move to use the rmcp crate, perhaps the cause for the version number diff

have you tried https endpoint ?

[rsandell]

I just suggested rmcp as the culprit because it was related and had a bump to v. 0.5.0 in the goose 1.3.0 release. :)

[cbruyndoncx]

I just suggested rmcp as the culprit because it was related and had a bump to v. 0.5.0 in the goose 1.3.0 release. :)

yeah, i somehow missed your line there, Sorry !

[batmat]

Alright, it took me a bit of time because I know nothing about Rust and I was using the Goose-UI (and I couldn't figure how to build it using cargo) and I had to learn to use the CLI. I just git bisected and it matches Bobby's theory above: the faulty commit is 6b3018b77a819d2bc8da7d16b5bea60d985b9cd5, introduced by https://github.com/block/goose/pull/3634

$ git bisect log 
git bisect start
# status : en attente d'un commit bon et d'un commit mauvais
# good: [a66f2ace6f1ca3f315ba9b12ec65ee152f82a716] tests: Add missing `#[serial]` to two tests (#3816)
git bisect good a66f2ace6f1ca3f315ba9b12ec65ee152f82a716
# status : en attente d'un mauvais commit, 1 commit bon connu
# bad: [15bfb9ef810b29c8bd36f49710669c08d7c51348] Use cross in linux bundle workflow (#3950)
git bisect bad 15bfb9ef810b29c8bd36f49710669c08d7c51348
# good: [a33460244cb62ad567f8c2ce6bc742cc65843cdf] Ensure more client (#3787)
git bisect good a33460244cb62ad567f8c2ce6bc742cc65843cdf
# bad: [c42c2ab6cdf932253535151bd3f24da3465e2e63] docs: Adding dev.to Tutorial & Update CLI Component (#3828)
git bisect bad c42c2ab6cdf932253535151bd3f24da3465e2e63
# bad: [48a38dc034d9356bb9c6bf297df31b7f51d3a62e] Chore: apply more clippy rules to prevent from code complexity (#3813)
git bisect bad 48a38dc034d9356bb9c6bf297df31b7f51d3a62e
# bad: [d93063b686a110367d373c0f2ed4ab1acb937bce] Override session name generator for ollama provider (#3710)
git bisect bad d93063b686a110367d373c0f2ed4ab1acb937bce
# good: [7b67007a54e1e38b9e25555e44847b0920682ce5] Use PR number for concurrency group (#3790)
git bisect good 7b67007a54e1e38b9e25555e44847b0920682ce5
# bad: [7e7b19db9e442b71f2addb214ff9ae9e3ad17f0a] docs: update custom extension project setup (#3793)
git bisect bad 7e7b19db9e442b71f2addb214ff9ae9e3ad17f0a
# bad: [6b3018b77a819d2bc8da7d16b5bea60d985b9cd5] Swap MCP client implementations to rmcp (#3634)
git bisect bad 6b3018b77a819d2bc8da7d16b5bea60d985b9cd5
# first bad commit: [6b3018b77a819d2bc8da7d16b5bea60d985b9cd5] Swap MCP client implementations to rmcp (#3634)

[batmat]

I tried locally to bumprmcp from 0.6.0 to 0.6.1, but the build fails with 22 errors 😅. And fixing this code is beyond my reach as I wrote just above. (I may need to try and use an LLM to make sense of this, but I'm lacking time to dive into this just now 😅)

[kgeis]

I think this issue might not just be Jenkins but all Spring AI MCP servers. I have a custom server that is freezing like this with 1.8.0 and 1.9.0. My server works with MCP Inspector, Cherry Studio, and Gemini CLI.

[kgeis]

#4792 pull request to upgrade rmcp to 0.7.0

[DOsinga]

#4792 pull request to upgrade rmcp to 0.7.0

does that mean this solves it?

[DOsinga]

we should even upgrade to 0.8

[kgeis]

#4792 pull request to upgrade rmcp to 0.7.0

does that mean this solves it?

I can't confirm that, but it's a good guess and probably a good direction for Goose. Sorry, I downloaded the release/1.10.0 branch and built it, but I can't get it to give me a prompt with or without the MCP server. 🤷‍♂️

[kgeis]

OK, I was able to confirm that release 1.10.0 with rmcp 0.7.0 does not fix my issue connecting to a MCP server built with Java and Spring AI.

[jamadeo]

I've tested HTTP servers with authorization headers and they appear to be set, so I don't think that is the problem.

@kgeis what does your extension config look like? Is it using HTTP or STDIO? Does goose say the extension is added correctly before the chat stalls?

[alexhancock]

@kgeis I am also curious for the answer's to @jamadeo's Qs above.

Also, is there any MCP server that repros this without setting up a jenkins instance?

[kgeis]

I've created a minimal Spring AI MCP server here: kgeis/mcp-demo. I've included instructions to run it with Java/Gradle or just Docker. Run it, and a "hello world" MCP server will listen on http://localhost:8080/mcp.

I have only tried using the streamable HTTP transport. Here's the output of goose before it hangs:

% goose
starting session | provider: ollama model: llama3.2
    logging to /Users/kgeis/.local/share/goose/sessions/20251020_112344.jsonl
    working directory: /Users/kgeis/temp/rmt-mcp-server-usage

Here's my extension config:

extensions:
  hello-world:
    available_tools: []
    bundled: null
    description: null
    enabled: true
    env_keys: []
    envs: {}
    headers: {}
    name: hello-world
    timeout: 300
    type: streamable_http
    uri: http://localhost:8080/mcp

[jamadeo]

Thank you @kgeis , that's been very helpful!

I tracked this issue down to this part of the transport flow: https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#listening-for-messages-from-the-server

goose, using rmcp, issues a GET to open an event stream, but the spring server never responds - it just hangs. I can reproduce this with the MCP inspector as well, but the difference is that the inspector is still functional in this state, while goose is not.

I'm not sure why the spring server is not returning an event stream or a 405 in response, but that seems to be causing the hang

[kgeis]

I've been able to reproduce the server not responding using curl. I'm not sure it's hung. Server stack trace shows nothing out of the ordinary for a listening Tomcat server.

I see the spec doesn't say that a GET needs to return immediately. I think that Spring is leaving the stream open and will send headers along with the first message on the stream.

[alexhancock]

@kgeis @jamadeo What should the resolution for this be in your all's opinion? Should we do something in https://github.com/modelcontextprotocol/rust-sdk or shouldn't the server send a response to the initialize request?

[jamadeo]

I think rmcp should not block on waiting for this response. I agree with @kgeis that the spec does not say the server must immediately write headers for the event stream request (although it would help).

[kgeis]

That it works in major clients like Cherry Studio, Gemini CLI, and Claude Code suggests that the TypeScript SDK handles it differently than the Rust SDK. I'd think the TypeScript SDK might be the de facto reference implementation, and maybe rmcp should follow.

[jamadeo]

https://github.com/modelcontextprotocol/rust-sdk/pull/553 should fix this