[
https://issues.apache.org/jira/browse/CAMEL-25672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-25672:
--------------------------------
Description:
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_
was:
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. One line 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_
> 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
> Priority: Major
> Fix For: 4.24.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
(v8.20.10#820010)
