WG - Model Context Protocol (MCP) Support

[cescoffier]

Objective

The main objective of this working group is to provide a robust and evolving implementation of the Model Context Protocol (MCP) client and server in Quarkus, aligned with the specification and its ecosystem.

The Problem

As large language model (LLM) applications evolve, interoperability and agent communication are increasingly standardized through protocols such as MCP or A2A. While MCP is gaining traction across ecosystems, we need to enhance the Quarkus MCP integration to align with the protocol’s evolution and support both client and server roles.

Quarkus needs to fill this gap by:

• Supporting MCP natively to ease the integration of AI-infused applications.
• Enabling agentic workflows and AI orchestration within Java/Quarkus applications.
• Ensuring compatibility with other platforms adopting MCP.

A lack of such support limits the potential of Quarkus for building interoperable AI-infused applications.

The Proposed Solution

This working group will provide official, first-class support for the Model Context Protocol in Quarkus, covering both client and server roles. The group will:

• Track and contribute to the MCP specification.
• Implement compliant server and client components.
• Explore protocol extensions (e.g., WebSocket transport).
• Evaluate trade-offs and limitations (e.g., resumability).
• Investigate architectures for scalable, stateful MCP servers.

The implementation will aim to be modular, specification-aligned, and extensible, providing a foundation for agentic and protocol-driven AI integrations.

Definition of Done

This working group will be considered complete when the following are delivered:

• A production-ready MCP server implementation (compliant with the latest stable spec).
• A production-ready MCP client implementation.
• Optional features and extensions implemented (e.g., WebSocket transport).
• Enterprise features such as tracing, logging, auditing, and security
• ADRs documenting key design decisions (e.g., state handling, transport options, resumability).
• User-facing documentation and developer guides.
• Examples and tests demonstrating interoperability with existing MCP clients/servers.
• Blog post and/or demo showing usage in a real-world AI use case.

Scope of Work

In Scope:

• MCP client and server implementations.
• Extensions to the base protocol (e.g., transport alternatives).
• Design decisions about stateful agents, resumability, etc.
• Spec tracking and active participation in the MCP community.
• Documentation and examples for developers.

Out of Scope:

• Implementations of other protocols (e.g., ACP, A2A (probably tracked in another working group)).
• Agent behavior logic or planning engines.
• UIs or graphical tools beyond what is needed for testing/debugging.

Organizing the Work

Communication and Transparency

• Coordination will be tracked using GitHub issues and a GitHub project board.
• Development will be done in the Quarkiverse MCP project.

Points of Contact:
Martin Kouba (@mkouba)
Jan Martiska (@jmartisk)
Clement Escoffier (@cescoffier )

Expected Timeline:

This is a long-running working group as specification updates are published regularly. We will see when we consider this effort done (when the specification will be mature enough)

Potential Outcomes & Deliverables

• quarkus-langchain4j-mcp, quarkus-mcp-server, and quarkus-mcp-servers extensions/repositories
• Reusable transport and message codec modules
• Quarkus blog post and Dev UI integration

[maxandersen]

+1

would it make sense to include https://github.com/quarkiverse/quarkus-mcp-servers in this?

[cescoffier]

Definitely.

[cescoffier]

@mkouba @jmartisk I think we need to get this one going.

• We need to discuss statelessness, as it becomes a stringent requirement
• I would like to explore WebSocket transport (I know that @mkouba has already implemented the server side)

[jmartisk]

I guess I could start looking at the client-side websocket transport this week.

[jmartisk]

I guess it won't be hard to implement, except that we will again probably need two implementations :/ upstream lc4j one with okhttp and quarkus one based on websockets-next.

[jmartisk]

Or maybe I could go with the JDK HTTP client on both sides to make it simpler, but of course, Quarkus should eat its own dogfood...

[mkouba]

Or maybe I could go with the JDK HTTP client on both sides to make it simpler, but of course, Quarkus should eat its own dogfood...

I don't think that you need to use WS Next here. It's more suitable for user apps. The truth is I did use it for the server side but it's a bit awkward because we generate a class that it processed by WS Next 🤷.

[jmartisk]

Ok, I'll try it with the JDK HTTP client then, that should work in plain lc4j as well as in Quarkus...