[
https://issues.apache.org/jira/browse/CAMEL-24352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18104053#comment-18104053
]
Karol Krawczyk commented on CAMEL-24352:
----------------------------------------
I would like to pick this up, and I have done some investigation first. Two
confirmations, one warning and one design question.
h3. The SDK assumption holds
{{StdioServerTransportProvider}} is present in {{mcp-core}} 2.0.0, the version
{{camel-mcp-server}} already depends on — I verified it in the artifact rather
than the docs:
{code}
io/modelcontextprotocol/server/transport/StdioServerTransportProvider.class
io/modelcontextprotocol/server/transport/StdioServerTransportProvider$StdioMcpSessionTransport.class
{code}
With {{McpServerEngine}} being as small as it is ({{initialize}} /
{{toolAdded}} / {{toolRemoved}}) and engine resolution going through a registry
bean first and {{META-INF/services/org/apache/camel/mcp-server-engine}} second,
a second engine next to {{VertxMcpServerEngine}} really is a thin addition. The
bridge, tag selection, timeout and sanitization stay untouched.
h3. Naming collision worth flagging
{{camel-mcp-server}} already contains {{JbangDevMcpServer}} and
{{JbangDevMcpMainListener}} under the {{jbang}} package. That is a different
thing: a dev/diagnostics server on the *management* HTTP port, exposing the
JBang CLI's own {{ToolRegistry}} tools reflectively, gated by
{{camel.management.mcpEnabled}} — not {{ai-tool}} routes. Anyone reading this
issue could reasonably assume the JBang side is already covered, or
accidentally extend that class. Whatever this issue produces should be clearly
separated from it, both in package naming and in the docs, since a JBang
process could in principle end up running both.
h3. Design question: where do the options live?
Every {{mcp-*}} option currently sits in {{HttpServerConfigurationProperties}},
i.e. under {{camel.server.*}}, whose contract is the main HTTP server. A stdio
transport needs no HTTP server at all, so {{camel.server.mcp-transport=stdio}}
would be an HTTP-server property that turns the HTTP server off, and roughly
half the existing options ({{mcp-path}}, {{mcp-session-keep-alive-interval}},
{{mcp-session-idle-ttl}}) become meaningless in that mode.
Three ways out, and I would rather you pick than guess:
# Keep it under {{camel.server.*}} as proposed and document which options are
ignored in stdio mode. Smallest change, slightly incoherent namespace.
# Introduce a {{camel.mcp.*}} namespace for transport-independent options and
leave the HTTP-specific ones where they are. Cleanest, but it is a user-visible
move of existing options and needs an upgrade-guide entry.
# Make it JBang-only: a {{--mcp-stdio}} flag that wires the engine
programmatically, no new Main property at all. Narrowest scope, matches the
"local coding agent" use case exactly, but does not help plain Camel Main users.
My preference is 3 for this issue, with 2 as a follow-up if plain Camel Main
ever needs stdio — it keeps this change small and avoids moving properties that
shipped in 4.22.
h3. Stdout hygiene
Agreed that this is the actual work. There is more precedent in JBang than the
issue suggests: {{RuntimeUtil.configureLog(...)}} already selects between seven
log4j2 variants, and three of them ({{log4j2-script}}, {{log4j2-export}},
{{log4j2-background}}) use a File appender only, with no console appender at
all. A {{log4j2-stdio}} variant fits that pattern directly. The remaining
console appenders declare no {{target}}, so they default to {{SYSTEM_OUT}} —
which confirms the leak. For the banner and command output, {{Printer}} is
already an interface with {{SystemOutPrinter}} and {{QuietPrinter}}
implementations, so a stderr-backed one is a small addition.
What I do not yet know is whether logging and the banner are the *only* things
reaching stdout during startup, or whether the JBang bootstrap, Vert.x or a
third-party library writes there too. I plan to measure that before
implementing rather than assume it, and I expect the honest answer may still
require redirecting {{System.out}} as a backstop.
h3. Coordination
Since CAMEL-24308 is still open and assigned to you, and you are also driving
the Spring Boot and Quarkus engines, I do not want to cut across your plans —
if you intended to take this one yourself, say so and I will pick something
else.
_Reported by Claude Code on behalf of Karol Krawczyk_
> camel-jbang - Serve ai-tool routes over the MCP stdio transport
> ---------------------------------------------------------------
>
> Key: CAMEL-24352
> URL: https://issues.apache.org/jira/browse/CAMEL-24352
> Project: Camel
> Issue Type: Improvement
> Components: camel-ai, camel-jbang
> Reporter: Federico Mariani
> Priority: Major
>
> Follow-up to CAMEL-24308. Local coding agents and IDEs launch MCP servers as
> child processes speaking JSON-RPC over stdin/stdout (the {{"command": ...}}
> entry in an {{mcp.json}}). A developer should be able to register {{camel run
> tools.yaml}} that way and have the tagged {{ai-tool}} routes served as local
> tools — no port, no URL, process lifetime = session.
> The transport is nearly free: the MCP Java SDK ships
> {{StdioServerTransportProvider}}, so this is a thin engine variant behind the
> existing {{McpServerEngine}} SPI (e.g. a
> {{camel.server.mcp-transport=http|stdio}} option or a JBang flag such as
> {{--mcp-stdio}}), with the bridge unchanged.
> The actual work is stdout hygiene: in stdio mode stdout must carry only
> protocol frames, so JBang needs to route all logging, the banner and
> route-startup summaries to stderr (or a file) and suppress anything else
> printed to stdout.
> Spring Boot and Quarkus already document their stdio setups via their native
> MCP stacks (camel-mcp-server-starter / camel-quarkus-mcp-server usage docs);
> this issue covers Camel Main / JBang.
> _Filed by Claude Code on behalf of Federico Mariani_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
