Updates to MCP Server and TLS/SSL Cipher Support in 26.0.0.5 Beta

Navaneeth S Nair on May 5, 2026

announcements , release , beta , security ,

Post available in languages:

This beta release updates the mcpServer-1.0 feature and simplifies SSL cipher configuration by using the effective JDK cipher list by default and flexible enabledCiphers syntax.

The Open Liberty 26.0.0.5-beta includes the following beta features (along with all GA features):

Updates to mcpServer-1.0
Update to TLS/SSL Cipher support

Updates to `mcpServer-1.0`

The Model Context Protocol (MCP) is an open standard that enables AI applications to access real-time information from external sources. The Liberty MCP Server feature mcpServer-1.0 allows developers to expose the business logic or data from their applications, allowing it to be integrated into agentic AI workflows.

This beta release of Liberty includes important updates to the mcpServer-1.0 feature, including configurable endpoint paths and notable bug fixes.

Prerequisites

To use the mcpServer-1.0 feature, it is required to have Java 17 or later installed on your system.

Configure custom MCP endpoint paths

Previously, the MCP endpoint was hard-coded to /mcp under the web application context root. You can now configure custom endpoint paths to better suit your application architecture and naming conventions.

Single Application Configuration

For a single application, configure the endpoint path directly in the <mcpServer> element:

<server description="Configurable Mcp Path Liberty server">

  <featureManager>
    <feature>servlet-6.0</feature>
    <feature>cdi-4.0</feature>
    <feature>mcpServer-1.0</feature>
  </featureManager>

  <application location="configurableMcpPathTests.war">
          <mcpServer path="/custom-mcp"/>
  </application>

  <include location="../fatTestPorts.xml" />

</server>

With this configuration, MCP server can be accessed at /custom-mcp instead of the default /mcp path.

Configuration Options

The <mcpServer> element supports the following attributes:

path (single app): The custom path for the MCP endpoint (for example, /custom-mcp)

Notable bug fixes in this release for `mcpServer-1.0`

1) Structured content output schemas now comply with MCP specification

The MCP specification requires that structured content output schemas must have an object type at the root level. Previously, when arrays of objects are returned, the schema incorrectly placed the array at the root level.

Previous Behavior (Incorrect):

{
  "outputSchema": {
    "description": "Returns list of person object",
    "type": "array",
    "items": {
      "$ref": "#/$defs/Person"
    }
  }
}

Current Behavior (Correct):

{
  "outputSchema": {
    "description": "Returns Persons object",
    "type": "object",
    "properties": {
      "persons": {
        "type": "array",
        "items": {
          "$ref": "#/$defs/Person"
        }
      }
    }
  }
}

This helps ensure that all structured content responses comply with the MCP structured content specification and improves compatibility with MCP clients and conformance tests.

2) Authentication failures now return correct HTTP status code

Previously, failed authentication attempts returned a 403 Forbidden response, which might be confusing as it typically indicates authorization (permission) failures rather than authentication (identity verification) failures.

Now, failed authentication attempts correctly return a 401 Unauthorized response, making it immediately clear that the issue is with authentication credentials rather than permissions. This behavior follows HTTP specification best practices and makes it easier to troubleshoot authentication configuration problems.

3) Fixed encoder bean isolation in multi-application deployments

Previously, encoder beans from multiple applications were stored in a static list within McpCdiExtension, causing beans from different applications to interfere with each other. This behavior could result in encoder beans from one application being incorrectly called in another application, unpredictable behavior in multi-application deployments, and potential security issues with cross-application bean access.

This has been fixed to ensure proper isolation of encoder beans per application, preventing cross-application interference and helping ensure that each application uses only its own encoder beans.

Update to TLS/SSL Cipher support

Liberty uses the effective JDK cipher list from the JDK. The securityLevel attribute in the SSL configuration is not used anymore. In addition, the enabledCiphers attribute in the SSL config is updated to customize the SSL ciphers in a more flexible way.

This change modifies the existing attribute enabledCiphers in the ssl config.

Liberty’s securityLevel based cipher categories no longer provide meaningful value. The MEDIUM and LOW categories contain no remaining ciphers.

The enabledCiphers attribute now has two mutually exclusive modes: (1) Specify a custom list of ciphers separated by spaces, or (2) Specify filter criteria to add (+) or remove (-) cipher suites from the effective JDK cipher list. If the value set in enabledCiphers contains a static entry and a +/- entry, an error is logged, and the server ignores the enabledCiphers value by returning the effective JDK cipher list.

Existing Usage - A user sets securityLevel as HIGH

<ssl id="defaultSSL" securityLevel=HIGH/>

Example with new syntax - securityLevel is not required and is ignored if provided

<ssl id="defaultSSL"/>

Existing Usage - A user specifies all ciphers from the effective jdk list excluding all TLS_RSA ciphers except for one (TLS_RSA_WITH_AES_128_GCM_SHA256)

<ssl id="defaultSSL" securityLevel="CUSTOM" enabledCiphers="TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_GCM_SHA256">

Example with new syntax - Use wildcards to achieve the same logic

<ssl id="defaultSSL" enabledCiphers="-TLS_RSA* +TLS_RSA_WITH_AES_128_GCM_SHA256"/>

To learn more about Transport Security, see SSL Constants Javadoc, JSSEProvider Javadoc, and SSL Configuration Reference.

Try it now

To try out these features, update your build tools to pull the Open Liberty All Beta Features package instead of the main release. To enable the MCP server feature, follow the instructions from MCP standalone blog. The beta works with Java SE 25, Java SE 21, Java SE 17, Java SE 11, and Java SE 8.

If you’re using Maven, you can install the All Beta Features package using:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.12.0</version>
    <configuration>
        <runtimeArtifact>
          <groupId>io.openliberty.beta</groupId>
          <artifactId>openliberty-runtime</artifactId>
          <version>26.0.0.5-beta</version>
          <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

You must also add dependencies to your pom.xml file for the beta version of the APIs that are associated with the beta features that you want to try. For example, the following block adds dependencies for two example beta APIs:

<dependency>
    <groupId>org.example.spec</groupId>
    <artifactId>exampleApi</artifactId>
    <version>7.0</version>
    <type>pom</type>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>example.platform</groupId>
    <artifactId>example.example-api</artifactId>
    <version>11.0.0</version>
    <scope>provided</scope>
</dependency>

Or for Gradle:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'io.openliberty.tools:liberty-gradle-plugin:4.0.0'
    }
}
apply plugin: 'liberty'
dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[26.0.0.5-beta,)'
}

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty:beta

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.

For more information on using a beta release, refer to the Installing Open Liberty beta releases documentation.