[
https://issues.apache.org/jira/browse/CAMEL-23613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18083514#comment-18083514
]
Marat Gubaidullin edited comment on CAMEL-23613 at 5/26/26 2:35 PM:
--------------------------------------------------------------------
I think we can achieve these goals much faster without designing a new protocol
from scratch.
We already have the core building blocks and we just need a standard
translation layer.
Here is my perspective on how we can implement this with minimal long-term
development:
* *Design-Time is already solved:* YAML serves as the perfect shared format
for humans, visual UI tools, and AI agents. For Java or XML routes, Camel can
already convert them to YAML.
* *Runtime is already solved:* The Camel Dev Console natively provides all the
real-time observability we need (resolved properties, route states via
{{{}/q/dev/route{}}}, Micrometer metrics) as well as the control plane
(hot-reloads, injecting test data).
* *The Missing Link:* Instead of inventing a new custom protocol, we simply
need to build a *lightweight MCP (Model Context Protocol) Server* that *wraps*
the existing Dev Console.
* *Keep it strictly Single-Tenant:* Because the initial focus is local-first
development, this wrapper doesn't even need to be a fully featured MCP
implementation. A stateless, single-session process. Since it’s just one
developer/agent working with one Camel context, we completely bypass the
overhead of multi-session management, concurrency, or complex state handling.
By mapping the Dev Console to standard MCP primitives:
# *Resources:* Agents can read real-time route state and properties.
# *Tools:* Agents can execute hot-reloads and send test messages.
# *Prompts:* We can guide agent workflows automatically.
This "tiny wrapper" approach delivers the exact unified, AI-assisted experience
outlined in the proposal.
It requires zero modifications to the Camel core and instantly makes any
MCP-compatible AI agent (like Cursor or Claude) a Camel expert.
was (Author: [email protected]):
I think we can achieve these goals much faster without designing a new protocol
from scratch.
We already have the core building blocks and we just need a standard
translation layer.
Here is my perspective on how we can implement this with minimal long-term
development:
* *Design-Time is already solved:* YAML serves as the perfect shared format
for humans, visual UI tools, and AI agents. For Java or XML routes, Camel can
already convert them to YAML.
* *Runtime is already solved:* The Camel Dev Console natively provides all the
real-time observability we need (resolved properties, route states via
{{{}/q/dev/route{}}}, Micrometer metrics) as well as the control plane
(hot-reloads, injecting test data).
* *The Missing Link:* Instead of inventing a new custom protocol, we simply
need to build a *lightweight MCP (Model Context Protocol) Server* that *wraps*
the existing Dev Console.
By mapping the Dev Console to standard MCP primitives:
# *Resources:* Agents can read real-time route state and properties.
# *Tools:* Agents can execute hot-reloads and send test messages.
# *Prompts:* We can guide agent workflows automatically.
This "tiny wrapper" approach delivers the exact unified, AI-assisted experience
outlined in the proposal.
It requires zero modifications to the Camel core and instantly makes any
MCP-compatible AI agent (like Cursor or Claude) a Camel expert.
> Explore a shared contract for Camel runtime to enable AI agent and human
> collaboration
> --------------------------------------------------------------------------------------
>
> Key: CAMEL-23613
> URL: https://issues.apache.org/jira/browse/CAMEL-23613
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
> Affects Versions: 4.x
> Reporter: Otavio Rodolfo Piske
> Priority: Major
> Fix For: 4.x
>
>
> During our AI working group discussion, we identified a gap in the developer
> experience:
> *Context:*
> * Humans and AI agents currently lack a shared, structured view of a running
> Camel application.
> * Humans rely on visual tools (Karavan, Kaoto, TUI, dev consoles), while
> agents interact through logs, MCP tools, and file system changes — but these
> views are disconnected. As integration development shifts toward AI-assisted
> workflows (prompt-first, with visual tools as a display layer), we need a
> common contract that both humans and agents can consume to understand the
> state of a Camel application at design time and runtime.
> *Proposal:*
> # Design a contract (set of APIs / protocol) that exposes Camel runtime
> state: route topology, endpoint inventory, message flow metrics, error
> states, REST/OpenAPI specs, and dev console information.
> # Evaluate the [Agent-Client
> Protocol|https://agentclientprotocol.com/get-started/introduction] as a
> potential standard for agent-IDE/tool communication, rather than inventing a
> custom protocol.
> # Revisit the existing Camel LSP work to assess whether it can be
> improved/extended (with AI assistance) to provide protocol-level integration
> and editing capabilities.
> # Coordinate with the community to ensure this contract becomes the de-facto
> way of consuming Camel runtime information
> {*}Goals{*}:
> * Enable a faster feedback loop where a developer can prompt an agent, the
> agent modifies a route, a running Camel instance hot-reloads it, and both
> human and agent can verify the result through the same interface.
> * Provide a consistent experience across the SDLC — the same contract serves
> design-time visualization, local development, and production observability.
> * Start with local-first (single laptop, no cloud dependency) to validate
> the approach and build field confidence.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
