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 modelcontextprotocol/rust-sdk#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 6b3018b, introduced by #3634

Details

$ 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