Proposal: Remove Spring AI tool loop support path option

[johnsonr]

Currently Spring AI's tool loop can be chosen instead of Embabel's own by changing LlmInteraction.useEmbabelToolLoop to false from the default true.

Making this choice means that a lot of valuable functionality based on full control of the tool loop, such as progressive tool disclosure (and more to come) is unavailable.

Curious as to if anyone is making this choice because of Spring AI tool-related functionality they need.

Please vote on whether to remove--thumbs up is yes.

Removal will have no impact on users not changing this default, besides the elimination of quite a bit of code.

Removing the Spring AI tool loop path would not drop support for Spring AI @Tool annotation, although Embabel's own @LlmTool should be preferred.

[azanux]

For Gemni we need to use @tool instead of @LLMTool

@LLMTool String responses break with Google GenAI (Gemini) - @tool works

when

SecurityAuditReport report = ai
            .withLlm(GEMINI_PRO_3)
            .withSystemPrompt(systemPrompt)
            .withToolObject(auditSecurityTools)
            .createObject(userInput.getContent(), SecurityAuditReport.class);          

@LLMTool methods returning String crash with Gemini because the raw string isn't JSON-serialized before reaching GoogleGenAiChatModel.parseJsonToMap().

Spring AI's @tool works fine because DefaultToolCallResultConverter calls JsonParser.toJson(result) before the response reaches Gemini.

  JsonParseException: Unrecognized token 'src': was expecting JSON String, Number, Array, Object...
    at GoogleGenAiChatModel.parseJsonToMap(GoogleGenAiChatModel.java:378)

Root cause: SpringToolCallbackAdapter.call() returns result.content as a bare string. Gemini requires FunctionResponse.response to be a JSON object.

Workaround: Use @tool / @ToolParam instead of @LLMTool / @LlmTool.Param.

Not totally sure but , I think , it is related: Same root cause as #1391.