[
https://issues.apache.org/jira/browse/CAMEL-24834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18123062#comment-18123062
]
Claus Ibsen commented on CAMEL-24834:
-------------------------------------
Other tool group candidates found in the codebase (dev consoles without an MCP
tool), for a later phase; HTTP is filed separately as the strongest one:
* *kafka*: the {{kafka}} console (topics, consumer groups, offsets, lag),
triggered by kafka endpoints. Artemis/JMS have no console.
* *quartz*: the {{quartz}} console (triggers, next fire time), for quartz
endpoints.
* *groovy*: the {{groovy}} console (compiled scripts, errors); measure first
whether the at frame of CAMEL-25296 is enough.
* *route controller*: the {{route-controller}} console (routes that failed to
start, retries) when the supervising controller is on.
* *stub*: the {{stub}} console (stubbed endpoints) when running with --stub.
Not groups: the secrets consoles (aws/azure/gcp/hashicorp/ibm, kubernetes
configmaps and secrets: niche and sensitive), JVM diagnostics (memory, heap,
threads, JFR: on demand, not a feature of the app), type converters and
transformers (every app; better as data-mapping tools, CAMEL-24908). Aggregator
state has no console yet (camel-core first).
> 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)
