[
https://issues.apache.org/jira/browse/CAMEL-24834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18122177#comment-18122177
]
Claus Ibsen commented on CAMEL-24834:
-------------------------------------
Plan (2026-10-03), from reading the code on main; implementation on branch
fix/CAMEL-24834.
*Findings*
* The runtime tools live once in the shared ToolRegistry (camel-jbang-core);
camel-jbang-mcp RuntimeTools wraps them 1:1 (camel_runtime_sql -> execute_sql,
camel_runtime_datasources, camel_runtime_sql_trace,
camel_runtime_circuit_breakers, camel_runtime_spans, camel_runtime_trace,
camel_runtime_metrics). The TUI exposes its own tui_* equivalents.
* There is no SELECT-only guard anywhere: SqlQueryDevConsole runs any statement
(stmt.execute).
* The TUI's TabRegistry already detects datasource / circuit breaker /
OpenTelemetry to show tabs, but on parsed IntegrationInfo, not reusable by the
MCP server.
* The status file (~/.camel/<pid>-status.json, LocalCliConnector) has
everything needed, one local read: dataSources.dataSources[] (non-empty),
routes[].processors[].processor == circuitBreaker and the resilience4j /
fault-tolerance / circuit-breaker sections, devConsoles containing
opentelemetry, trace.enabled, micrometer.
*Phase 1*
* camel-jbang-core: AppFeatures.fromStatus(JsonObject) (pure, unit tested on
status fixtures, tolerant of older status files), ToolGroup (sql, tracing,
resilience) and ToolGroups.select(features, sqlWrites) returning the tools, one
guidance line per group (datasource names; table names come from the SQL trace,
not a guessed schema; breaker routes) and a fingerprint that changes only when
the groups change.
* Read-only SQL: SqlReadOnlyGuard (SELECT / WITH / VALUES / SHOW / EXPLAIN /
DESCRIBE only, one statement, comments and literals stripped first, no SELECT
INTO or FOR UPDATE, no data-changing CTE) and a new read-only registry tool
behind it; MCP camel_runtime_sql_query (readOnlyHint). The sql group offers the
read-only tool unless writes are enabled. Best effort until the console itself
can run read-only (phase 2).
* MCP: camel_runtime_tool_groups(nameOrPid, sqlWrites) returns core tools,
groups (tools + guidance) and the fingerprint, so any client, including the
local-model benchmark harness, applies the same selection as the TUI.
tools/list_changed was considered and left out: the server has no selected app,
and many clients ignore the notification.
* TUI AI panel, core mode only (full mode unchanged): recompute the groups when
the selected app changes or after a reload (union on the same pid, so the tool
list and prompt stay byte-identical between questions and the cached prefix
survives); send core + group tools; guidance lines at the end of the system
prompt; tui_execute_sql read-only unless the new setting camel.tui.ai.sqlWrites
is true; /tools shows the loaded groups. tui_get_spans stays in the core set
(baselines).
* Prompt budget test covers core + all groups with its own, slightly higher
budget.
* Docs: TUI local models, TUI AI, TUI settings, camel-jbang-mcp.
*Phase 2 (later)*: groups from the project source before the app runs
(ProjectOverview), a readOnly option in SqlQueryDevConsole (setReadOnly +
rollback), a /sql slash command, aggregator state.
> camel-jbang-mcp: load AI tool groups (SQL, tracing, resilience) from what the
> selected app has, read-only SQL for local models
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24834
> URL: https://issues.apache.org/jira/browse/CAMEL-24834
> Project: Camel
> Issue Type: Improvement
> Components: camel-jbang
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Priority: Major
> Fix For: 4.24.0
>
>
> The camel-jbang-mcp server's AI tool set for local models is a fixed core set
> of 19 tools. Hosted providers get the full set of 47. A local model therefore
> cannot use the tools it would need for a question that depends on what the
> running app has: it cannot run a SQL query against the app's datasource to
> check that a message landed in a table, cannot read spans when tracing is on,
> and cannot inspect a circuit breaker or aggregator.
> A local model is typically pointed at one app. The server already knows which
> app is selected and the dev consoles say what that app has. So the tool set
> should be a function of the app, not only of the provider.
> Proposal:
> * Keep the core set as the base for local models.
> * Add tool groups that are loaded when the selected app reports the matching
> feature:
> ** SQL: execute_sql, get_datasources, get_sql_trace, when the datasource
> console reports a datasource
> ** tracing: get_spans and trace_control, when tracing is enabled
> ** resilience: get_circuit_breakers, when a circuit breaker is in the routes;
> the aggregator state likewise
> * When a group joins, add one line of guidance with it: the datasource names,
> and that table names come from the SQL trace, so the model does not guess a
> schema.
> * For local models the SQL tool is read-only (SELECT only) unless the user
> enables writes, the same way the tool mode is a setting today. The model is
> not the security boundary. Hosted providers in full mode keep the current
> behaviour.
> * The prefix changes only when the selected app changes or the app gains the
> feature after a reload, so the prompt cache is re-filled once per app.
> Later, a meta tool that lets the model ask for a named group on demand (the
> remaining tools: screen, drawing, tape, memory and threads) so a local model
> can reach the full set at the cost of one re-prefill per group. Coarse
> groups, since every change of the tool set re-fills the prompt prefix.
> The prompt budget test guards the size of the prefix in both modes and should
> cover the loaded groups too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
