This is an automated email from the ASF dual-hosted git repository.
jamesnetherton pushed a commit to branch 3.40.x
in repository https://gitbox.apache.org/repos/asf/camel-quarkus.git
The following commit(s) were added to refs/heads/3.40.x by this push:
new d897b0688a mcp-server: Document the mcp-server extension as streamable
HTTP only. Related to #9342.
d897b0688a is described below
commit d897b0688ae79643baa6ad3d143244751b528d52
Author: Alexandre Gallice <[email protected]>
AuthorDate: Mon Nov 2 08:35:25 2026 +0100
mcp-server: Document the mcp-server extension as streamable HTTP only.
Related to #9342.
Co-authored-by: Claude Opus 5 <[email protected]>
---
.../pages/reference/extensions/mcp-server.adoc | 85 ++++------------------
.../mcp-server/runtime/src/main/doc/intro.adoc | 12 +--
.../mcp-server/runtime/src/main/doc/usage.adoc | 72 ++----------------
3 files changed, 28 insertions(+), 141 deletions(-)
diff --git a/docs/modules/ROOT/pages/reference/extensions/mcp-server.adoc
b/docs/modules/ROOT/pages/reference/extensions/mcp-server.adoc
index 080044d97d..9528fb1b9e 100644
--- a/docs/modules/ROOT/pages/reference/extensions/mcp-server.adoc
+++ b/docs/modules/ROOT/pages/reference/extensions/mcp-server.adoc
@@ -24,12 +24,12 @@ extension. No route is needed for the server itself: add
the extension, tag
the `ai-tool` routes to expose, and any MCP client (another Camel
application, an IDE, a coding agent) can discover and call them.
-Tool semantics — tag-based opt-in (the untagged default pool is never
-exposed), flat-namespace collision refusal, per-call timeout and error
-sanitization — are owned by the runtime-agnostic `camel-mcp-server-api`
-bridge and are identical on every Camel runtime. Serving concerns (endpoint
-path, transports, authentication) are owned by quarkus-mcp-server and
-configured via `quarkus.mcp.server.*`.
+The server is exposed over streamable HTTP. Tool semantics — tag-based
+opt-in (the untagged default pool is never exposed), flat-namespace
+collision refusal, per-call timeout and error sanitization — are owned by
+the `camel-mcp-server-api` bridge. Serving concerns (endpoint path,
+authentication) are owned by quarkus-mcp-server and configured via
+`quarkus.mcp.server.*`.
[id="extensions-mcp-server-whats-inside"]
@@ -98,9 +98,10 @@ arrive as message headers in the route
(`${header.customerId}`).
=== Combining the Camel and quarkus-mcp-server configuration
The configuration is split by ownership: `quarkus.camel.mcp-server.*`
-decides *which tools exist and how they execute* (identical semantics on
-every Camel runtime), while `quarkus.mcp.server.*` decides *how the server
-is exposed*. Both are set side by side in `application.properties`:
+decides *which tools exist and how they execute* (semantics owned by the
+`camel-mcp-server-api` bridge), while `quarkus.mcp.server.*` decides *how
+the server is exposed*. Both are set side by side in
+`application.properties`:
[source,properties]
----
@@ -120,7 +121,7 @@ quarkus.mcp.server.traffic-logging.text-limit = 200
See the
https://docs.quarkiverse.io/quarkus-mcp-server/dev/index.html#configuration-reference[quarkus-mcp-server
configuration reference]
-for the full list of `quarkus.mcp.server.*` properties (transports, dev UI,
+for the full list of `quarkus.mcp.server.*` properties (dev UI,
authentication, guardrails, pagination, timeouts).
[id="extensions-mcp-server-usage-connecting-mcp-clients"]
@@ -155,63 +156,9 @@ A coding agent or IDE is configured with the same URL,
e.g. in an
}
----
-[id="extensions-mcp-server-usage-serving-over-stdio"]
-=== Serving over stdio
-
-Out of the box the tools are served over streamable HTTP. MCP clients that
-launch the server as a subprocess speak over stdin/stdout instead — add the
-stdio transport alongside the extension:
-
-[source,xml]
-----
-<dependency>
- <groupId>io.quarkiverse.mcp</groupId>
- <artifactId>quarkus-mcp-server-stdio</artifactId>
- <!-- the same version as the quarkus-mcp-server-http extension pulled in
- by camel-quarkus-mcp-server; the transports share their core module
-->
- <version>1.13.1</version>
-</dependency>
-----
-
-The stdio transport is active as soon as it is on the classpath
-(`quarkus.mcp.server.stdio.enabled` defaults to `true`), and the same Camel
-tools are then served over both transports. To serve over stdio *only*,
-disable the HTTP transport of the default MCP server:
-
-[source,properties]
-----
-quarkus.mcp.server."<default>".http.enabled = false
-----
-
-The server name of the default MCP server is the literal string
-`<default>`, so it has to be quoted. Conversely,
-`quarkus.mcp.server.stdio.enabled = false` keeps the stdio extension on the
-classpath without activating it, which is useful when the same application
-is deployed both ways.
-
-Because stdout carries the MCP protocol, nothing else may be written to it;
-`quarkus-mcp-server-stdio` takes care of this by routing console logging to
-stderr. A stdio server is typically built as a native executable and
-launched by the client:
-
-[source,json]
-----
-{
- "mcpServers": {
- "my-integration-app": {
- "command": "/path/to/target/my-integration-app-1.0.0-runner"
- }
- }
-}
-----
-
-See the
-https://docs.quarkiverse.io/quarkus-mcp-server/dev/getting-started-stdio.html[quarkus-mcp-server
stdio guide]
-and the
-https://docs.quarkiverse.io/quarkus-mcp-server/dev/reference-configuration.html[configuration
reference]
-for the transport options. On Spring Boot the equivalent setup is described
-in the
-https://docs.spring.io/spring-ai/reference/api/mcp/mcp-server-boot-starter-docs.html[Spring
AI MCP Server Boot Starter documentation].
+The tools are served over streamable HTTP only. The stdio transport, used
+by MCP clients that launch the server as a subprocess, is not supported by
+this extension.
[id="extensions-mcp-server-usage-mixing-with-quarkus-mcp-server-annotated-tools"]
=== Mixing with quarkus-mcp-server annotated tools
@@ -262,10 +209,6 @@ and a call exceeding
`quarkus.camel.mcp-server.tool-timeout` returns
`Tool execution timed out` while the route keeps running until it completes
on its own.
-On Camel Main and Camel JBang the equivalent setup is the
-`camel-mcp-server` module with the `camel.server.mcp-*` options; on Spring
-Boot it is the `camel-mcp-server-starter`.
-
[id="extensions-mcp-server-additional-camel-quarkus-configuration"]
== Additional Camel Quarkus configuration
diff --git a/extensions/mcp-server/runtime/src/main/doc/intro.adoc
b/extensions/mcp-server/runtime/src/main/doc/intro.adoc
index 7c60ee6f2d..74d1bc5019 100644
--- a/extensions/mcp-server/runtime/src/main/doc/intro.adoc
+++ b/extensions/mcp-server/runtime/src/main/doc/intro.adoc
@@ -5,9 +5,9 @@ extension. No route is needed for the server itself: add the
extension, tag
the `ai-tool` routes to expose, and any MCP client (another Camel
application, an IDE, a coding agent) can discover and call them.
-Tool semantics — tag-based opt-in (the untagged default pool is never
-exposed), flat-namespace collision refusal, per-call timeout and error
-sanitization — are owned by the runtime-agnostic `camel-mcp-server-api`
-bridge and are identical on every Camel runtime. Serving concerns (endpoint
-path, transports, authentication) are owned by quarkus-mcp-server and
-configured via `quarkus.mcp.server.*`.
+The server is exposed over streamable HTTP. Tool semantics — tag-based
+opt-in (the untagged default pool is never exposed), flat-namespace
+collision refusal, per-call timeout and error sanitization — are owned by
+the `camel-mcp-server-api` bridge. Serving concerns (endpoint path,
+authentication) are owned by quarkus-mcp-server and configured via
+`quarkus.mcp.server.*`.
diff --git a/extensions/mcp-server/runtime/src/main/doc/usage.adoc
b/extensions/mcp-server/runtime/src/main/doc/usage.adoc
index 595f81e6ed..27a9de1e12 100644
--- a/extensions/mcp-server/runtime/src/main/doc/usage.adoc
+++ b/extensions/mcp-server/runtime/src/main/doc/usage.adoc
@@ -36,9 +36,10 @@ arrive as message headers in the route
(`${header.customerId}`).
=== Combining the Camel and quarkus-mcp-server configuration
The configuration is split by ownership: `quarkus.camel.mcp-server.*`
-decides *which tools exist and how they execute* (identical semantics on
-every Camel runtime), while `quarkus.mcp.server.*` decides *how the server
-is exposed*. Both are set side by side in `application.properties`:
+decides *which tools exist and how they execute* (semantics owned by the
+`camel-mcp-server-api` bridge), while `quarkus.mcp.server.*` decides *how
+the server is exposed*. Both are set side by side in
+`application.properties`:
[source,properties]
----
@@ -58,7 +59,7 @@ quarkus.mcp.server.traffic-logging.text-limit = 200
See the
https://docs.quarkiverse.io/quarkus-mcp-server/dev/index.html#configuration-reference[quarkus-mcp-server
configuration reference]
-for the full list of `quarkus.mcp.server.*` properties (transports, dev UI,
+for the full list of `quarkus.mcp.server.*` properties (dev UI,
authentication, guardrails, pagination, timeouts).
=== Connecting MCP clients
@@ -92,62 +93,9 @@ A coding agent or IDE is configured with the same URL, e.g.
in an
}
----
-=== Serving over stdio
-
-Out of the box the tools are served over streamable HTTP. MCP clients that
-launch the server as a subprocess speak over stdin/stdout instead — add the
-stdio transport alongside the extension:
-
-[source,xml]
-----
-<dependency>
- <groupId>io.quarkiverse.mcp</groupId>
- <artifactId>quarkus-mcp-server-stdio</artifactId>
- <!-- the same version as the quarkus-mcp-server-http extension pulled in
- by camel-quarkus-mcp-server; the transports share their core module
-->
- <version>1.13.1</version>
-</dependency>
-----
-
-The stdio transport is active as soon as it is on the classpath
-(`quarkus.mcp.server.stdio.enabled` defaults to `true`), and the same Camel
-tools are then served over both transports. To serve over stdio *only*,
-disable the HTTP transport of the default MCP server:
-
-[source,properties]
-----
-quarkus.mcp.server."<default>".http.enabled = false
-----
-
-The server name of the default MCP server is the literal string
-`<default>`, so it has to be quoted. Conversely,
-`quarkus.mcp.server.stdio.enabled = false` keeps the stdio extension on the
-classpath without activating it, which is useful when the same application
-is deployed both ways.
-
-Because stdout carries the MCP protocol, nothing else may be written to it;
-`quarkus-mcp-server-stdio` takes care of this by routing console logging to
-stderr. A stdio server is typically built as a native executable and
-launched by the client:
-
-[source,json]
-----
-{
- "mcpServers": {
- "my-integration-app": {
- "command": "/path/to/target/my-integration-app-1.0.0-runner"
- }
- }
-}
-----
-
-See the
-https://docs.quarkiverse.io/quarkus-mcp-server/dev/getting-started-stdio.html[quarkus-mcp-server
stdio guide]
-and the
-https://docs.quarkiverse.io/quarkus-mcp-server/dev/reference-configuration.html[configuration
reference]
-for the transport options. On Spring Boot the equivalent setup is described
-in the
-https://docs.spring.io/spring-ai/reference/api/mcp/mcp-server-boot-starter-docs.html[Spring
AI MCP Server Boot Starter documentation].
+The tools are served over streamable HTTP only. The stdio transport, used
+by MCP clients that launch the server as a subprocess, is not supported by
+this extension.
=== Mixing with quarkus-mcp-server annotated tools
@@ -194,7 +142,3 @@ the client), a missing or invalid argument returns the
validation message,
and a call exceeding `quarkus.camel.mcp-server.tool-timeout` returns
`Tool execution timed out` while the route keeps running until it completes
on its own.
-
-On Camel Main and Camel JBang the equivalent setup is the
-`camel-mcp-server` module with the `camel.server.mcp-*` options; on Spring
-Boot it is the `camel-mcp-server-starter`.
