back to all blogsSee all blog posts

MCP Server (mcp-1.0), Protected Resource Metadata for openidConnectClient, and more in 26.0.0.9

image of author
Ismath Badsha on Sep 8, 2026
announcements , release , ai ,
Post available in languages:

Open Liberty 26.0.0.9 introduces MCP Server support (mcp-1.0), adds OAuth 2.0 Protected Resource Metadata support for openidConnectClient, and introduces custom session cache name prefixes for shared JCache clusters.

In Open Liberty 26.0.0.9:

View the list of fixed bugs in 26.0.0.9.

Check out previous Open Liberty GA release blog posts.

Develop and run your apps using 26.0.0.9

If you’re using Maven, include the following in your pom.xml file:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.12.3</version>
</plugin>

Or for Gradle, include the following in your build.gradle file:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'io.openliberty.tools:liberty-gradle-plugin:4.0.2'
    }
}
apply plugin: 'liberty'

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty

Or take a look at our Downloads page.

If you’re using IntelliJ IDEA, Visual Studio Code or Eclipse IDE, you can also take advantage of our open source Liberty developer tools to enable effective development, testing, debugging and application management all from within your IDE.

Ask a question on Stack Overflow

MCP Server (mcp-1.0)

The Model Context Protocol (MCP) is an open standard that enables AI applications to access real-time data and business logic from external sources. The MCP Server feature (mcp-1.0) lets application developers expose their Liberty application’s tools and data for use in agentic AI workflows by using just a few annotations.

Before mcp-1.0, there was no standard way to expose your Liberty application’s existing Java business logic to AI agents. You had to build and maintain custom integrations for each AI tool you wanted to connect to. With mcp-1.0, you annotate your existing CDI methods with @Tool and Liberty automatically handles the MCP protocol, tool discovery, session management, security, and observability. Your application becomes immediately usable by any MCP-compatible AI agent without changing your business logic.

What’s new in 26.0.0.9

After several beta releases, mcp-1.0 is now generally available. The most important change since the last beta (26.0.0.9-beta) is that the feature name changed from mcpServer-1.0 to mcp-1.0, and the server.xml configuration element changed from <mcpServer> to <mcp>. Update your server.xml as follows:

<featureManager>
    <feature>mcp-1.0</feature>
</featureManager>
<application location="my-app.war">
    <mcp path="/custom-mcp"/>
</application>

If you are migrating from 26.0.0.8-beta or earlier, the core API types also moved from io.openliberty.mcp. to org.mcpjava.server.. For full details on those import changes, see the 26.0.0.9-beta blog post.

The following capabilities are also new in this GA release and were not included in 26.0.0.9-beta:

  • DNS rebinding attack protection — When an MCP server receives a request from a loopback address, it now validates the Origin header as required by the MCP specification. No configuration needed.

  • @MetaField support on tool methods — Tool methods can be annotated with @MetaField to add data to the _meta object in tools/list responses.

  • outputSchemaFrom on @Tool — When structuredContent = true, you can specify a different class for generating the output schema, independent of the method return type.

  • Warnings for unsupported annotations — If your application uses MCP Java API annotations that are not supported by mcp-1.0 (such as @Prompt, @Resource, @ResourceTemplate), Liberty now logs a warning. The application still starts and @Tool-annotated methods continue to work.

  • OAuth 2.0 Protected Resource Metadata (RFC 9720) — When protectedResourceMetaDataEnabled="true" is configured on openidConnectClient, Liberty serves the protected resource metadata document at /.well-known/oauth-protected-resource. This enables MCP clients to automatically discover the correct authorization server following the MCP authorization flow.

For a full getting-started guide and examples, see the Expose your Liberty business logic as AI tools blog post and the mcp-1.0 feature documentation.

Protected Resource Metadata for openidConnectClient

OAuth 2.0 Protected Resource Metadata (RFC 9720) provides metadata about an OAuth 2.0-protected resource, including a link to the authorization server that can grant access.

In this release, Open Liberty servers that use the openidConnectClient-1.0 feature can enable protected resource metadata. Protected resource metadata can be enabled for any openidConnectClient configuration, but the primary use case is with the mcp-1.0 feature to support the MCP authorization flow. In this flow, the MCP client uses the protected resource metadata to discover the authorization server.

To enable protected resource metadata for an openidConnectClient configuration, add the <protectedResourceMetadata> configuration element:

<openidConnectClient id="protected-resource-demo"
    clientId="protected-resource"
    clientSecret="..."
    jwkEndpointUrl="https://auth.example.com/oidc/endpoint/SampleProvider/jwk"
    tokenEndpointAuthMethod="basic"
    issuerIdentifier="https://auth.example.com/oidc/endpoint/SampleProvider"
    authFilterRef="mcpAuthFilter"
    inboundPropagation="required">
    <protectedResourceMetadata />
