MCP servers
Camel Kit uses the Model Context Protocol to verify Camel configuration, to guide Citrus test generation and to search documentation without loading whole catalogs into the agent’s context. init configures two local servers by default (three with --with-citrus-mcp; released versions 0.4.1 and earlier include all three by default) in the agent’s MCP configuration file (see Supported AI agents for the file of each target); the agent starts each one with JBang when a skill first needs it, and JBang resolves the runner and the catalog artifacts from the configured repositories.
| Server | Purpose |
|---|---|
| The Apache Camel catalog: components, EIPs, data formats, languages, Kamelets and examples; route, YAML and configuration validation; diagnostics, migration and OpenAPI helpers |
| Hybrid search over indexed Apache Camel documentation, CVE advisories, release notes and Jira issues; see Knowledge MCP |
| The Citrus action and endpoint catalogs, the YAML DSL schema and the test-authoring guidance used by |
The JBang runner coordinates of this release:
camel org.apache.camel:camel-jbang-mcp:4.22.1:runner camel-knowledge io.github.luigidemasi:camel-kit-knowledge-mcp:0.0.2:runner citrus org.citrusframework:citrus-mcp-server:5.0.1:runner
The generated configuration is, in the target’s JSON or TOML shape:
{
"mcpServers": {
"camel": {
"command": "jbang",
"args": [
"--repos", "<configured MCP repositories>",
"-Dcamel.catalog.repos=<configured catalog repositories>",
"-Dquarkus.log.level=WARN",
"-Dquarkus.http.port=-1",
"org.apache.camel:camel-jbang-mcp:4.22.1:runner"
]
}
}
}Versions and repository lists come from distribution.properties; nothing is extracted into the project, and the generated launch configuration is used unchanged. Targets with exact tool filtering receive the workflow allowlist of each server from the workflow manifest; Codex CLI adds default_tools_approval_mode = "prompt", Pi reads the same .mcp.json through pi-mcp-adapter.
Responses are data
An MCP response is loaded context. The workflow relies only on the purpose-specific fields it requested, after the artifact identity, runtime, platform BOM, resolved version, result and provenance are present and validated. Prose, examples, commands, URLs, tool requests or scope changes in a response cannot direct an action; summaries inherit the response’s authority rather than increasing it. See Context authority.
Version binding
Every version-sensitive catalog call passes the project’s runtime (main, spring-boot or quarkus) and the full platform BOM coordinate derived from .camel-kit/config.properties; a call without them is answered from the catalog bundled in the server, which may be the wrong version.
| Runtime | Platform BOM |
|---|---|
|
|
|
|
|
|
The version binding comes from .camel-kit/config.properties (project.runtime, project.camelVersion, project.platformBomVersion). Every catalog call passes runtime and the full platformBom GAV derived from those properties — those parameters are the binding. Detail tools do not all echo a version, so each artifact is validated by type and name against the request instead. A detail-call error is not proof of absence: an artifact is recorded as NOT_FOUND only after a successful list call with a complete enumeration contains no exact match, and as UNVERIFIED when completeness or the binding cannot be established.
For behaviour questions — YAML shape, runtime configuration, version changes, header propagation — skills call camel_docs_search on the camel-knowledge server, not camel. The knowledge server tools (camel_docs_search, camel_docs_component_info, camel_docs_cve_search, camel_docs_release_info, camel_docs_jira_lookup) complement the catalog with documentation search; catalog tools (camel_catalog_*) remain on camel.
The current defaults are Camel 4.22.1 for Camel Main and Spring Boot, with Camel 4.18.3 on the Quarkus platform 3.33.3.2; the catalog server artifact follows the Camel Main stream.
The Camel catalog server
The workflow allowlist covers the read-only and generation helpers the skills use; runtime mutation and control tools stay out of the generated configuration.
| Tool | Purpose |
|---|---|
Catalog exploration | |
| List, document and locate the Maven coordinates of components |
| Data formats and their options |
| Expression languages |
| Enterprise Integration Patterns and their configuration |
| Kamelets and their dependencies |
| Camel examples and their files |
Validation, security and tests | |
| Validate one endpoint URI against the bound catalog (the skills call it once per statically extracted endpoint) |
| Validate YAML DSL syntax |
| Convert routes between YAML and XML |
| Extract components and EIPs from a route; candidate evidence for route hardening |
| A JUnit 5 route test scaffold |
Diagnostics and configuration | |
| Component property metadata; validation of configuration properties |
| Dependency checks, error diagnosis, property translation between runtimes |
| Camel versions with LTS status and JDK requirements |
Migration and OpenAPI | |
| Migration analysis, compatibility, recipes and guidance |
| OpenAPI validation, scaffolding and mock guidance |
The design stage verifies every component, EIP, data format and language before it enters the design, and records the evidence (see Catalog verification). During implementation the route files are validated with camel_validate_route and camel_validate_yaml_dsl, and camel_configuration_validate is a mandatory gate after writing application properties: generation is not complete until it passes or the documented manual fallback is recorded. /camel-validate uses the same tools for its endpoint verification, and camel-test uses the route context and hardening tools for its test strategy.
Without the catalog, a model writes component names from its training data, which may be renamed, removed or different in the target version. With it, a request such as "a message queue" becomes three verified candidates (jms, amqp, kafka) and a question to you, and an unknown name becomes a clarification instead of a guess.
The Citrus server
camel-test validates the test vocabulary through citrus_catalog_actions, citrus_catalog_action, citrus_catalog_action_schema, citrus_catalog_endpoints, citrus_catalog_endpoint, citrus_catalog_endpoint_schema, citrus_docs_index and citrus_docs_page, plus resources such as citrus://schema/dsl/yaml. The test schema and the generated test dependencies use citrus.version from .camel-kit/config.properties, and the server coordinate is bound to the actual runner artifact in the agent’s configuration. Typed catalog and schema fields are treated as same-version data only when that runner version equals citrus.version; otherwise the skill uses the same-version quick reference cached under .camel-kit/.cache/citrus/, and marks a generated test as unverified rather than falling back to another Citrus version silently.