[
https://issues.apache.org/jira/browse/CAMEL-25672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18143924#comment-18143924
]
Claus Ibsen commented on CAMEL-25672:
-------------------------------------
[~ldemasi] [~fmariani] reopened and moved to 4.25.0, as this needs your input
first.
We think a migration of an integration to Camel is better handled by camel-kit
than by camel-jbang-mcp, so PR https://github.com/apache/camel/pull/29740 (a
camel_migrate_to_camel prompt and a camel_migration_instructions tool) is
closed.
That leaves the default server instructions of camel-jbang-mcp (CAMEL-25646, in
4.24.0, not released yet). Some of their rules came from the evaluation of
agents migrating legacy integrations to Camel, and only matter in a migration:
* smtp/imap/pop3, not mail
* the mail producer ignores the Subject, From and To headers unless
useHeaderSubject, useHeaderFrom and useHeaderRecipients are true
* remove the Camel* headers before an http or mail producer
* xslt receives the headers and variables as stylesheet parameters
* the HTTP port and the extra jars (//DEPS, camel.jbang.dependencies, --dep) of
camel run
Questions:
# Does camel-kit carry these rules itself, so they can leave the default text
of camel-jbang-mcp, which would then serve everyday work on a Camel project
(the first part of the proposal above)?
# Or does camel-kit rely on the server instructions, and they should stay?
The upgrade tools between Camel versions (camel_migration_analyze,
_compatibility, _recipes, _guide_search, _wildfly_karaf and the
camel_migrate_project prompt) are not in question: they stay in camel-jbang-mcp.
_Claude Code on behalf of davsclaus_
> camel-jbang-mcp - server instructions for everyday work on a Camel project;
> migration guidance in a prompt and a tool
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25672
> URL: https://issues.apache.org/jira/browse/CAMEL-25672
> Project: Camel
> Issue Type: Improvement
> Components: camel-jbang-mcp
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Priority: Major
> Fix For: 4.25.0
>
>
> CAMEL-25646 gave camel-jbang-mcp server instructions: the text an agent host
> shows the model at the start of a session. The rules came from an evaluation
> of agents migrating legacy integrations to Camel. But most people who use the
> server work on an existing Camel project every day: they build routes, run
> them and fix them. Migration is a one-time task for a few users, and after it
> they never do it again. So the default instructions should serve everyday
> work, and the migration guidance should be there when a migration starts.
> h3. What the current text does for everyday work
> * Several rules only matter in a migration: the mail producer headers
> ({{useHeaderSubject}} and the like), {{removeHeaders}} before an http or mail
> call, xslt parameters, smtp and not mail, {{--dep}} and the port of camel run.
> * The tool map points to catalog, examples and dependency lookups. It never
> names the tools of daily work: {{camel_get_files}}, {{camel_edit_file}} and
> {{camel_write_file}} (whose answer already shows the reload and what the
> routes logged after it), {{camel_eval_expression}}, {{camel_get_log}} and
> {{camel_control}}.
> * Measured in a local-model benchmark (qwen3.6 35B-A3B, 21 authoring
> examples, 5 runs per arm, Oct 14-15):
> ** with the instructions in the system prompt, 314 of 355 steps passed,
> against 313 without;
> ** the model made 8% more tool calls ({{camel_catalog_doc}} 58 per run
> against 42, {{camel_get_log}} 57 against 36);
> ** it had 30% fewer refused writes.
> ** So the instructions change how the model works, but do not help it build
> routes.
> h3. Proposal
> # *Default instructions for everyday work on an existing project.* Say what
> the server is for: building, running and fixing Camel routes. Then the rules
> that cost a model most when it writes routes (from the same benchmark):
> ** the steps of an EIP go under its steps;
> ** a choice has one when list;
> ** onException, errorHandler and routeConfiguration are top-level entries,
> and handled is an expression;
> ** variables, not exchange properties, for the values a route keeps for
> itself;
> ** Simple operators go between functions, not inside them;
> ** after a write, read the reload result in the answer and the log.
> ** then the daily tool loop, and one line that points to migration:
> "Migrating to Camel, or between Camel versions? Use the
> camel_migrate_to_camel or camel_migrate_project prompt, or call
> camel_migration_instructions."
> # *Migration guidance on demand:*
> ** a prompt {{camel_migrate_to_camel}}, next to the existing
> {{camel_migrate_project}}, that carries the current migration rules: a
> workflow the user starts on purpose (a slash command in clients such as
> Claude Code);
> ** a tool {{camel_migration_instructions}} that returns the same text, for
> clients that only use tools. Its description says to call it once at the
> start of a migration. The same text could optionally come as a SKILL.md, for
> agents that support skills.
> # *Follow-up with the tool profiles of CAMEL-25537:* a migration profile
> whose server instructions are the migration text, so a migration project runs
> the server in migration mode.
> Keep the default text short, as the current one is (under the 4,096
> characters Claude Code shows).
> cc [~fmariani]
> _Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
