shashank created CAMEL-26454:
--------------------------------
Summary: camel-jbang-mcp - chaos tools for the MCP server and
camel ask
Key: CAMEL-26454
URL: https://issues.apache.org/jira/browse/CAMEL-26454
Project: Camel
Issue Type: Improvement
Components: camel-jbang
Reporter: shashank
Assignee: shashank
Next stage of CAMEL-26330 (design/chaos.adoc, section "Control", step "The MCP
tool group" of "Order of work"), on top of CAMEL-26436 (apache/camel#28788),
which gives a running application a read-only {{chaos}} dev console, a
{{chaos}} action of the CLI connector and {{camel cmd chaos-*}} / {{camel get
chaos}}. An AI agent working on an integration through the Camel MCP server
cannot add a fault yet, or read what the faults did, except by asking the user
to run the CLI.
*Proposal*
* camel-jbang-mcp ({{RuntimeTools}}, {{@McpSecured}}): six tools, the same six
operations as the CLI, through the same {{chaos}} action of the CLI connector
and the chaos console in the status, as the other runtime tools reach an
integration:
** {{camel_runtime_chaos_list}}, {{camel_runtime_chaos_report}}:
{{readOnlyHint=true}};
** {{camel_runtime_chaos_add}}, {{camel_runtime_chaos_change}}:
{{readOnlyHint=false}}, {{destructiveHint=true}} (a rule makes messages fail,
wait or get lost, and {{exception=}} can name any exception class), as agreed
in the review of #28716; so the {{read-write}} access level of the MCP security
layer does not offer them, as it does not offer {{camel_runtime_route_control}}
or {{camel_runtime_sql}};
** {{camel_runtime_chaos_remove}}, {{camel_runtime_chaos_clear}}:
{{readOnlyHint=false}}, {{destructiveHint=false}}: they only take faults away
and the report keeps the removed rules, as starting and stopping the tracer
({{camel_runtime_trace}}) is not destructive either.
* Shared {{ToolRegistry}} (used by {{camel ask}}): {{chaos_list}},
{{chaos_report}}, {{chaos_add}}, {{chaos_change}}, {{chaos_remove}},
{{chaos_clear}} with the same marks; the MCP tools delegate to them.
* {{ToolConfirms.chaos}}: adding or changing a rule is a call the user confirms
first, with the rule shown; {{camel ask}} asks before {{chaos_add}} and
{{chaos_change}}. The security model ("Developer tools") lists it.
* A {{chaos}} runtime tool group ({{ToolGroup.CHAOS}}, {{AppFeatures}},
{{ToolGroups}}): it loads when the status of the application has the chaos
console, with chaos on or off, and its guidance line says which. The AI panel
of the TUI gets the group with no tools, only a line that faults may be
injected on purpose.
* A rule that is not valid comes back with the reason of the parser of
{{camel.chaos.rules}}; with chaos off every tool that changes rules is refused
with the reason; an unknown id is said; an integration that is not found or not
the only one is refused (rule ids are per integration).
* Not changed: the development MCP tools of {{camel run --mcp}}
({{camel.jbang.mcp=true}}, {{JbangDevMcpServer}}) expose every shared tool
without asking, so also {{chaos_add}} and {{chaos_change}}, as they expose
{{stop_route}} and {{execute_sql}}; the docs say so, and a follow-up can keep
the calls of {{ToolConfirms}} out of that server.
* Also fixed: the chaos plugin takes a property that tooling resolves to a
placeholder (route diagram with {{ignoreMissingProperty}}) or to the magic
value of {{camel export}} as not set, instead of vetoing the start; and
{{AskTools.sharedToolNames}} replaces the longest tool names first
({{camel_runtime_sql}} is the start of {{camel_runtime_sql_trace}}).
* Docs: the MCP server page (the tools, their hints, the group), the TUI
local-models page (the group), the chaos page ("From an AI agent (MCP)"), the
security model, and design/chaos.adoc (step done).
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