</openidConnectClient>

For more information, see the OpenID Connect Client feature documentation and the openidConnectClient configuration reference.

Custom session cache name prefixes for shared JCache clusters

When you run multiple Liberty instances that share the same JCache-based session store — for example, several pods on Kubernetes or OpenShift pointing at the same Hazelcast or Infinispan cluster — Liberty previously generated identical session cache names on every instance. Identical cache names meant that separate instances could collide on the same cache, risking session data corruption in shared cache deployments.

Open Liberty 26.0.0.9 adds the new cacheNamePrefix attribute to the httpSessionCache element in the sessionCache-1.0 feature.The attribute is intended for operations teams and administrators who run multi-instance Liberty deployments backed by a shared cache cluster. Use it when each instance requires distinct cache namespacing to avoid collisions.

Previously, Liberty always generated session cache names as com.ibm.ws.session.meta. and com.ibm.ws.session.attr., with no way to distinguish which Liberty instance created them. Now, you can configure each instance with its own prefix, so the same shared cluster can safely host session data from multiple Liberty servers without cache name collisions. If no prefix is configured, the feature is fully backward compatible.

To configure a cache name prefix, add the cacheNamePrefix ` attribute to your `httpSessionCache configuration:

<!-- Instance 1 -->
<httpSessionCache cacheRef="InfinispanCacheManager" cacheNamePrefix="pod1_"/>
<!-- Instance 2 -->
<httpSessionCache cacheRef="InfinispanCacheManager" cacheNamePrefix="pod2_"/>

The prefixes result in distinct cache names for each instance — pod1_com.ibm.ws.session.attr.default_host/myapp and pod2_com.ibm.ws.session.attr.default_host/myapp. Without a prefix, both instances would generate the same com.ibm.ws.session.attr.default_host/myapp cache name. The cacheNamePrefix attribute is especially useful for:

  • Multi-tenant deployments

  • Blue-green deployments needing separate cache namespaces

  • Kubernetes/OpenShift deployments requiring pod-specific cache isolation

For more information about configuring session caching, see the httpSessionCache reference documentation.

Security vulnerability (CVE) fixes in this release

CVE CVSS Score Vulnerability Assessment Versions Affected Notes

CVE-2026-14529

9.4

Server-side request forgery

17.0.0.3-26.0.0.8

Affects the sipServlet-1.1 feature

CVE-2026-14981

7.5

Denial of service

17.0.0.3-26.0.0.8

Affects the servlet-3.1, servlet-4.0, servlet-5.0, servlet-6.0, and servlet-6.1 features

CVE-2026-15064

8.7

HTTP response smuggling

17.0.0.3-26.0.0.8

Affects the servlet-3.1, servlet-4.0, servlet-5.0, servlet-6.0, and servlet-6.1 features

CVE-2026-15328

7.4

HTTP request smuggling

17.0.0.3-26.0.0.8

Affects the servlet-3.1, servlet-4.0, servlet-5.0, servlet-6.0, and servlet-6.1 features

CVE-2026-15325

8.7

HTTP request smuggling

17.0.0.3-26.0.0.8

Affects the servlet-3.1, servlet-4.0, servlet-5.0, servlet-6.0, and servlet-6.1 features

CVE-2026-16192

7.1

Denial of service

17.0.0.3-26.0.0.8

Affects the restConnector-2.0 feature

CVE-2026-10571

5.7

Denial of service

17.0.0.3-26.0.0.8

Affects the restConnector-2.0 feature

CVE-2026-54225

7.5

Denial of service

17.0.0.3-26.0.0.8

Affects the jaxrs-2.0, jaxrs-2.1, jaxws-2.2, xmlWS-3.0, and xmlWS-4.0 features

CVE-2026-57819

7.5

Denial of service

17.0.0.3-26.0.0.8

Affects the jaxrs-2.0, jaxrs-2.1, jaxws-2.2, xmlWS-3.0, and xmlWS-4.0 features

CVE-2026-64958

7.5

Denial of service

17.0.0.3-26.0.0.8

Affects the jaxrs-2.0, jaxrs-2.1, jaxws-2.2, xmlWS-3.0, and xmlWS-4.0 features

For a list of past security vulnerability fixes, reference the Security vulnerability (CVE) list.

Notable bugs fixed in this release

We’ve spent some time fixing bugs. The following sections describe just some of the issues resolved in this release. If you’re interested, here’s the full list of bugs fixed in 26.0.0.9.

Get Open Liberty 26.0.0.9 now

Available through Maven, Gradle, Docker, and as a downloadable archive.