26.0.0.5 beta post

[navaneethsnair1]

https://blogs-draft-openlibertyio.mqj6zf7jocq.us-south.codeengine.appdomain.cloud/blog/2026/05/05/26.0.0.5-beta.html

[arkarkala]

1. The current Title - Transport Security - seems too high level and not convey the real updates (sounds like a new feature actually)
   How about - Update to TLS/SSL Cipher support

2. Example Usage ----> is that supposed to say Existing Usage? (and showing 2 CUSTOMs and enabledCiphers is confusing).
   Let's remove the first entry for both.

[rangaran]

[martindrozdz]

Hi @navaneethsnair1 , please replace these lines with:

<GHA-BLOG-SUMMARY>

The Model Context Protocol (MCP) has emerged as the standard for AI applications to access real-time information from external sources. The Liberty MCP Server feature mcpServer-1.0 allows developers to expose 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, your MCP server will be accessible at /custom-mcp instead of the default /mcp path.
Multiple Application Configurations for one EAR file are not yet supported.

Configuration Options

The <mcpServer> element supports the following attributes:

• path (single app): The custom path for the MCP endpoint (e.g., /custom-mcp)

Notable bug fixes in this release

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 returning arrays of objects, 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 ensures 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 could 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 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 could result in encoder beans from one application being incorrectly called in another application, unpredictable behavior in multi-application deployments.

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

</GHA-BLOG-SUMMARY>

[martindrozdz]

Please see my comments above.
I've added what I need replaced in the comments.