embabel-agent

The failure occurs because EventPublishingTool maps only thrown exceptions to Result.failure; a returned Tool.Result.Error follows the success branch and is published as Result.success("<error message>"). Fix EventPublishingTool in ToolDecorators.kt so that when the delegate returns Tool.Result.Error, it publishes Result.failure(ToolReturnedError(message, cause)) while call() still returns the original Error. Do not change the returned intermediate result, because downstream recovery and Spring's ToolExecutionException conversion depend on it. Add a test where the delegate returns Tool.Result.Error, asserting both that responseEvent.result.isFailure is true and that call() still returns the original Error. This makes result.isFailure, tool stats, and embabel.tool.errors.total report the call correctly. Until using a release containing the fix, custom tools can throw instead of returning Tool.Result.Error, but annotated MethodTool and ScriptTool errors require the patch.

This happens because embabel-agent-lmstudio-autoconfigure contains a stale duplicate models/openai-models.yml. If that JAR loads first, OpenAiModelLoader uses it instead of the catalog in embabel-agent-openai-autoconfigure, so newer models are never registered.

Fix:
1. Upgrade to a release containing the fix for issue #2064, where the duplicate file was removed from embabel-agent-lmstudio-autoconfigure.
2. As a temporary workaround, remove the stale resource from the LM Studio JAR:

jar tf embabel-agent-lmstudio-autoconfigure-*.jar | grep 'models/openai-models.yml'
   zip -d embabel-agent-lmstudio-autoconfigure-*.jar 'models/openai-models.yml'

Registered OpenAI model bean: gpt56luna -> gpt-5.6-luna

A longer-term safeguard is to have OpenAiModelLoader call getResources("models/openai-models.yml") and warn or fail when multiple catalog copies are found.

Agents declared without an explicit @Agent(version = "...") previously fell back to the framework default 0.1.0-SNAPSHOT, because annotations require compile-time constants and cannot read the Maven/Gradle project version. Fixed in PR #2113 via an AgentVersionResolver used by AgentMetadataReader, which resolves the version in this order: 1) Explicit @Agent(version = "...") if set; 2) Spring Boot BuildProperties.version when build-info is generated; 3) the JAR manifest Implementation-Version of the agent class package; 4) Semver.DEFAULT_VERSION as final fallback. To get your build version into agent metadata, either set the version explicitly: @Agent(description = "...", version = "2.0.0"), or enable Spring Boot build-info generation. For Maven: add an execution of the build-info goal to spring-boot-maven-plugin. For Gradle: add springBoot { buildInfo() }. Then the deployed agent metadata will reflect the actual application artifact version.

Use an Embabel release that includes the MCP Streamable HTTP migration, where the SSE-only McpSseShutdownConfiguration is removed and WebMvcSseServerTransportProvider is no longer used. Then let Spring AI auto-configuration select the transport by adding:

spring.ai.mcp.server.protocol=STREAMABLE

or YAML:

spring:
  ai:
    mcp:
      server:
        protocol: STREAMABLE

Remove any custom beans or configuration referencing WebMvcSseServerTransportProvider, McpSseShutdownConfiguration, or the legacy SSE endpoint. Rebuild with ./mvnw clean package. Remote MCP or agent-to-agent clients must connect to the Streamable HTTP endpoint rather than the old SSE endpoint. On versions containing this change, Embabel delegates transport handling to Spring AI and no longer retains the SSE-specific shutdown code path.

Upgrade to a release containing the fix for issue #2083, then configure connect-timeout and read-timeout instead of relying on the hard-coded client defaults. For Docker Model Runner, set, for example:

embabel:
  agent:
    platform:
      models:
        docker:
          connect-timeout: 5s
          read-timeout: 30m

For a generic OpenAI-compatible provider, set the same connect-timeout and read-timeout properties in that provider's configuration. The patched implementation applies the values to both embedding and completion/chat clients and propagates them to Spring AI's per-request options, which otherwise send a 60-second timeout and override the HTTP client setting. Defaults remain 5 seconds for connect and 10 minutes for read. On older versions, the only workaround is to reduce the embedding batch size, e.g. split an 800-chunk request into smaller requests.