Open GenAI Stack 1.5 makes API selection explicit and moves MCP clients to 2.x

Open GenAI Stack 1.5 is not a drop-in upgrade for every deployment. The Oct. 9 release collects 108 commits since 1.4.0, adds MCP 2.x client support and new inference, search and storage integrations, but also changes how the server decides which HTTP APIs to expose.

API configuration now means what it says

The sharpest change is the treatment of apis:. In 1.4, apis: [] was indistinguishable from omitting the key and could expose every API supplied by configured providers. In 1.5, an explicit empty list is authoritative: it serves no provider-backed APIs. Omitting the key still means “serve everything,” while a bare apis: value is treated like an omitted key and produces a startup warning.

Route registration also follows a new three-tier rule. The merged routing change keeps admin, inspect and providers available for stack administration; serves conversations and prompts when they are listed or when responses is enabled; and serves other APIs only when they are listed. A deployment with an explicit list that omits responses must therefore add conversations or prompts if it expects those endpoints. Configurations that include responses, and configurations that omit apis:, retain the previous route surface.

That distinction matters most for gateways and split-service topologies. The project’s test case shows that removing responses from the list also turns off /v1/responses, /v1/conversations and /v1/prompts, while unrelated configured routes remain available. The same change notes that the bundled distributions already include responses, so their HTTP surface did not require configuration edits.

MCP 2.x is supported, with limits

The MCP integration now requires the MCP 2.x client SDK, resolving to 2.2.0 in the release work. OGX migrated its client code to renamed SDK attributes, switched transport exception handling to the SDK’s httpx2 dependency, moved custom headers onto a caller-owned asynchronous client and explicitly maps an HTTP 401 during connection to its authentication-required error.

The project reports end-to-end checks for both SSE and streamable HTTP transports, including server information, tool discovery, invocation, sessions, custom headers and the 401 path. Existing /sse URLs and distribution configurations remain unchanged. The same change explicitly leaves multi-round-trip elicitation, structuredContent, cache TTLs, reserved MCP headers and W3C trace propagation for follow-up work, so “MCP 2.x support” does not yet mean every new SDK capability is implemented.

Upgrade checklist

Before moving from 1.4, integrators should distinguish an omitted apis: key from an empty list, verify every route their gateway expects, and add conversations or prompts explicitly when responses is not exposed. Teams with custom MCP adapters should also test both transports, authentication failures and any code that depends on the old McpError name or httpx exception types. The 1.5 release notes describe 45 additional fixes and new providers, but the configuration and client-SDK transitions are the changes most likely to surface during rollout.