aldettinger opened a new issue, #9342:
URL: https://github.com/apache/camel-quarkus/issues/9342
Problem
_camel-quarkus-mcp-server_ currently depends on _quarkus-mcp-server-http_,
which forces the HTTP transport on all users and makes camel-quarkus
responsible for CVEs in that transport layer. The extension code itself uses
only types from _quarkus-mcp-server-core_ (ToolManager, ToolResponse,
TextContent) — the HTTP dependency is a gratuitous coupling.
Design rationale
The upstream Camel _McpServerEngine_ SPI explicitly separates bridge (tool
selection, execution, timeout) from transport. The _QuarkusMcpServerEngine_ is
a "native engine" — it delegates to the quarkiverse ToolManager and returns
consumesServingConfiguration() = false, meaning Camel's own serving
configuration is ignored in favor of _quarkus.mcp.server.*_. The engine never
touches transport; that is Quarkus's responsibility. Depending on
_quarkus-mcp-server-core_ only aligns the dependency graph with this
already-established contract.
Users choose their transport by adding _quarkus-mcp-server-http_,
_quarkus-mcp-server-stdio_, or _quarkus-mcp-server-websocket_ to their own
application POM — the same pattern Quarkus uses elsewhere (e.g. choosing a REST
JSON provider).
Changes required
Extension runtime (extensions/mcp-server/runtime/pom.xml):
- Replace io.quarkiverse.mcp:quarkus-mcp-server-http with
io.quarkiverse.mcp:quarkus-mcp-server-core
Extension deployment (extensions/mcp-server/deployment/pom.xml):
- Replace _io.quarkiverse.mcp:quarkus-mcp-server-http-deployment_ with
_io.quarkiverse.mcp:quarkus-mcp-server-core-deployment_
Runtime BOM (poms/bom/pom.xml):
- Replace the two _quarkus-mcp-server-http_ /
_quarkus-mcp-server-http-deployment_ entries with _quarkus-mcp-server-core_ /
_quarkus-mcp-server-core-deployment_ (same version
${quarkiverse-mcp-server.version})
Integration tests (integration-tests/mcp-server/pom.xml):
- Add _io.quarkiverse.mcp:quarkus-mcp-server-http_ as a test-scope
dependency (the test app needs a transport to run against; existing test code
uses McpAssured.newStreamableClient() over HTTP)
Extension metadata (extensions/mcp-server/runtime/pom.xml description +
quarkus-extension.yaml):
- Update description from "Expose ai-tool routes as MCP tools over
streamable HTTP" to "Expose ai-tool routes as MCP tools" (transport is no
longer prescribed)
- Run mvn -N cq:update-quarkus-metadata to regenerate quarkus-extension.yaml
No Java code changes needed — all imports already resolve against
quarkus-mcp-server-core.
Verification
1. mvn clean install -pl
extensions/mcp-server/runtime,extensions/mcp-server/deployment -am -Dquickly —
compiles successfully
2. mvn verify -pl integration-tests/mcp-server — JVM tests pass
3. mvn verify -pl integration-tests/mcp-server -Dnative — native tests pass
The documentation would probably need updates. Not sure it still make sense
to document dual transport support if we adopt this architecture.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
