Support a custom ChatJsonRPCService::executeWithTools method implementation

[diegolovison]

The current implementation is the following:

private Response<AiMessage> executeWithTools(ChatMemory memory) {
        ChatResponse response = model
                .chat(ChatRequest.builder().messages(memory.messages()).toolSpecifications(toolSpecifications).build());
....

I would like to change the implementation for my needs. As an example, my current implementation can determine the appropriate tool from a message using a deterministic, non-AI approach.

If possible, I wish to provide my custom code at the following.. @McpToolCode is just a suggestion.

@RegisterAiService
@SessionScoped
public interface McpClientAI {

    @SystemMessage("""
            You are a knowledgeable........
            """
    )
    @McpToolBox("default")
    String chat(@UserMessage String question);

    @McpToolCode("default")
    Response<AiMessage> executeWithTools(ChatMemory memory) {
         .....
}

[diegolovison]

Another custom implementation that I wish to use is:

ChatResponse response = model
                .chat(ChatRequest.builder()
                      .messages(memory.messages())
                      .toolSpecifications(toolSpecifications)
                      ......
                      build());

Double temperature;
Double topP;
Integer topK;
Double frequencyPenalty;
Double presencePenalty;
Integer maxOutputTokens;
ToolChoice toolChoice;

and with the code provided by the quarkus-langchain4j I can't.

[jmartisk]

I don't quite understand why you would need to override something that is used purely for quick experiments during development. And I don't think Quarkus even generally allows applications to plug in their custom code into the Dev UI, which is where ChatJsonRPCService is used. To accomplish something like this, you would probably need your own Quarkus extension with your own Dev UI pages.

As for overriding topK, temperature, etc., you should be able to do that for the model using application.properties. That wouldn't work for overriding it separately (differently) for each request, but we just don't have the UI tool for that (that would be possible to implement, but I'm not sure if a lot of people would find it useful).