feat(extensions): add Java/JDK support for MCP servers

[tcollier]

Update 2025-03-24

I've worked past the node integrity issue and was able to test the GUI on my machine. After adding 2 new commits to resolve a couple of issues, I have successfully added a Java-based extension to Goose with jbang. I would appreciate reviewers also testing the GUI in the same manner.

Screen.Recording.2025-03-24.at.2.25.43.PM.mov

Description

This PR adds support for Java and Kotlin-based MCP servers on Linux and macOS systems. It enables users to run JVM-based MCP servers using jbang, following the same pattern established by our npx and uvx integrations.

There are official Kotlin and Java MCP SDKs. Developers are already publishing MCP servers using those, so Goose needs the ability to install JDK-based extension to get access to them.

Note to Reviewers

I've tested this on my machine (see Testing section below), but would appreciate if others could test on M3 Macbooks, Linux machines or other supported (non-Windows) platforms

Key Features

• Hermit-managed OpenJDK installation (version 17)
• Local jbang installation in ~/.config/goose/mcp-hermit
• Support for custom registries via GOOSE_JBANG_REGISTRY environment variable
• Improved UX with automatic --fresh and --quiet flags

Example Usage

goose session --with-extension "jbang jdbc@quarkiverse/quarkus-mcp-servers"

Documentation

• Added Java/JDK examples to extension documentation
• Updated Docker configuration to include OpenJDK and jbang
• Added notes about platform support (Linux/macOS only for now)

Testing

Tested on an M2 Mac with Sequoia 15.3.2

CLI

# The `--quiet` option for `jbang` prevents a "trust this site" modal from popping up, it's not required
./target/debug/goose run \
    --text "What tools do you have available?" \
    --with-extension "jbang --quiet jdbc@quarkiverse/quarkus-mcp-servers"

starting session | provider: databricks model: goose

[snip]

I have access to several SQL database management tools that work with an H2 database. Here are the available tools:

1. **Database Information Tool**
   - Function: `pdkcpy1r__database_info`
   - Description: Provides information about the database, including SQL dialect and keywords
   - No parameters required

2. **List Tables Tool**
   - Function: `pdkcpy1r__list_tables`
   - Description: Lists all tables in the database
   - No parameters required

[snip]

The database is running H2 version 2.3.232, supports transactions, and is not read-only. Would you like me to demonstrate any of these tools or help you with a specific database operation?

GUI

• TODO: just run-ui is currently failing with an npm integrity check.

Platform Support

✅ Linux
✅ macOS
❌ Windows

Why jbang?

We evaluated several options for running Java/Kotlin MCP servers, including:

• Traditional Maven/Gradle project setup
• Java Application Packager (jpackage)
• SDKMan for JDK management
• GraalVM native-image compilation
• jbang

We chose jbang because it offers several key advantages for our use case:

1. Zero Installation Model: Like npx for Node.js and uvx for Python, jbang allows running Java applications directly from source or JARs without requiring a local Java development environment. This aligns perfectly with our existing pattern for other language integrations.

2. Script-First Approach: jbang treats Java code as scripts that can be run directly, making it ideal for MCP servers that are essentially single-purpose applications. This matches our philosophy of making extension development as straightforward as possible.

3. Built-in Dependency Management: jbang automatically handles dependencies declared in the code or catalog, similar to how npx manages npm packages. This eliminates the need for complex build tool configurations.

4. Catalog Support: jbang's catalog feature allows publishing and running applications using simple aliases (e.g., jdbc@quarkiverse/quarkus-mcp-servers), making distribution and versioning of MCP servers much simpler.

5. Cross-Platform: While our current implementation is Linux/macOS only, jbang itself is cross-platform, making future Windows support straightforward to implement.

Other solutions either required more complex setup (Maven/Gradle), didn't handle dependencies as elegantly (jpackage), or were too focused on development environments rather than runtime execution (SDKMan). GraalVM native-image, while powerful, would require compilation for each platform and doesn't align with our goal of running servers directly from source or JARs.

[michaelneale]

nice - looks good to me and jbang shim will help for cases where people do need a jvm based MCP but dont want to go through all the setup

[angiejones]

thank you from a JVM girlie! ❤️

[angiejones]

tested on mac

$ goose session --with-extension "jbang jdbc@quarkiverse/quarkus-mcp-servers"
Failed to start extension: Failed to start extension: Transport error: Stdio process error: No such file or directory (os error 2)

[tcollier]

tested on mac

$ goose session --with-extension "jbang jdbc@quarkiverse/quarkus-mcp-servers"
Failed to start extension: Failed to start extension: Transport error: Stdio process error: No such file or directory (os error 2)

Hi @angiejones, thanks for testing this locally! This is my first contribution to Goose and my understanding of the desired behavior here is still evolving.

Since you posted your test results, I discovered that I have a jbang installation through homebrew. When I uninstall that, I see the same behavior that you are experiencing.

However, I also have uv/uvx installed via homebrew. When I uninstall that, I get the same error message when trying to use Goose with a Python-based extension. For example

% goose session --with-extension "uvx mcp-server-git"
Failed to start extension: Failed to start extension: Transport error: Stdio process error: No such file or directory (os error 2)

When first posting the PR, my assumption was the the shim would kick in for both the GUI and the CLI. Though upon further inspection, these do not appear to be used in the CLI.

Is it sufficient to claim Java/Kotlin support if the CLI does not make use of the shim?