Serdar Gökay created CAMEL-26686:
------------------------------------
Summary: camel-jbang-mcp - development against integrations that
run on a server: can camel mcp serve integrations that connect to it
(CAMEL-25197)?
Key: CAMEL-26686
URL: https://issues.apache.org/jira/browse/CAMEL-26686
Project: Camel
Issue Type: Improvement
Components: camel-jbang
Affects Versions: 4.23.0
Reporter: Serdar Gökay
We develop integrations with coding agents, and we would like to ask whether
the way we do it is one the MCP server is meant to cover.
h3. What we do and why
The integrations do not run on the developer's machine. Each one runs as a
{{camel run}} container on a shared development server (a Kubernetes cluster in
our case), next to the systems it talks to: SAP, databases, brokers. A laptop
cannot reach those systems, several people work on the same running
integration, and nothing has to be installed on the developer's machine. The
developer's agent (Claude Code or another client) connects over MCP and works
on the running integration: validate, look at routes and errors, send a
message, read the log, fix and try again.
The Camel CLI and {{camel mcp}} are built around the developer's own machine:
{{camel mcp}} finds integrations through the files in {{~/.camel}} and a check
of the pid, so it serves the integrations of its own machine. CAMEL-25197 names
this limit for tools in general ("no containers, dev containers or remote dev
clusters") and added the integration's side of a way out.
h3. Where we are stuck
Both ways we found work on 4.23.0, and each has a cost:
|| Way || What we get || Cost ||
| The embedded server of {{camel run}} (its mcp option), one in each
integration | No second process | 72 tools without hints, no resources, no
prompts, and one process selection shared by all sessions |
| {{camel mcp}} over HTTP next to each integration, sharing its PID namespace,
{{~/.camel}} and source directory | The whole surface: 86 tools with hints,
resources and prompts. The tools find the integration with no selector, and a
restarted integration is found again | A second JVM for every integration:
about 145 MiB resident when idle, 300 to 330 MiB after a catalog search (heaps
of 128 to 256 MB) |
What we would like is one {{camel mcp}} for the server, with the integrations
connecting to it.
h3. Questions
# Is development against integrations on a server a use that {{camel mcp}} is
meant to cover? Or are we looking at it with the wrong architecture, and there
is a better shape than the two above?
# With CAMEL-25197 an integration can dial out to a developer tool
({{camel.cli.transport=websocket}}). Is {{camel mcp}} accepting such
connections, and serving the connected integrations like local ones (listed by
{{camel_runtime_processes}}, selected by {{nameOrPid}}), on the roadmap? We
found nothing in camel-jbang that accepts them, at 4.23.0 or on main.
# Is there a reason not to have it? The transport is for development only (it
refuses the prod profile and asks for a token), which fits our use.
# If the embedded server is the intended way for an integration that is not
local, is it planned to serve the CLI server's surface there?
If one of these fits, we would like to work on it, and we can test against real
containers.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
