[
https://issues.apache.org/jira/browse/CAMEL-23382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18094022#comment-18094022
]
Zineb Bendhiba commented on CAMEL-23382:
----------------------------------------
[~fmariani]
This work is split into several sequential PRs to keep reviews focused:
* ( ) PR 1: Create the new \{{camel-ai-tool}} module with \{{AiToolSpec}},
\{{AiToolRegistry}}, consumer endpoint, and full tests. No changes to existing
modules.
* ( ) PR 2: Wire \{{camel-langchain4j-agent}} producer to read tools from
\{{AiToolRegistry}} instead of the old cache, with upgrade guide entry.
* ( ) PR 3: Wire \{{camel-spring-ai-chat}} producer to discover tools from
\{{AiToolRegistry}}, with upgrade guide entry.
* ( ) PR 4: Wire \{{camel-langchain4j-tools}} producer to read from
\{{AiToolRegistry}}, keeping the agentic loop intact.
* ( ) PR 5: Deprecate \{{camel-langchain4j-tools}} consumer side and remove
\{{camel-spring-ai-tools}} entirely, with upgrade guide entries for both.
* ( ) PR 6: Add tool support to \{{camel-openai}}. It resolve tools from
\{{AiToolRegistry}} and implement the dispatch loop. This one should have a
Jira issue to introduce the feature
> Unified Camel AI tool abstraction for route-based tools across AI components
> -----------------------------------------------------------------------------
>
> Key: CAMEL-23382
> URL: https://issues.apache.org/jira/browse/CAMEL-23382
> Project: Camel
> Issue Type: New Feature
> Components: camel-ai
> Affects Versions: 4.20.0
> Reporter: Federico Mariani
> Assignee: Zineb Bendhiba
> Priority: Major
> Fix For: 4.22.0
>
>
> tldr; as an user of camel-langchain4j, or camel-spring-ai or camel-openai,
> I'd expect the same behaviour and workflow when implementing tools.
> Currently, _camel-langchain4j-tools_ and _camel-spring-ai-tools_
> independently implement the same pattern: Camel routes register as
> LLM-invokable tools via a consumer endpoint, a singleton registry
> ({_}CamelToolExecutorCache{_}) maps tags to tool specs, and a producer
> dispatches tool calls to the matching route. Each module has its own
> duplicated copy of this registry and specification classes. *camel-openai*
> only supports external MCP server tools and has no way to use Camel routes as
> tools.
> This issue proposes extracting a shared, framework-agnostic tool abstraction
> ({*}camel-ai-tools{*}) that all AI components can use:
> - *ai-tool:toolName* consumer endpoint — defines a Camel route as an
> LLM-invokable tool with metadata (description, parameter schema). No AI
> framework dependency.
> - *AiToolRegistry* — shared singleton registry mapping tags to tool specs.
> Replaces the duplicated _CamelToolExecutorCache_ in langchain4j-tools and
> spring-ai-tools.
> - *AiToolSpec* — framework-agnostic tool definition holding name,
> description, JSON Schema parameters, and a reference to the Camel processor
> that implements the tool.
> Each AI component discovers tools from the shared registry via a _tags_
> parameter and converts them to its native format
> ({_}ChatCompletionFunctionTool{_} for openai, _ToolSpecification_ for
> langchain4j, _ToolCallback_ for spring-ai).
> Example YAML DSL:
> {code:java}
> # Define a tool once (framework-agnostic)
> - route:
>
>
>
> from:
> uri: ai-tools:getFacts
>
>
>
> parameters:
>
>
>
> tags: research
>
>
> description: "Get facts about a given topic"
>
>
>
> parameter.topic: string
> parameter.topic.description: "The topic to get facts about"
> steps:
>
>
> - to: "direct:someRoute"
>
>
>
>
>
>
> # Any AI component can use it
>
>
>
> - route:
>
>
>
> from:
> uri: direct:researcher
>
>
>
> steps:
> - to: "openai:chat-completion?autoToolExecution=true&tags=research"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
