luigidemasi commented on code in PR #119: URL: https://github.com/apache/camel-kit/pull/119#discussion_r4360956953
########## camel-kit-core/src/main/resources/agents/catalog-researcher.md: ########## @@ -22,18 +22,17 @@ This pattern keeps raw MCP response traces out of the orchestrator's context win ## What You Do 1. Receive a list of artifacts to verify (components, EIPs, dataformats, languages), the runtime, the full platform BOM GAV, and the resolved Camel version -2. Establish one catalog version binding with `camel_catalog_components(limit=0)` using the supplied runtime and full - platform BOM. Require its returned `camelVersion` to match the resolved project version, as defined in - `shared/mcp-setup.md`. +2. Bind the catalog version from the supplied runtime and full platform BOM (derived from Review Comment: Required before merge (finding 2): align the output template with this new procedure. Line 63 still requires a camel_catalog_components call and a returned camelVersion; the migration verification-chain diagram still requires a probe once per batch. Both are installed for all eight targets. Remove those residual requirements and update docs/modules/ROOT/pages/mcp.adoc, including the new Knowledge-first routing, in this PR. ########## camel-kit-core/src/main/resources/skills/shared/mcp-setup.md: ########## @@ -127,22 +154,28 @@ The runtime affects which components are returned (e.g., Quarkus extensions vs S ### Rule 3: Bind catalog results to the resolved Camel version -Before consuming catalog detail or list fields, call `camel_catalog_components` with `limit=0` and the same `runtime` -and full `platformBom` GAV. Its successful result includes the catalog's resolved `camelVersion` without returning a -component payload; require that value to match the project's resolved Camel version. Record that probe and the exact call -arguments as the version binding for subsequent catalog calls that use the same runtime and BOM. +The version binding comes from `.camel-kit/config.properties` (`project.runtime`, `project.camelVersion`, +`project.platformBomVersion`). Always pass `runtime` and the full `platformBom` GAV derived from these properties on +every catalog call — those parameters **are** the binding. A call without them is answered from the catalog bundled in Review Comment: Required before merge (finding 1): update ResourceConsistencyTest for this new binding contract and the changed design-evidence line. Both existing binding tests fail. Preserve identity/provenance/failure checks and add regression coverage for Knowledge-server routing and removal of the old probe. Reversing the new server-name rule still passes all nine structural tests; do not rely on ShippedAssetStructureTest alone or weaken the contract assertions. ########## camel-kit-core/src/main/resources/skills/shared/mcp-setup.md: ########## @@ -127,22 +154,28 @@ The runtime affects which components are returned (e.g., Quarkus extensions vs S ### Rule 3: Bind catalog results to the resolved Camel version -Before consuming catalog detail or list fields, call `camel_catalog_components` with `limit=0` and the same `runtime` -and full `platformBom` GAV. Its successful result includes the catalog's resolved `camelVersion` without returning a -component payload; require that value to match the project's resolved Camel version. Record that probe and the exact call -arguments as the version binding for subsequent catalog calls that use the same runtime and BOM. +The version binding comes from `.camel-kit/config.properties` (`project.runtime`, `project.camelVersion`, +`project.platformBomVersion`). Always pass `runtime` and the full `platformBom` GAV derived from these properties on +every catalog call — those parameters **are** the binding. A call without them is answered from the catalog bundled in +the MCP server JAR, which may be a different version. Detail tools do not all return `camelVersion`. Do not require or invent a field that is absent from a tool's schema. -Validate each returned artifact identity and each consumed field against the requested type and name, and bind it to the -successful version probe plus the detail call's matching runtime and BOM. A `version` in Maven coordinates is an artifact -version, not proof of the catalog version. For component Maven coordinates, call `camel_catalog_component_maven` with the -same binding tuple. +Validate each returned artifact identity and each consumed field against the requested type and name, bound to the +`runtime` and `platformBom` from the call. A `version` in Maven coordinates is an artifact version, not proof of the +catalog version. For component Maven coordinates, call `camel_catalog_component_maven` with the same binding tuple. A detail-call error is not authoritative evidence that an artifact is absent. Record `NOT_FOUND` only after a successful matching list call contains no exact artifact name and the enumeration is complete. For a list tool with `limit`, increase the limit until the returned count is below it; if completeness or the version binding cannot be established, record `UNVERIFIED` instead. +### Forward compatibility (Camel 4.23+) + +On Camel 4.23 and later (CAMEL-24712), `camel_catalog_components`, `camel_catalog_component_doc`, +`camel_catalog_eip_doc`, `camel_catalog_dataformat_doc`, and `camel_catalog_language_doc` are removed. They are replaced +by `camel_catalog_find` and `camel_catalog_doc`. The `runtime` and `platformBom` parameters have no equivalent on 4.23+. +When targeting 4.23 or later, use the new tool names and omit the removed parameters. Review Comment: Required before merge (finding 3): project target version does not select the MCP server API. The generated runner remains 4.22.1, where a real camel_catalog_find call fails with Invalid tool name; camel_catalog_doc has an older, different schema. The manifest also excludes both names and its consistency test fails. Remove these actionable notes (including the duplicate in iron-laws.md) until the server/schema, allowlists and downstream binding guidance support them together. -- 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]
