luigidemasi opened a new issue, #109: URL: https://github.com/apache/camel-kit/issues/109
> Imported from [luigidemasi/camel-kit#249](https://github.com/luigidemasi/camel-kit/issues/249), opened by [Croway](https://github.com/Croway) on 2026-10-10. --- ## Description `camel-kit init` writes the Citrus MCP server into every generated MCP config, next to `camel` and `camel-knowledge`. Only the `camel-test` skill (and its guides) uses it, but every agent session in the workspace starts it and carries its tool definitions. In migration work, where `camel-test` is rarely or never invoked, this is pure overhead: one more JBang/Quarkus JVM launched per session and 8 extra tool definitions (plus 2 MCP prompts) in every model turn. ## Evidence In an evaluation of coding agents (Claude Code and IBM Bob) on migration tasks with camel-kit 0.4.1 initialised in the workspace, 84 of 84 sessions in the latest batch had the Citrus server connected and none called it: 0 Citrus calls out of 595 MCP calls (the rest went to `camel` and `camel-knowledge`). Across all earlier batches, Citrus tools were called in 2 of about 120 sessions (10 of ~1,150 MCP calls), and neither of those sessions had invoked `camel-test`; both used `citrus_docs_page` / `citrus_catalog_endpoint` while writing routes. The Claude Code session init shows what each session pays for: ``` mcp_servers: [camel: connected, camel-knowledge: connected, citrus: connected] tools: mcp__citrus__citrus_catalog_action, ..._action_schema, ..._actions, ..._endpoint, ..._endpoint_schema, ..._endpoints, mcp__citrus__citrus_docs_index, mcp__citrus__citrus_docs_page slash_commands: mcp__citrus__citrus_migrate_project, mcp__citrus__citrus_write_test ``` ## Where it comes from `camel-kit-core/src/main/resources/templates/mcp-configs/claude-code-mcp.json` (same in the other `*-mcp.json`/`codex-mcp.toml` templates) always contains: ```json "citrus": { "command": "jbang", "args": ["--repos", "{CITRUS_MCP_REPOS}", "-Dquarkus.log.level=WARN", "-Dquarkus.http.port=-1", "org.citrusframework:citrus-mcp-server:{CITRUS_MCP_VERSION}:runner"], ... } ``` `McpConfigGenerator.templateData()` fills it unconditionally from `workflow.mcpServer("citrus")`, and `CodexConfigMerger.MANAGED_SERVERS` lists it as always managed. Since luigidemasi/camel-kit#146, `DoctorService` requires the server whenever `citrus.version` / `citrus.mcp.version` are in `.camel-kit/config.properties`, which `init` always writes, so removing it by hand makes `doctor` fail. There is no init option to leave it out (`--citrus-version` only selects the version). Unchanged on `main`. The `camel-test` skill already has a fallback when the server is absent (the cached `citrus-quick-reference.md` for the configured `citrus.version`). ## Proposal Make the Citrus MCP server opt-in, for example one of: 1. An init flag (`--with-citrus-mcp`, or `-p citrus.mcp.enabled=true`) that adds the entry; default off. 2. Let `camel-test` add it on demand: on first use, if the server is not configured, tell the user (or run a `camel-kit` subcommand) to add the Citrus entry to the agent's MCP config, then reload. In both cases `doctor` should treat a missing `citrus` server as fine unless Citrus MCP was enabled (record the choice in `config.properties`, e.g. `citrus.mcp.enabled`), and keep validating the allowlist when it is present. `camel-test` keeps using the quick reference when the server is off. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
