This is an automated email from the ASF dual-hosted git repository.
jamesnetherton pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel-quarkus.git
The following commit(s) were added to refs/heads/main by this push:
new 4c96400684 mcp-server : Document the mcp-server extension as
streamable HTTP only. Related to #9342
4c96400684 is described below
commit 4c9640068445822f31bfbdcf274da27df4a8c7a8
Author: Alexandre Gallice <[email protected]>
AuthorDate: Mon Nov 2 08:34:15 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 | 88 ++++------------------
.../mcp-server/runtime/src/main/doc/intro.adoc | 12 +--
.../mcp-server/runtime/src/main/doc/usage.adoc | 75 +++---------------
3 files changed, 30 insertions(+), 145 deletions(-)
diff --git a/docs/modules/ROOT/pages/reference/extensions/mcp-server.adoc
b/docs/modules/ROOT/pages/reference/extensions/mcp-server.adoc
index ecc0a279e7..985757b78f 100644
--- a/docs/modules/ROOT/pages/reference/extensions/mcp-server.adoc
+++ b/docs/modules/ROOT/pages/reference/extensions/mcp-server.adoc
@@ -25,12 +25,12 @@ extension. No route is needed for the server itself: add
the extension, tag
the `ai-tool` and `ai-resource` routes to expose, and any MCP client (another
Camel application, an IDE, a coding agent) can discover and use 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"]
@@ -128,11 +128,11 @@ running.
=== Combining the Camel and quarkus-mcp-server configuration
The configuration is split by ownership: `quarkus.camel.mcp-server.*`
-decides *which tools and resources exist and how they execute* (identical
-semantics on every Camel runtime, except for the tool and resource clashes
-refused by quarkus-mcp-server), while `quarkus.mcp.server.*` decides
-*how the server is exposed*. Both are set side by side in
-`application.properties`:
+decides *which tools and resources exist and how they execute* (semantics
+owned by the `camel-mcp-server-api` bridge, except for the tool and
+resource clashes refused by quarkus-mcp-server), while
+`quarkus.mcp.server.*` decides *how the server is exposed*. Both are set
+side by side in `application.properties`:
[source,properties]
----
@@ -153,7 +153,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"]
@@ -188,63 +188,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
@@ -297,10 +243,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 f6faac8d46..7ab8062552 100644
--- a/extensions/mcp-server/runtime/src/main/doc/intro.adoc
+++ b/extensions/mcp-server/runtime/src/main/doc/intro.adoc
@@ -6,9 +6,9 @@ extension. No route is needed for the server itself: add the
extension, tag
the `ai-tool` and `ai-resource` routes to expose, and any MCP client (another
Camel application, an IDE, a coding agent) can discover and use 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 5473295c53..ad2f7ee947 100644
--- a/extensions/mcp-server/runtime/src/main/doc/usage.adoc
+++ b/extensions/mcp-server/runtime/src/main/doc/usage.adoc
@@ -63,11 +63,11 @@ running.
=== Combining the Camel and quarkus-mcp-server configuration
The configuration is split by ownership: `quarkus.camel.mcp-server.*`
-decides *which tools and resources exist and how they execute* (identical
-semantics on every Camel runtime, except for the tool and resource clashes
-refused by quarkus-mcp-server), while `quarkus.mcp.server.*` decides
-*how the server is exposed*. Both are set side by side in
-`application.properties`:
+decides *which tools and resources exist and how they execute* (semantics
+owned by the `camel-mcp-server-api` bridge, except for the tool and
+resource clashes refused by quarkus-mcp-server), while
+`quarkus.mcp.server.*` decides *how the server is exposed*. Both are set
+side by side in `application.properties`:
[source,properties]
----
@@ -88,7 +88,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
@@ -122,62 +122,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
@@ -226,7 +173,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`.
