1. Installation Guide
  2. Siebel AI Connectors

Siebel AI Connectors

This topic provides an overview of Siebel AI Connectors. Siebel AI Connectors enable customers to expose selected Siebel Open Integration REST APIs as Model Context Protocol (MCP)-compatible tools and servers for consumption by AI agents and assistant applications.

Siebel Open Integration exposes Siebel objects, services and workflows through REST APIs. These APIs are powerful and flexible for direct system-to-system integration. However, AI agents require a more structured interface for interacting with enterprise systems.

Siebel AI Connectors provide a configuration-driven framework for exposing selected Open Integration REST APIs as MCP tools. Customers identify the Open Integration REST APIs they want to expose, define MCP tool metadata & maintain a centralized catalog, group those tools into MCP Servers, and once configured deploy these servers either on-premises or via Siebel Cloud Manager(SCM). The Siebel AI Connectors runtime then realizes the configured MCP Servers and exposes runtime endpoints that AI agents can use to discover and invoke the configured tools.

By using Siebel AI Connectors, customers can expose only the Open Integration operations that are relevant for an AI-agent use case, keep access to Siebel data and actions controlled, and align agent behavior with business processes.

This topic covers the following sections:

  1. Installing Siebel AI Connectors
  2. Configuring Siebel AI Connectors
  3. Deploying Siebel AI Connectors

Installing Siebel AI Connectors

This topic describes how to install Siebel AI Connectors.

Siebel AI Connectors can work with on-premises environments and in Kubernetes-based environments managed through Siebel Cloud Manager. The deployment model determines how the runtime package and configuration artifacts are delivered, but the core runtime behavior remains the same.

In an on-premises deployment, the runtime package includes the artifacts required to run Siebel AI Connectors in the target environment.

In a Siebel Cloud Manager deployment, the Siebel AI Connectors runtime is deployed in a Kubernetes-based environment. Configuration artifacts are provided as part of the deployment process. More details to how we can work with Siebel Cloud Manager to deploy and manage Siebel AI Connectors can be found in the Deploying Siebel AI Connectors section of this topic. For more details on SCM, please read the Administration Bookshelf guide for Siebel Cloud Manager.

Note:
  • Open Integration installation and configuration is a prerequisite to ensure that your Siebel AI Connectors works properly.
  • During the installation process, don't modify the runtime JAR or dependent libraries. Update only the configuration files.

On-Premises Package Contents

The on-premises runtime package includes the runtime JAR, dependent libraries, and configuration template files.

The package includes the following artifacts:


mcp-runtime/
  ├── mcp-runtime-<version>.jar.              # Do not Modify
  ├── libs/					   # Do not Modify     
  ├── application.yaml			     # Configuration File
  ├── logging.properties 			  # Configuration File
  ├── MCP_CONFIG.json			      # Configuration Files
  ├── FINAL_SPECIFICATION.json	          # Configuration Files
  ├── OI_CONFIG.json                          # Configuration Files

On-Premises Installation for Windows & Linux

Windows Installer

Interactive Installation

Use this procedure to install Siebel AI Connectors on Windows by using the interactive installer.

  1. Download and extract the Siebel AI Connectors installer artifacts.
  2. Review the README file provided with the installer package.
  3. Start the installer by running the Windows installer command.
  4. Select the installation directory.
  5. Select the Siebel AI Connectors component.
  6. Review the installation summary.
  7. Click Install.
  8. After installation completes, verify that the Siebel AI Connectors artifacts are created in the selected installation directory.
  9. Configure the runtime artifacts before starting the Siebel MCP Server.

Silent Installation

Use this procedure to install Siebel AI Connectors on Windows in silent mode.

  1. Run the installer and proceed to the Summary screen.
  2. Save the response file.
  3. Review the response file and verify that the installation directory is correct.
  4. Run the installer in silent mode using the generated response file.
  5. After installation completes, verify that the Siebel AI Connectors artifacts are created in the selected installation directory.

Linux Installer

Interactive Installation

Use this procedure to install Siebel AI Connectors on Linux by using the interactive installer.

  1. Download and extract the Siebel AI Connectors installer artifacts.
  2. Review the README file provided with the installer package.
  3. Start the installer by running the Linux installer command.
  4. Select the installation directory.
  5. Select the Siebel AI Connectors component.
  6. Review the installation summary.
  7. Click Install.
  8. After installation completes, verify that the Siebel AI Connectors artifacts are created in the selected installation directory.
  9. Configure the runtime artifacts before starting the Siebel MCP Server.

Silent Installation

Use this procedure to install Siebel AI Connectors on Linux in silent mode.

  1. Run the installer and proceed to the Summary screen.
  2. Save the response file.
  3. Review the response file and verify that the installation directory is correct.
  4. Run the installer in silent mode using the generated response file.
  5. After installation completes, verify that the Siebel AI Connectors artifacts are created in the selected installation directory.

Configuring Siebel AI Connectors

This section describes how to configure Siebel AI Connectors, prepare MCP tools from Siebel Open Integration REST APIs, secure MCP endpoints, and validate runtime behavior.

Siebel AI Connectors are intended to be used with Siebel Open Integration. After Open Integration is configured and running, it exposes the resources defined for API generation under config.json as standard REST APIs. The corresponding OpenAPI specification available from the Open Integration runtime describes the exposed resources, paths, HTTP methods, parameters, request bodies, and schemas.

Customers use the Open Integration REST APIs and the corresponding OpenAPI specification as the starting point to decide which operations should be selectively exposed as MCP tools. The selected operations and tool metadata are represented in FINAL_SPECIFICATION.json, grouped into MCP Servers using MCP_CONFIG.json, connected to Open Integration using OI_CONFIG.json, and loaded by the runtime using application.yaml and logging.properties.

Configuration Prerequisites

Before configuring or deploying Siebel AI Connectors, complete the following prerequisites.

Open Integration

Siebel Open Integration must be installed, configured, and running before Siebel AI Connectors can be configured.

Check Description
Open Integration is installed and configured. Siebel AI Connectors depend on Open Integration REST APIs as the source APIs for MCP tools.
Open Integration runtime is running. The runtime must expose the configured resources as standard REST APIs.
OpenAPI specification is available from the Open Integration runtime. The OpenAPI specification describes the resources, paths, HTTP methods, parameters, request bodies, and schemas available for tool creation.
Target Open Integration server details are known. These values are required in OI_CONFIG.json, including server name, scheme, host, port, and context.

Tool Selection

Before creating or updating FINAL_SPECIFICATION.json, identify which Open Integration operations should be exposed as MCP tools.

Check Description
Required business use case is identified. Only expose APIs required by the intended AI-agent use case.
Required Open Integration resources are identified. For example, Account, Contact, Product, Service Request, or other configured resources.
Required API operations are selected. Select the required paths and HTTP methods, such as get, post, put, or delete.
Tool names and descriptions are planned. Tool names should be stable, and descriptions should be clear enough for MCP clients and AI agents.
Required request inputs are understood. Review path, query, header parameters, and request body schemas.
Security impact is reviewed. Avoid exposing create, update, or delete operations unless the AI-agent use case requires them.

Runtime Package

The Siebel AI Connectors runtime package must be available on the target environment.

Check Description
mcp-runtime-<version>.jar is present. Runtime application binary. Do not modify.
libs/ is present. Runtime dependencies. Do not modify.
application.yaml is present. Defines runtime server settings, security settings, and configuration file locations.
logging.properties is present. Defines runtime logging behavior.
MCP_CONFIG.json is present. Defines MCP Servers and tool mappings.
FINAL_SPECIFICATION.json is present. Defines selected tools in OpenAPI-compatible format.
OI_CONFIG.json is present. Defines Open Integration server instances.

Security

If JWT authentication is enabled for Siebel AI Connectors, verify the following:

Check Description
Identity provider is configured. For example, OCI Identity Domain or the configured OAuth provider.
JWT issuer is known. Required in security.jwt.issuer.
JWT audience is known. Required in security.jwt.audience.
Required OAuth scope is known. Required in security.jwt.required-scope. Scope Siebel AI Connectors should match with what is defined for Open Integration.
JWKS URI is available. Required in security.jwt.jwks-uri.
Open Integration authentication is aligned. If Siebel AI Connectors uses OAuth/JWT authentication, Open Integration must also be configured to accept the corresponding authentication flow.
Test token can be generated. Required for secured endpoint validation.

High-Level Configuration Overview

To ensure that you can start your MCP Servers using Siebel AI Connectors, the following diagram provides a high level guidance on the activities you need to perform when working with the product:

  1. Review Open Integration API(s): Open Integration is the source of all MCP tools available in FINAL_SPECIFICATION.json for Siebel AI Connectors. Begin by reviewing the OpenAPI specification generated by Open Integration, for the target resource & identify the REST operations that support your AI use case. Rather than exposing every available operation, select only the APIs that an AI agent needs to perform its tasks. This helps minimize unnecessary access and simplifies tool management.
  2. Define MCP Tool(s): After identifying the required operations, move relevant APIs into the FINAL_SPECIFICATION.json and create MCP tool definitions that describe how those APIs will be presented to AI agents. Each MCP tool represents a specific business capability, such as retrieving account information or updating a service request. The tool definitions become the catalog of capabilities that can later be assigned to MCP Servers.
  3. Add Open Integration instance(s): Ensure that the OI_CONFIG.json is updated with relevant Open Integration instances which have relevant APIs updated as part of the FINAL_SPECIFICATION.json file.
  4. Organize Tools into MCP Server(s): Group related MCP tools into one or more MCP Servers in the MCP_CONFIG.json file. A server can represent a business domain, application area, or functional capability. For example, one server might expose customer-related tools while another exposes product-related operations. Organizing tools into logical servers makes them easier for AI agents to discover and consume.
  5. Configure the Runtime: Once the tools and servers have been defined, configure the remaining configuration files - application.yaml & logging.properties with appropriate details. The runtime uses these configured files to establish connections with the configured Open Integration instances, initializes the MCP Servers, and exposes the corresponding endpoints for AI clients.
  6. Deploy and Validate: Deploy the configured runtime to your target environment, either on-premises or using Siebel Cloud Manager.After deployment, verify that:
    • The runtime starts successfully.
    • The MCP Server endpoints are available.
    • AI clients can discover the configured servers.
    • The exposed tools successfully invoke the corresponding Open Integration REST APIs.

Although creating an MCP Server is primarily a configuration activity, the runtime uses several configuration artifacts to describe the tools, servers, runtime settings, Open Integration connections, and logging behavior. These artifacts work together to define what capabilities are exposed and how the runtime operates. Each artifact has a specific purpose and should be configured consistently before deployment.

Inspecting Open Integration

Open Integration is the source for APIs exposed through Siebel AI Connectors. After Open Integration is configured and running, the resources defined for API generation under config.json are exposed as standard REST APIs. The corresponding OpenAPI specification from the Open Integration runtime provides metadata for the exposed resources, including paths, HTTP methods, parameters, request bodies, and schemas.

Use these available Open Integration APIs as the starting point for tool selection. Not every Open Integration operation needs to be exposed as an MCP tool. Select only the operations required for the AI-agent use case.

To prepare MCP tools:

  1. Confirm that the required Open Integration resources are configured for API generation under config.json.

  2. Start or verify the Open Integration runtime.

  3. Use the describe operation available for the target Siebel artifact configured on Open Integration, to fetch and review the corresponding OpenAPI specification.

  4. Identify the API paths and HTTP methods that should be exposed to AI agents.

  5. Define the selected operations and MCP tool metadata in FINAL_SPECIFICATION.json.

  6. Group the selected tools into MCP Servers using MCP_CONFIG.json.

The following example shows an Open Integration Account resource exposed as REST API operations:

{
  "paths": {
    "/openintegration/v1.0/data/Account/Account/": {
      "get": {
        "operationId": "openintegration_v1.0_data_Account_Account__get"
      },
      "put": {
        "operationId": "openintegration_v1.0_data_Account_Account__put"
      },
      "post": {
        "operationId": "openintegration_v1.0_data_Account_Account__post"
      }
    }
  }
}

In this example, the Account resource exposes get, put, and post operations. The implementation team can evaluate these operations and decide which ones should be selectively created as MCP tools.

Open Integration Operation Expose as MCP Tool? Guidance
GET /openintegration/v1.0/data/Account/Account/ Common Expose when the AI-agent use case requires account lookup or retrieval.
PUT /openintegration/v1.0/data/Account/Account/ Conditional Expose only if the AI-agent use case is allowed to update account data.
POST /openintegration/v1.0/data/Account/Account/ Conditional Expose only if the AI-agent use case is allowed to create account data.

After the tool selection is complete, define the selected operations in FINAL_SPECIFICATION.json and map them to MCP Server endpoints using MCP_CONFIG.json.

Configuring Siebel AI Connectors Files

Only the configuration files should be updated. Do not modify mcp-runtime-<version>.jar or files under libs/. The below table captures details on individual configuration files available for developers to make necessary changes to configure MCP Tools & Servers:

File or Folder Purpose Update Guidance
FINAL_SPECIFICATION.json Cumulated tools in OpenAPI-compatible format. Defines MCP tool metadata and Open Integration operation mappings. Generated or updated by configuration-time tooling. Do not manually update unless instructed.
MCP_CONFIG.json MCP Server configuration. Maps MCP Servers to tool names from FINAL_SPECIFICATION.json. Update when MCP Server grouping or endpoint mapping changes.
application.yaml Runtime configuration. Defines server host, port, security settings, and paths to runtime configuration files. Update when runtime settings, security settings, or file locations change.
OI_CONFIG.json Open Integration instance configuration. Defines Open Integration servers used by the runtime. Update when Open Integration server details change.
logging.properties Runtime logging configuration. Update when logging levels or logging behavior need to change.

FINAL_SPECIFICATION.json

FINAL_SPECIFICATION.json is the runtime-consumable tool specification used by Siebel AI Connectors to create MCP tool definitions from selected Open Integration REST API operations. It is modeled on the OpenAPI Specification and allows developers to define:

  • Open Integration API paths and HTTP methods selected for exposure.
  • List of tool names available as part of the FINAL_SPECIFICATION.json
  • Tool metadata - tool name, descriptions and so on are defined for selected Open Integration paths and HTTP operations.
  • Open Integration server mappings.
  • Parameters, request bodies, and schemas used to build and validate MCP tool inputs.

The delivered template uses the following top-level structure:

{
  "openapi": "<version>",
  "info": {
    "title": "<Title>",
    "description": "<Description>",
    "contact": {
      "email": "sample@sample.com"
    },
    "version": "<version>"
  },
  "externalDocs": {
    "description": "<description>",
    "url": "<url>"
  },
  "servers": [
    {
      "url": "<Server Base Url>",
      "x-server-name": "<Server Instance Name>"
    }
  ],
  "x-tools": [
    "<Tool Name>"
  ],
  "tags": [
    {
      "name": "<tag>"
    }
  ],
  "paths": {
    "<Path>": {
      "<http-method>": {
        "x-tool-name": "<Tool Name>",
        "x-server-name": "<Server Instance Name>",
        "tags": [
          "<tag>"
        ],
        "operationId": "<Operation Id>",
        "description": "<Description>",
        "summary": "<Summary>",
        "parameters": [],
        "requestBody": {},
        "responses": {}
      }
    }
  },
  "components": {
    "schemas": {}
  },
  "x-original-swagger-version": "3.0"
}

Top-Level Fields

Field Required Description
components Recommended Contains schemas referenced by parameters or request bodies.
externalDocs Optional External documentation reference.
info Recommended OpenAPI metadata, including title, description, contact, and version.
openapi Yes OpenAPI version used by the specification.
paths Yes Contains Open Integration API paths and operations selected for tool generation.
servers Yes Server entries from the OpenAPI specification. Runtime reads these for server-name and URL comparison or logging. The downstream base URL is resolved from OI_CONFIG.json.
tags Optional OpenAPI tags used for grouping operations.
x-original-swagger-version Optional Preserves source Swagger/OpenAPI version metadata.
x-tools Yes List of all tools present in the file.

Additional Details on Fields for FINAL_SPECIFICATION.json

The following describes additional information on the different fields described in the above table, in scope of the FINAL_SPECIFICATION.json

  1. servers

    The servers array contains OpenAPI server definitions and logical server names.

    
"servers": [
  {
    "url": "<Server Base Url>",
    "x-server-name": "<Server Instance Name>"
  }
]
    Field Required Description
    url Yes Server base URL from the OpenAPI specification.
    x-server-name Yes Logical server instance name. Operation-level x-server-name values use this name to identify the Open Integration server mapping.

    The runtime reads top-level servers for server-name and URL comparison or logging. It does not use the top-level server URL directly as the downstream base URL. The downstream server URL is resolved from OI_CONFIG.json.

  2. x-tools

    The x-tools field lists all tool names present in FINAL_SPECIFICATION.json. Each operation-level x-tool-name should be present in the top-level x-tools array.

    "x-tools": [
  "Account GET",
  "Account PUT",
  "Account POST"
]
  3. paths

    The paths object contains the selected Open Integration API paths and HTTP method that can be realized as MCP Tools by the Siebel AI Connectors runtime.

    Sample:

"paths": {
  "/openintegration/v1.0/data/Account/Account/": {
    "get": {
         .....
    },
    "put": {
         .....
    }
  }
}
    Field Required Description
    Path key Yes OpenAPI path, for example /accounts/{id} or /openintegration/v1.0/data/Account/Account/.
    HTTP method Yes HTTP operation under the path, such as get, post, put, or delete.
  4. HTTP method Fields

    For Siebel AI Connectors, we map individual HTTP methods(GET, PUT, POST and DELETE) defined under a "path" to an MCP Tool in the FINAL_SPECIFICATION.json file. Each selected HTTP method defines the OpenAPI operation and MCP-specific metadata. The following table captures relevant information on the different key-value pairs that should be configured:

    Field Required Description
    x-tool-name Recommended Primary source for the MCP tool name. If absent or blank, operationId is used as the fallback tool name.
    x-server-name Optional Identifies which server entry from OI_CONFIG.json the tool sends the downstream request to. If missing, the default server from OI_CONFIG.json is used.
    operationId Yes Used as fallback MCP tool name when x-tool-name is absent or blank. Also used in description fallback behavior.
    description Recommended Primary source for the MCP tool description. Can be updated by user to reflect the tool description they would want to provide for the selected operation.
    summary Optional Fallback MCP tool description when description is absent or blank.
    tags Optional Provided by the Open Integration OpenAPI Spec.
    parameters Conditional Provided by the Open Integration OpenAPI Spec.
    requestBody Conditional Provided by the Open Integration OpenAPI Spec. Required when the operation expects a request body. Used to build the body argument in the MCP input schema.
    responses Recommended Provided by the Open Integration OpenAPI Spec.
  5. parameters

    Parameters are available for certain HTTP methods available for a given path. These parameters are specified in Open Integration's OpenAPI spec and are added as needed in the FINAL_SPECIFICATION.json for the associated path and HTTP method.

    Sample:

"parameters": [
  {
    "name": "Id",
    "in": "query",
    "description": "Account identifier.",
    "schema": {
      "type": "string"
    }
  }
]
    Field Required Description
    in Yes Provided via the Open Integration OpenAPI Spec
    name Yes Provided via the Open Integration OpenAPI Spec
    schema Yes Provided via the Open Integration OpenAPI Spec
    description Recommended Optionally available. Should be added for the parameter for proper usage with the MCP tool.
  6. components.schemas

    The components.schemas section defines schemas used by parameters and request bodies.

    Sample:

"components": {
  "schemas": {
    "AccountUpdate": {
      "type": "object",
      "additionalProperties": false,
      "required": [
        "Name"
      ],
      "properties": {
        "Name": {
          "type": "string",
          "description": "Account name."
        }
      }
    }
  }
}
    Field Description
    required Validated for request body. This is distinct from the generated top-level tool required array.
    additionalProperties

    Controls whether unexpected body fields are allowed in a request body. Can be set to true or false.

    If set to false, unexpected body fields are rejected.

    If set to true, additional fields are allowed as part of the Request Body.

    description Exposed to clients. Body descriptions appear on properties.body.
    discriminator Preserved. Runtime has no discriminator-specific logic, although schema composition may apply where supported.

MCP_CONFIG.json

MCP_CONFIG.json defines MCP Servers and maps each MCP Server to tool names from FINAL_SPECIFICATION.json.

Sample:


{
  "mcp-servers": [
    {
      "mcp-server-name": "GET",
      "mcp-server-path": "/account1",
      "mcp-server-description": "Account 1 Description",
      "mcp-server-version": "1.0.0",
      "mcp-server-tools": [
        "Account GET",
        "Account PUT",
        "Account POST"
      ]
    },
    {
      "mcp-server-name": "PUT",
      "mcp-server-path": "/account2",
      "mcp-server-description": "Account 2 Description",
      "mcp-server-version": "1.0.0",
      "mcp-server-tools": [
        "Account GET",
        "AccountMethod POST",
        "AccountKeyMethod POST"
      ]
    }
  ]
}
Field Required Description
mcp-servers Yes Array of MCP Server definitions.
mcp-server-name Yes Name of the MCP Server.
mcp-server-path Yes Runtime endpoint path for the MCP Server. Must be unique for each MCP Server.
mcp-server-description Yes Description of the MCP Server.
mcp-server-version Yes MCP Server version.
mcp-server-tools Yes List of tool names exposed by this MCP Server. Each value should be present under x-tools in FINAL_SPECIFICATION.json

Rules:

  • Each mcp-server-path must be unique.

  • Each tool in mcp-server-tools must exist in FINAL_SPECIFICATION.json.

  • Tool names are matched by exact string.

OI_CONFIG.json

OI_CONFIG.json defines Open Integration instance(s) used by the runtime.

Sample:

{
  "default-server": "<server-name-1>",
  "servers": [
    {
      "name": "<server-name-1>",
      "scheme": "<scheme>",
      "host": "<host>",
      "port": 8433,
      "context": "<context>"
    },
    {
      "name": "<server-name-2>",
      "scheme": "<scheme>",
      "host": "<host>",
      "port": 8433,
      "context": "<context>"
    }
  ]
}
Field Required Description
default-server Yes Default Open Integration server. Used when operation-level x-server-name is missing or unknown.
servers Yes List of Open Integration server definitions.
name Yes Logical Open Integration server name. This should match operation-level x-server-name values in FINAL_SPECIFICATION.json.
scheme Yes Protocol used for Open Integration, such as http or https.
host Yes Open Integration host.
port Yes Open Integration port.
context Yes Open Integration context path.
Rules:

  • default-server must match one of the servers[].name values.

  • Each servers[].name must be unique.

  • Operation-level x-server-name values in FINAL_SPECIFICATION.json should resolve to entries in OI_CONFIG.json.

  • If operation-level x-server-name is missing or unknown, the runtime uses default-server.

logging.properties

The logging.properties defines runtime logging behavior and must be referenced from application.yaml using mcp.logging-properties-file.

The file should be placed in the same folder as mcp-runtime-<version>.jar unless the path in application.yaml is updated.

handlers=io.helidon.logging.jul.HelidonConsoleHandler
java.util.logging.SimpleFormatter.format=%1$tY.%1$tm.%1$td %1$tH:%1$tM:%1$tS.%1$tL %4$s %5$s%6$s%n

# Global logging level. Can be overridden by specific loggers
.level=SEVERE
io.helidon.level=SEVERE
Field Description
handlers Defines the logging handler used by the runtime.
java.util.logging.SimpleFormatter.format Defines the log message format.
.level Global logging level. Can be overridden by specific loggers.
io.helidon.level Logging level for Helidon runtime loggers.

application.yaml

application.yaml defines runtime server settings, JWT security settings, and configuration file paths.

Sample:

server:
  port: <port>
  host: <host>

security:
  jwt:
    enabled: true
    issuer: <issuer>
    audience: <audience>
    required-scope: <scope>
    clock-skew-seconds: <seconds>
    jwks-uri: "<jwks-uri>"
    jwks-cache-duration-seconds: <duration>

mcp:
  server-config-file: <path to MCP_CONFIG.json>
  final-spec-file: <path to FINAL_SPECIFICATION.json>
  logging-properties-file: <path to logging.properties>
  open-int-config-file: <path to OI_CONFIG.json>
Field Required Description
server.port Yes Runtime server port. Change this if the configured port is already in use.
server.host Yes Runtime server host.
security.jwt.enabled Required when JWT is used Enables or disables JWT validation.
security.jwt.issuer Required when JWT is used Expected token issuer.
security.jwt.audience Required when JWT is used Expected token audience.
security.jwt.required-scope Required when JWT is used Required OAuth scope for MCP requests.
security.jwt.clock-skew-seconds Recommended when JWT is used Allowed clock skew during token validation.
security.jwt.jwks-uri Required when JWT is used JWKS URI used to validate JWT signatures.
security.jwt.jwks-cache-duration-seconds Recommended when JWT is used Duration for JWKS cache.
mcp.server-config-file Yes Path to MCP_CONFIG.json.
mcp.final-spec-file Yes Path to FINAL_SPECIFICATION.json.
mcp.logging-properties-file Yes Path to logging.properties.
mcp.open-int-config-file Yes Path to OI_CONFIG.json.

Security and Authentication

Siebel AI Connectors support OAuth 2.0 JWT-based authentication. When JWT authentication is enabled, each request to an MCP Server endpoint must include a valid access token.

The runtime validates the token using the JWT configuration in application.yaml.

security:
  jwt:
    enabled: true
    issuer: <issuer>
    audience: <audience>
    required-scope: <scope>
    clock-skew-seconds: <seconds>
    jwks-uri: "<jwks-uri>"
    jwks-cache-duration-seconds: <duration>
Field Required Description
security.jwt.enabled Yes Enables JWT authentication.
security.jwt.issuer Yes Expected token issuer.
security.jwt.audience Yes Expected token audience.
security.jwt.required-scope Yes OAuth scope required to invoke MCP endpoints.
security.jwt.clock-skew-seconds Recommended Allowed clock skew during token validation.
security.jwt.jwks-uri Yes JWKS endpoint used to validate token signatures.
security.jwt.jwks-cache-duration-seconds Recommended Duration for JWKS cache.

In a secured deployment:

  1. The MCP client generates an OAuth access token from the configured identity provider.

  2. The MCP client sends the request to the MCP Server endpoint with an authorization header.

  3. The Siebel AI Connectors runtime validates the JWT.

  4. After validation, the runtime invokes the configured Open Integration REST API.

Note: Authorization: Bearer <access_token>

The authentication configuration must be consistent across Siebel AI Connectors and Open Integration. If Siebel AI Connectors uses OAuth/JWT authentication, Open Integration must also be configured to accept the corresponding authentication flow.

Consistency Checklist

Before starting or deploying the runtime, verify the following:

Check Required
Every tool in MCP_CONFIG.json has a mapping in FINAL_SPECIFICATION.json. Yes
Every operation-level x-tool-name is listed in top-level x-tools. Yes
mcp.server-config-file points to MCP_CONFIG.json. Yes
mcp.final-spec-file points to FINAL_SPECIFICATION.json. Yes
mcp.logging-properties-file points to logging.properties. Yes
mcp.open-int-config-file points to OI_CONFIG.json. Yes
Every operation-level x-server-name resolves to an entry in OI_CONFIG.json, or default-server is configured for fallback. Yes
OI_CONFIG.json defines a valid default-server. Yes
Each mcp-server-path is unique. Yes
Request bodies use application/json. Yes
Supported parameter locations are path, query, and header. Yes

Deploying Siebel AI Connectors

This section describes how to deploy Siebel AI Connectors after the required configuration files are prepared.

Siebel AI Connectors can be deployed in an on-premises environment or through Siebel Cloud Manager. In both deployment models, the runtime uses the configured artifacts to create MCP Servers, expose MCP-compatible tools, and connect those tools to the selected Siebel Open Integration REST APIs.

Before deploying Siebel AI Connectors, verify that application.yaml, MCP_CONFIG.json, FINAL_SPECIFICATION.json, OI_CONFIG.json, and logging.properties are updated for the target environment. Also verify that Siebel Open Integration is installed, configured, and running.

The deployment topics include:

  • Deploying Siebel AI Connectors - On-Premise
  • Deploying Siebel AI Connectors - Siebel Cloud Manager
  • Runtime Behavior and Validations

Deployment Prerequisites

Java and Certificate Prerequisites

For on-premises runtime startup, verify the following:

Prerequisite Description
JRE 21 is available. Configure JAVA_HOME and PATH for the JRE delivered or supported with the Siebel installer.
Required certificates are trusted. If Open Integration uses TLS, import the required Siebel or Open Integration certificate into the Java truststore used by the runtime.
Truststore path and password are known. Required when configuring Java truststore behavior for deployment or runtime.

Example certificate import command on Linux:

keytool -importcert -trustcacerts -alias siebel \
  -file "<FS path>/siebel.crt" \
  -keystore "<FS path>/jre/lib/security/cacerts" \
  -storepass changeit \
  -noprompt

Example certificate import command on Windows:

keytool -importcert -trustcacerts -alias siebel ^
  -file "<FS path>\siebel.crt" ^
  -keystore "<FS path>\jre\lib\security\cacerts" ^
  -storepass changeit ^
  -noprompt

SCM Deployment Prerequisites

For Siebel Cloud Manager deployment, verify the following before deploying Siebel AI Connectors:

Prerequisite Description
Siebel Cloud Manager is available. SCM APIs are used to create infrastructure and deploy Siebel AI Connectors.
Kubernetes environment is available. For example, BYO OCNE, OKE, or another supported Kubernetes target.
Infrastructure input is available. Namespace, kubeconfig path or cluster details, operator options, registry details, and GitOps details are required.
Customer Git repository is available. Runtime configuration artifacts are maintained in Git.
Git access credentials are available. HTTPS token, self-signed CA path, or SSH private key path may be required.
Git repository is registered with SCM. SCM returns a git_id used in the deployment payload.
Container registry access is available. Registry URL, user, password or token, and registry prefix are required.
Configuration files are committed to Git. application.yaml, MCP_CONFIG.json, FINAL_SPECIFICATION.json, OI_CONFIG.json, and logging.properties must be available in the configured Git folder.
Truststore file is available when required. The deployment payload can reference the Java truststore path and password.
Namespace is created when using BYO namespace. If byo_ns is true, create the namespace before deployment and use the namespace value in the deployment name field.
Security context values are known when required. If a custom security context is used, provide run_as_user, run_as_group, and fs_group.

Deploying Siebel AI Connectors - On-Premises

This topic describes how to deploy Siebel AI Connectors in an on-premises environment after the required configuration files are prepared.

In an on-premises deployment, Siebel AI Connectors are started from the delivered runtime package. Before starting the runtime, verify that the configuration files are present, that the Open Integration server details are correct, and that the Java prerequisites are complete.

Before You Begin

Before deploying Siebel AI Connectors on-premise, make sure that:

  • Siebel Open Integration is installed, configured, and running.
  • The Open Integration REST APIs selected for MCP tool exposure are available.
  • The Siebel AI Connectors runtime package is installed.
  • The required configuration files are updated for the target environment.
    • Navigate to the Siebel AI Connectors runtime directory and verify that the necessary files, libs and folders are present.
    • Verify that application.yaml contains the correct runtime settings and file paths.
      • server.port is available on the target host.
      • server.host is correct for the deployment.
      • The paths under mcp point to the correct files.
      • JWT settings are correct, if authentication is enabled.
    • Verify that OI_CONFIG.json contains the Open Integration server instances used by the runtime.
      • default-server matches one of the server names in the servers array.
      • Each server name is unique.
      • scheme, host, port, and context are correct for the Open Integration environment.
      • The runtime host can connect to each configured Open Integration server.
    • Verify that FINAL_SPECIFICATION.json contains the selected Open Integration operations and MCP tool metadata.
      • The required tools are present.
      • Tool names are unique.
      • Tool names used in MCP_CONFIG.json match the names in FINAL_SPECIFICATION.json.
      • The Open Integration server mappings are correct.
    • Verify that MCP_CONFIG.json defines the MCP Servers and maps each server to one or more tools from FINAL_SPECIFICATION.json.
      • Each mcp-server-path is unique.
      • Each tool listed in mcp-server-tools exists in FINAL_SPECIFICATION.json.
      • Tool names match exactly between MCP_CONFIG.json and FINAL_SPECIFICATION.json.
  • JRE 21 is configured.
  • Required certificates are imported into the Java truststore, if Open Integration uses TLS.

Start the Siebel AI Connectors Runtime

After verifying the configuration files and necessary prerequisites, start the runtime from the runtime directory.

For Windows, run:


java -cp ".\mcp-runtime-<version>.jar;.\libs\*" com.oracle.siebel.mcp.Main

For Linux, run:


java -cp "./mcp-runtime-<version>.jar:./libs/*" com.oracle.siebel.mcp.Main

Replace <version> with the version of the runtime JAR delivered in the package.

Verify Runtime Startup

After starting the runtime, review the startup logs.

Look for log messages that confirm the following:

  • FINAL_SPECIFICATION.json was parsed successfully.
  • Open Integration servers were loaded.
  • The default Open Integration server was identified.
  • Tools were processed from the OpenAPI specification.
  • The runtime selected the Open Integration server for each tool.
  • MCP tools were adapted from the OpenAPI specification.
  • MCP Servers were started successfully.
  • The base MCP Server URL was created.

Example log messages:

INFO Successfully parsed OpenAPI spec file:<Path>/FINAL_SPECIFICATION.json

INFO Loaded Open Integration servers: [OI123, OI456]; default server: OI456

INFO Processing Tool : [Account GET] , Method : [GET] , Path: [/openintegration/v1.0/data/Account/Account/]

INFO Using Open Integration server [OI456] for tool [Account GET]

INFO Adapted [20] tools from OpenAPI spec

INFO Started all channels in 8 milliseconds. 590 milliseconds since JVM startup. Java 21.0.11

INFO MCP Servers started with base url: 0.0.0.0:8081/siebelAIConnectors/mcp

If the runtime does not start successfully, review the logs and verify the configuration file paths, Open Integration server details, Java configuration, certificate configuration, and MCP tool mappings.

Verify MCP Server Access

After the Siebel AI Connectors runtime starts successfully, verify that the configured MCP Servers are available.

The runtime exposes MCP Servers using the base MCP path and the MCP Server path configured in MCP_CONFIG.json.

The MCP Server endpoint uses the following format:

<scheme>://<host>:<port>/siebelAIConnectors/mcp/<mcp-server-path>

Where:

Value Description
<scheme> The protocol used to access the Siebel AI Connectors runtime, such as http or https.
<host> The host where the Siebel AI Connectors runtime is running.
<port> The runtime port configured in application.yaml.
/siebelAIConnectors/mcp The base path used by the Siebel AI Connectors runtime for MCP Servers.
<mcp-server-path> The MCP Server path configured in MCP_CONFIG.json.

For example, if application.yaml configures the runtime on port 8081, and MCP_CONFIG.json defines the following MCP Server path:

{
  "mcp-server-name": "Account MCP Server",
  "mcp-server-path": "/account",
  "mcp-server-description": "MCP Server for account-related Siebel operations.",
  "mcp-server-version": "1.0.0",
  "mcp-server-tools": [
    "get_account_details",
    "update_account_details"
  ]
}

Then the MCP Server endpoint is available at:

http://<host>:8081/siebelAIConnectors/mcp/account

If multiple MCP Servers are configured, each server is available at its own configured path.

Example:

MCP Server Name MCP Server Path MCP Server Endpoint
Account MCP Server /account http://<host>:8081/siebelAIConnectors/mcp/account
Product MCP Server /product http://<host>:8081/siebelAIConnectors/mcp/product
Service Request MCP Server /service-request http://<host>:8081/siebelAIConnectors/mcp/service-request

Use an MCP client, such as Postman, MCP Inspector or another supported MCP client, to connect to the required MCP Server endpoint and verify that the configured tools are available.

If the MCP Server endpoint is not available, verify the following:

  • The Siebel AI Connectors runtime started successfully.
  • The runtime startup logs show the MCP Server base URL.
  • The server.port value in application.yaml is correct.
  • The mcp-server-path value in MCP_CONFIG.json is correct.
  • Each mcp-server-path value is unique.
  • The MCP Server path in the client request matches the value configured in MCP_CONFIG.json.
  • Network access to the runtime host and port is available.
  • Authentication headers are included if JWT authentication is enabled.

Updating an Existing On-Premises Deployment

The runtime does not dynamically reload configuration changes.

  • If FINAL_SPECIFICATION.json is updated, review and update the tool mappings in MCP_CONFIG.json, and then restart the runtime.
  • If MCP_CONFIG.json is updated, restart the runtime.
  • If application.yaml or OI_CONFIG.json is updated, restart the runtime.

Deploying Siebel AI Connectors using Siebel Cloud Manager

This section describes the Siebel Cloud Manager payloads used to deploy Siebel AI Connectors in a Kubernetes-based environment.

Siebel AI Connectors expose selected Siebel Open Integration REST APIs as MCP-compatible tools. In an SCM deployment, the runtime configuration artifacts are maintained in a customer Git repository and deployed through Siebel Cloud Manager.

The deployment process includes the following high-level steps:

  1. Retrieve the Siebel AI Connectors configuration templates.

  2. Register the customer Git repository.

  3. Create the required infrastructure.

  4. Verify the infrastructure.

  5. Deploy Siebel AI Connectors.

  6. Check the deployment status.

  7. Delete the deployment, if required.

  8. Perform incremental updates after configuration changes.

1. Retrieve Configuration Templates

Use this API to retrieve the base configuration templates required for Siebel AI Connectors.

API
GET /scm/api/v1.0/siebelAIConnectors/templates HTTP/1.1
Host: https://<scm_host>:<scm_port>
Authorization: Basic <base64_admin_credentials>

The response contains a ZIP file with the following template artifacts:

Expected Template Artifacts: 
application.yaml, MCP_CONFIG.json, OI_CONFIG.json, FINAL_SPECIFICATION.json, logging.properties

These files are updated by the customer and committed to the Git repository used by the Siebel AI Connectors deployment.

2. Register Customer Git Repository

Use this API to register the Git repository that contains the Siebel AI Connectors configuration artifacts.

SCM validates access to the repository and returns a git_id. This git_id is used later in the Siebel AI Connectors deployment payload.

API
POST /scm/api/v1.0/git_repositories HTTP/1.1
Host: https://<scm_host>:<scm_port>
Authorization: Basic <base64_admin_credentials>
Content-Type: application/json
API
POST /scm/api/v1.0/git_repositories HTTP/1.1
Host: https://<scm_host>:<scm_port>
Authorization: Basic <base64_admin_credentials>
Content-Type: application/json
Sample HTTPS Git Payload with Self-Signed CA
{
  "git": {
    "git_protocol_type": "https",
    "git_url": "https://<git_host>/<group>/<repo>.git",
    "git_user": "<git_user>",
    "git_accesstoken": "<git_access_token>",
    "git_selfsigned_cacert": "/home/opc/<path_to_ca_certificate>"
  }
}
Sample SSH Git Payload
{
  "git": {
    "git_protocol_type": "ssh",
    "git_url": "git@<git_host>:<group>/<repo>.git",
    "git_ssh_private_key": "/home/opc/.ssh/<private_key_file>"
  }
}
Example Response
{
  "data": {
    "git_id": "<git_id>",
    "git_url": "https://<git_host>/<group>/<repo>.git",
    "git_protocol_type": "https"
  },
  "message": "Git repository registered successfully.",
  "status": "success"
}

3. Create Infrastructure

Use this API to create the infrastructure required for the Siebel AI Connectors deployment.

The payload contains the following top-level sections:

Section Description
operators Defines operator installation requirements.
kubernetes Defines the Kubernetes environment where the deployment will run.
git Defines the GitOps and Helm chart repositories used by SCM.
registry Defines the container registry used for images.
security_context Optional. Defines custom non-root user and group IDs. 
API
POST /scm/api/v1.0/infrastructure HTTP/1.1
Host: https://<scm_host>:<scm_port>
Authorization: Basic <base64_admin_credentials>
Content-Type: application/json
Sample Infrastructure Payload without Security Context
{
  "operators": [
    {
      "coherence_operator":< false | true >
    }
  ],
  "kubernetes": {
    "namespace": "<infra_namespace>",
    "kubernetes_type": "BYO_OCNE",
    "byo_ocne": {
      "kubeconfig_path": "/home/opc/siebel/<kubeconfig_file>.yaml"
    }
  },
  "git": {
    "git_type": "byo_git",
    "byo_git": {
      "git_protocol_type": "https",
      "git_accesstoken": "<git_access_token>",
      "git_user": "<git_user>",
      "git_scm_repo_url": "https://<git_host>/<group>/<siebel_ai_connectors_gitops_repo>",
      "git_scm_repo_branch": "main",
      "git_scm_flux_folder": "flux",
      "git_helm_repo_url": "https://<git_host>/<group>/<helm_chart_repo>",
      "git_helm_repo_branch": "main",
      "skip_flux_bootstrap": false
    }
  },
  "registry": {
    "registry_url": "<registry_host>",
    "registry_user": "<registry_user>",
    "registry_password": "<registry_password>",
    "registry_prefix": "<registry_prefix>"
  }
}

Use the following payload when infrastructure and operator setup must use custom non-root IDs:

Sample Infrastructure Payload with Security Context
{
  "security_context": {
    "run_as_user": <uid>,
    "run_as_group": <gid>,
    "fs_group": <fs_group_id>
  },
  "operators": [
    {
      "coherence_operator": < false | true >
    }
  ],
  "kubernetes": {
    "namespace": "<infra_namespace>",
    "kubernetes_type": "BYO_OCNE",
    "byo_ocne": {
      "kubeconfig_path": "/home/opc/siebel/<kubeconfig_file>.yaml"
    }
  },
  "git": {
    "git_type": "byo_git",
    "byo_git": {
      "git_protocol_type": "https",
      "git_accesstoken": "<git_access_token>",
      "git_user": "<git_user>",
      "git_scm_repo_url": "https://<git_host>/<group>/<siebel_ai_connectors_gitops_repo>",
      "git_scm_repo_branch": "main",
      "git_scm_flux_folder": "flux",
      "git_helm_repo_url": "https://<git_host>/<group>/<helm_chart_repo>",
      "git_helm_repo_branch": "main",
      "skip_flux_bootstrap": false
    }
  },
  "registry": {
    "registry_url": "<registry_host>",
    "registry_user": "<registry_user>",
    "registry_password": "<registry_password>",
    "registry_prefix": "<registry_prefix>"
  }
}

Sample Response

{
  "data": {
    "infra_details": {
      "components_info": {},
      "infra_id": "<infra_id>",
      "infra_status": "creation-in-progress",
      "payload": {
        "git": {
          "byo_git": {
            "git_accesstoken": "********",
            "git_helm_repo_branch": "main",
            "git_helm_repo_url": "https://<git_host>/<group>/<helm_chart_repo>",
            "git_protocol_type": "http",
            "git_scm_flux_folder": "flux",
            "git_scm_repo_branch": "main",
            "git_scm_repo_url": "https://<git_host>/<group>/<siebel_ai_connectors_gitops_repo>",
            "git_user": "<git_user>",
            "skip_flux_bootstrap": false
          },
          "git_type": "byo_git"
        },
        "kubernetes": {
          "byo_ocne": {
            "kubeconfig_path": "/home/opc/siebel/kubeconfig.yaml"
          },
          "kubernetes_type": "BYO_OCNE",
          "namespace": "<infra_namespace>"
        },
        "operators": [
          {
            "coherence_operator": true
          }
        ],
        "registry": {
          "registry_password": "************",
          "registry_prefix": "<registry_prefix>",
          "registry_url": "<registry_host>",
          "registry_user": "<registry_user>"
        }
      },
      "resource_status": {
        "git": "not-validated",
        "kubernetes": "not-validated",
        "operators": [
          {
            "coherence_operator": "not-validated"
          }
        ],
        "registry": "not-validated"
      },
      "self_link": "https://<scm_host>:<scm_port>/scm/api/v1.0/infrastructure/<infra_id>",
      "stages_info": [
        {
          "end_time": "",
          "log_api_link": "https://<scm_host>:<scm_port>/scm/api/v1.0/infrastructure/<infra_id>/logs/setup_validation_helmchart",
          "log_location": "",
          "name": "Setup Helm Chart for validation",
          "previous_status": "",
          "stage_name": "setup_validation_helmchart",
          "start_time": "<start_time>",
          "status": ""
        },
        {
          "end_time": "",
          "log_api_link": "https://<scm_host>:<scm_port>/scm/api/v1.0/infrastructure/<infra_id>/logs/check_job_status_helmchart",
          "log_location": "",
          "name": "Check Job status",
          "previous_status": "",
          "stage_name": "check_job_status_helmchart",
          "start_time": "<start_time>",
          "status": ""
        },
        {
          "end_time": "",
          "log_api_link": "https://<scm_host>:<scm_port>/scm/api/v1.0/infrastructure/<infra_id>/logs/install_operator_workflow",
          "log_location": "",
          "name": "Install operator workflow",
          "previous_status": "",
          "stage_name": "install_operator_workflow",
          "start_time": "<start_time>",
          "status": ""
        },
        {
          "end_time": "",
          "log_api_link": "https://<scm_host>:<scm_port>/scm/api/v1.0/infrastructure/<infra_id>/logs/verify_operator_workflow",
          "log_location": "",
          "name": "Verify Operator Installation",
          "previous_status": "",
          "stage_name": "verify_operator_workflow",
          "start_time": "<start_time>",
          "status": ""
        },
        {
          "end_time": "",
          "log_api_link": "https://<scm_host>:<scm_port>/scm/api/v1.0/infrastructure/<infra_id>/logs/collect_infra_artifacts",
          "log_location": "",
          "name": "Collect Infra artifacts",
          "previous_status": "",
          "stage_name": "collect_infra_artifacts",
          "start_time": "<start_time>",
          "status": ""
        }
      ]
    }
  },
  "message": "Infrastructure successfully created.",
  "status": "success"
}

After this response is returned, use the infra_id value from data.infra_details.infra_id in the subsequent infrastructure verification and Siebel AI Connectors deployment steps.

4. Verify Infrastructure

Use this API to verify that the infrastructure has been created successfully.

API
GET /scm/api/v1.0/infrastructure/<infra_id> HTTP/1.1
Host: https://<scm_host>:<scm_port>
Authorization: Basic <base64_admin_credentials>
Sample Response
{
  "data": {
    "infra_details": {
      "components_info": {
        "coherence_operator": true,
        "git": {
          "byo_git": {
            "git_accesstoken": "*************",
            "git_helm_repo_branch": "<helm_repo_branch>",
            "git_helm_repo_url": "https://<git_host>/<group>/<helm_chart_repo>",
            "git_protocol_type": "<http|https|ssh>",
            "git_scm_flux_folder": "<flux_folder>",
            "git_scm_repo_branch": "<gitops_repo_branch>",
            "git_scm_repo_url": "https://<git_host>/<group>/<gitops_repo>",
            "git_user": "<git_user>",
            "skip_flux_bootstrap": false
          },
          "git_type": "byo_git"
        },
        "kubernetes": {
          "byo_ocne": {
            "kubeconfig_path": "/home/opc/siebel/<kubeconfig_file>.yaml"
          },
          "k8s_profile": "/home/opc/siebel/infrastructures/<infra_id>/k8sprofile",
          "kubeconfig_path": "/home/opc/siebel/infrastructures/<infra_id>/kubeconfig.yaml",
          "kubernetes_type": "BYO_OCNE",
          "namespace": "<infra_namespace>"
        },
        "registry": {
          "registry_password": "************",
          "registry_prefix": "<registry_prefix>",
          "registry_url": "<registry_host>",
          "registry_user": "<registry_user>"
        }
      },
      "infra_id": "<infra_id>",
      "infra_status": "completed",
      "payload": {
        "git": {
          "byo_git": {
            "git_accesstoken": "**********",
            "git_helm_repo_branch": "<helm_repo_branch>",
            "git_helm_repo_url": "https://<git_host>/<group>/<helm_chart_repo>",
            "git_protocol_type": "<http|https|ssh>",
            "git_scm_flux_folder": "<flux_folder>",
            "git_scm_repo_branch": "<gitops_repo_branch>",
            "git_scm_repo_url": "https://<git_host>/<group>/<gitops_repo>",
            "git_user": "<git_user>",
            "skip_flux_bootstrap": false
          },
          "git_type": "byo_git"
        },
        "kubernetes": {
          "byo_ocne": {
            "kubeconfig_path": "/home/opc/siebel/<kubeconfig_file>.yaml"
          },
          "k8s_profile": "/home/opc/siebel/infrastructures/<infra_id>/k8sprofile",
          "kubeconfig_path": "/home/opc/siebel/infrastructures/<infra_id>/kubeconfig.yaml",
          "kubernetes_type": "BYO_OCNE",
          "namespace": "<infra_namespace>"
        },
        "operators": [
          {
            "coherence_operator": true
          }
        ],
        "registry": {
          "registry_password": "*********",
          "registry_prefix": "<registry_prefix>",
          "registry_url": "<registry_host>",
          "registry_user": "<registry_user>"
        }
      },
      "resource_status": {
        "git": "validated",
        "kubernetes": "validated",
        "operators": [
          {
            "coherence_operator": "validated"
          }
        ],
        "registry": "validated"
      },
      "self_link": "https://<scm_host>:<scm_port>/scm/api/v1.0/infrastructure/<infra_id>",
      "stages_info": [
        {
          "end_time": "<end_time>",
          "log_api_link": "https://<scm_host>:<scm_port>/scm/api/v1.0/infrastructure/<infra_id>/logs/setup_validation_helmchart",
          "log_location": "/home/opc/siebel/infrastructures/<infra_id>/logs/install_connection_chart.log",
          "name": "Setup Helm Chart for validation",
          "previous_status": "",
          "stage_name": "setup_validation_helmchart",
          "start_time": "<start_time>",
          "status": "passed"
        },
        {
          "end_time": "<end_time>",
          "log_api_link": "https://<scm_host>:<scm_port>/scm/api/v1.0/infrastructure/<infra_id>/logs/check_job_status_helmchart",
          "log_location": "/home/opc/siebel/infrastructures/<infra_id>/logs/validate_connection_chart.log",
          "name": "Check Job status",
          "previous_status": "",
          "stage_name": "check_job_status_helmchart",
          "start_time": "<start_time>",
          "status": "passed"
        },
        {
          "end_time": "<end_time>",
          "log_api_link": "https://<scm_host>:<scm_port>/scm/api/v1.0/infrastructure/<infra_id>/logs/install_operator_workflow",
          "log_location": "/home/opc/siebel/infrastructures/<infra_id>/logs/operators.log",
          "name": "Install operator workflow",
          "previous_status": "",
          "stage_name": "install_operator_workflow",
          "start_time": "<start_time>",
          "status": "passed"
        },
        {
          "end_time": "<end_time>",
          "log_api_link": "https://<scm_host>:<scm_port>/scm/api/v1.0/infrastructure/<infra_id>/logs/verify_operator_workflow",
          "log_location": "/home/opc/siebel/infrastructures/<infra_id>/logs/operators.log",
          "name": "Verify Operator Installation",
          "previous_status": "",
          "stage_name": "verify_operator_workflow",
          "start_time": "<start_time>",
          "status": "passed"
        },
        {
          "end_time": "<end_time>",
          "log_api_link": "https://<scm_host>:<scm_port>/scm/api/v1.0/infrastructure/<infra_id>/logs/collect_infra_artifacts",
          "log_location": "/home/opc/siebel/infrastructures/<infra_id>/logs/artifacts.log",
          "name": "Collect Infra artifacts",
          "previous_status": "",
          "stage_name": "collect_infra_artifacts",
          "start_time": "<start_time>",
          "status": "passed"
        }
      ]
    }
  },
  "message": "Infrastructure details retrieved successfully.",
  "status": "success"
}

After verification completes successfully, the infra_status value is completed, and the resource_status values for Git, Kubernetes, operators, and registry are marked as validated. Use the infra_id value in the Siebel AI Connectors deployment payload.

5. Deploy Siebel AI Connectors

Use this API to deploy Siebel AI Connectors using the prepared infrastructure and registered Git repository. The deployment payload references the Git repository that contains the runtime configuration files.

API
POST /scm/api/v1.0/siebelAIConnectors HTTP/1.1
Host: https://<scm_host>:<scm_port>
Authorization: Basic <base64_admin_credentials>
Content-Type: application/json
Deployment Payload
{
  "name": "<mcp_deployment_namespace>",
  "infra_id": "<infra_id>",
  "byo_ns": false,
  "security_context": {
    "run_as_user": <uid>,
    "run_as_group": <gid>,
    "fs_group": <fs_group_id>
  },
  "siebel_mcp": {
    "git": {
      "git_id": "<git_id>",
      "git_repo_branch": "main",
      "git_config_folder": "siebel-mcp"
    },
    "java_truststore": {
      "cacerts_path": "/home/opc/siebel/cacerts",
      "password": "<truststore_password>"
    }
  }
}

Optionally, If byo_ns is set to "true", ensure that the Siebel AI Connector namespace is created before executing this step. Then, specify the created namespace in the Siebel AI Connector deployment payload by setting the "name" field to the namespace value.

Example Response
{
  "data": {
    "ansible_chart_name": "ansible-<deployment_name>-<deploy_id_lowercase>",
    "app_dir": "/home/opc/siebel/microservices/siebel-ai-connectors/<deploy_id>",
    "byo_ns": false,
    "deploy_id": "<deploy_id>",
    "deploy_status": "creation-in-progress",
    "infra_id": "<infra_id>",
    "name": "<mcp_deployment_namespace>",
    "namespace": "<mcp_deployment_namespace>",
    "product_name": "siebel-ai-connectors",
    "security_context": {
      "fs_group": <fs_group_id>,
      "run_as_group": <gid>,
      "run_as_user": <uid>
    },
    "self_link": "https://<scm_host>:<scm_port>/scm/api/v1.0/siebelAIConnectors/<deploy_id>",
    "siebel_mcp": {
      "git": {
        "git_config_folder": "siebel-mcp",
        "git_id": "<git_id>",
        "git_json": {
          "branch": "main",
          "config_folder": "siebel-mcp",
          "protocol_type": "https",
          "url": "https://<git_host>/<group>/<repo>",
          "user": "<git_user>"
        },
        "git_protocol_type": "https",
        "git_repo_branch": "main",
        "git_selfsigned_cacert": "",
        "git_siebel_mcp_directory": "siebel-mcp",
        "git_ssh_private_key": "",
        "git_url": "https://<git_host>/<group>/<repo>",
        "git_user": "<git_user>"
      },
      "java_truststore": {
        "cacerts_path": "/home/opc/siebel/cacerts",
        "helm_values": {
          "checksum": "<truststore_checksum>",
          "enabled": true,
          "fileName": "cacerts",
          "mountPath": "/opt/mcp/truststore",
          "password": "",
          "passwordSecretKey": "storepass",
          "passwordSecretName": "",
          "secretKey": "cacerts",
          "secretName": ""
        },
        "password": "<masked_or_configured_truststore_password>"
      }
    },
    "stages": [
      {
        "name": "Pre Deploy",
        "stage_name": "pre_deploy",
        "stage_description": "Create pre requisites and other preparations",
        "status": ""
      },
      {
        "name": "Prepare GitOps",
        "stage_name": "prepare_gitops",
        "stage_description": "Generate Flux definitions, Prepare helmchart to git and Prepare GitOps",
        "status": ""
      },
      {
        "name": "Verify Deployment",
        "stage_name": "verify_deployment",
        "stage_description": "Verify HR Deployment",
        "status": ""
      },
      {
        "name": "Publish Urls",
        "stage_name": "publish_urls",
        "stage_description": "Publish Application Urls",
        "status": ""
      }
    ]
  },
  "message": "ansible playbook for siebel-ai-connectors ansible playbook for executed successfully",
  "status": "success"
}

6. Get Siebel AI Connectors Deployment Status

Use this API to retrieve the current status of a Siebel AI Connectors deployment.

API
GET /scm/api/v1.0/siebelAIConnectors/<deploy_id> HTTP/1.1
Host: https://<scm_host>:<scm_port>
Authorization: Basic <base64_admin_credentials>
Example Response
{
  "data": {
    "ansible_chart_name": "ansible-<deployment_name>-<deploy_id_lowercase>",
    "app_dir": "/home/opc/siebel/microservices/siebel-ai-connectors/<deploy_id>",
    "byo_ns": false,
    "deploy_id": "<deploy_id>",
    "deploy_status": "<creation-in-progress|completed|failed|Rerun-In-Progress>",
    "infra_id": "<infra_id>",
    "name": "<mcp_deployment_namespace>",
    "namespace": "<mcp_deployment_namespace>",
    "product_name": "siebel-ai-connectors",
    "security_context": {
      "fs_group": <fs_group_id>,
      "run_as_group": <gid>,
      "run_as_user": <uid>
    },
    "self_link": "https://<scm_host>:<scm_port>/scm/api/v1.0/siebelAIConnectors/<deploy_id>",
    "siebel_mcp": {
      "git": {
        "git_id": "<git_id>",
        "git_config_folder": "siebel-mcp",
        "git_repo_branch": "main",
        "git_protocol_type": "https",
        "git_url": "https://<git_host>/<group>/<repo>",
        "git_user": "<git_user>"
      },
      "java_truststore": {
        "cacerts_path": "/home/opc/siebel/cacerts",
        "password": "<masked_or_configured_truststore_password>"
      }
    },
    "stages": [
      {
        "name": "Pre Deploy",
        "stage_name": "pre_deploy",
        "status": "<passed|failed|in-progress>",
        "log_api_link": "https://<scm_host>:<scm_port>/scm/api/v1.0/siebelAIConnectors/<deploy_id>/logs/pre_deploy",
        "log_location": "/home/opc/siebel/microservices/siebel-ai-connectors/<deploy_id>/logs/pre_deploy.log"
      },
      {
        "name": "Prepare GitOps",
        "stage_name": "prepare_gitops",
        "status": "<passed|failed|in-progress>",
        "log_api_link": "https://<scm_host>:<scm_port>/scm/api/v1.0/siebelAIConnectors/<deploy_id>/logs/prepare_gitops",
        "log_location": "/home/opc/siebel/microservices/siebel-ai-connectors/<deploy_id>/logs/prepare_gitops.log"
      },
      {
        "name": "Verify Deployment",
        "stage_name": "verify_deployment",
        "status": "<passed|failed|in-progress>",
        "log_api_link": "https://<scm_host>:<scm_port>/scm/api/v1.0/siebelAIConnectors/<deploy_id>/logs/verify_deployment",
        "log_location": "/home/opc/siebel/microservices/siebel-ai-connectors/<deploy_id>/logs/verify_deployment.log"
      },
      {
        "name": "Publish Urls",
        "stage_name": "publish_urls",
        "status": "<passed|failed|in-progress>"
      }
    ]
  },
  "message": "success",
  "status": "success"
}

7. Delete Siebel AI Connectors Deployment

Use this API to delete an existing Siebel AI Connectors deployment.

API
DELETE /scm/api/v1.0/siebelAIConnectors/<deploy_id> HTTP/1.1 
Host: https://<scm_host>:<scm_port> 
Authorization: Basic <base64_admin_credentials>
Example Response
{
  "data": {
    "archive_dir": "/home/opc/siebel/microservices/siebel_mcp/archive/<deploy_id>",
    "deleted": true,
    "deploy_id": "<deploy_id>"
  },
  "message": "Deletion of deploy_id <deploy_id> of siebel_mcp successfull",
  "status": "success"
}

8. Perform Incremental Updates

Perform an incremental update after changes are made to the Siebel AI Connectors configuration files in the customer Git repository.

Configuration files may include either of the following files:

  • application.yaml
  • MCP_CONFIG.json
  • OI_CONFIG.json
  • FINAL_SPECIFICATION.json
  • logging.properties
Steps:

  1. Update the required configuration files in the customer Git repository.

  2. Commit and push the customer Git changes.

  3. Go to the infrastructure Helm chart repository.
    
cd /home/opc/siebel/infrastructures/<infra_id>/<helmchart_repo>/
git pull
  4. Change to the image builder chart directory for the deployment.
    cd <deploy_name>-<deploy_id>/siebel-mcp
  5. Edit Chart.yaml.
    vi Chart.yaml
  6. Increment the chart version.
    version: 0.1.2
  7. Commit and push the Helm chart change.
    git add Chart.yaml
git commit -m "<incremental_update_message>"
git push

Expected Result

After the Helm chart version is updated and pushed:

  1. Flux reconciliation detects the Helm chart version change.

  2. The MCP image builder job restarts.

  3. A new Siebel AI Connectors application image is built using the latest committed customer Git content.

  4. The updated MCP application starts with the new image.

Important Notes

  1. Do not commit credentials, access tokens, registry passwords, truststore passwords, private keys, or other secrets into Git.
  2. Ensure that all customer Git changes are committed and pushed before incrementing the Helm chart version.
  3. Increment only the chart version required to trigger the image builder update.

Placeholder Reference

Placeholder Description
<scm_host> Siebel Cloud Manager host name or IP address.
<scm_port> Siebel Cloud Manager port.
<infra_id> Infrastructure ID returned by the infrastructure creation API.
<deploy_id> Deployment ID returned by the Siebel AI Connectors deployment API.
<git_id> Git repository ID returned by the Git registration API.
<git_host> Git server host.
<group> Git group, project, or organization path.
<repo> Git repository name.
<git_user> Git user name.
<git_access_token> Git access token.
<infra_namespace> Kubernetes namespace used for infrastructure resources.
<mcp_deployment_namespace> Namespace or deployment name used for Siebel AI Connectors.
<registry_host> Container registry host.
<registry_user> Container registry user.
<registry_password> Container registry password or authentication token.
<registry_prefix> Registry namespace or prefix.
<uid> Runtime user ID.
<gid> Runtime group ID.
<fs_group_id> File system group ID.
<truststore_password> Java truststore password.
<kubeconfig_file> Kubernetes kubeconfig file available on the SCM host.

Validating Runtime Behavior

Runtime behavior includes startup, configuration loading, MCP Server creation, tool invocation, and validation.

Runtime Startup

When the runtime starts, it performs the following actions:

  1. Reads application.yaml.

  2. Resolves the configured paths for MCP_CONFIG.json, FINAL_SPECIFICATION.json, logging.properties, and OI_CONFIG.json.

  3. Loads logging configuration.

  4. Loads Open Integration server configuration from OI_CONFIG.json.

  5. Parses FINAL_SPECIFICATION.json.

  6. Builds MCP tool definitions from the selected Open Integration REST API operations.

  7. Loads MCP Server definitions from MCP_CONFIG.json.

  8. Maps tools to MCP Servers.

  9. Starts MCP Server endpoints.

Expected startup indicators include:


Successfully parsed OpenAPI spec file:<Path>/FINAL_SPECIFICATION.json
Loaded Open Integration servers: [<server-name-1>, <server-name-2>]; default server: <server-name>
Processing Tool : [<tool-name>] , Method : [<method>] , Path: [<path>]
Using Open Integration server [<server-name>] for tool [<tool-name>]
Adapted [<count>] tools from OpenAPI spec
MCP Servers started with base url: <host>:<port>/siebelAIConnectors/mcp

If a server URL in FINAL_SPECIFICATION.json differs from the server URL configured in OI_CONFIG.json, the runtime logs a warning and uses the configured Open Integration server URL.

Startup Validation

After startup, validate that the runtime loaded all required artifacts successfully.

Validation Check Expected Result
application.yaml is loaded. Runtime starts with configured host, port, security settings, and file paths.
logging.properties is loaded. Logs use the configured handler, format, and logging levels.
OI_CONFIG.json is loaded. Runtime logs the configured Open Integration servers and default server.
FINAL_SPECIFICATION.json is parsed. Runtime logs successful parsing of the tool specification file.
MCP tools are generated. Runtime logs the tools processed from the selected operations.
MCP_CONFIG.json is parsed. Runtime creates MCP Servers with configured endpoint paths.
MCP Server endpoints are started. Runtime logs the MCP base URL.

Tool Discovery and Invocation Validation

After startup validation, validate that MCP tools can be discovered and invoked.

Validation Check Expected Result
MCP client connects to the MCP Server endpoint. Connection succeeds.
Configured tools are available for discovery. Tools listed in MCP_CONFIG.json are visible through the MCP Server.
Sample MCP tool is invoked. Runtime identifies the tool and resolves the Open Integration server.
Open Integration REST API is invoked. Runtime sends the downstream request to the configured Open Integration server.
Response is returned to MCP client. MCP client receives the response from the tool invocation.

For secured deployments, also validate:

Validation Check Expected Result
Request without token is sent. Request is rejected.
Request with invalid token is sent. Request is rejected.
Request with valid token and required scope is sent. Request is accepted.
Token contains expected issuer, audience, and scope. JWT validation succeeds.
Open Integration authentication is aligned. Downstream Open Integration request succeeds.

Updating Existing Configurations

The runtime does not dynamically reload configuration artifacts. Restart the runtime after updating any of the following files:

  • FINAL_SPECIFICATION.json
  • MCP_CONFIG.json
  • application.yaml
  • OI_CONFIG.json
  • logging.properties

It is critical to note that if the FINAL_SPECIFICATION.json is updated, then you must also review and if needed update MCP_CONFIG.json if tools were added, removed or renamed.

Troubleshooting Validation Issues

Use the following checks when runtime startup or tool invocation fails.

Issue Check
Runtime does not start. Verify Java version, runtime classpath, mcp-runtime-<version>.jar, libs/, and application.yaml.
Configuration file not found. Verify mcp.server-config-file, mcp.final-spec-file, mcp.logging-properties-file, and mcp.open-int-config-file.
No tools are available. Verify x-tools, operation-level x-tool-name, and MCP_CONFIG.json tool mappings.
MCP Server endpoint is missing. Verify mcp-server-path in MCP_CONFIG.json.
Tool mapping fails. Verify every mcp-server-tools value exists in FINAL_SPECIFICATION.json.
Open Integration server is not resolved. Verify operation-level x-server-name, OI_CONFIG.json server names, and default-server.
Request body validation fails. Verify requestBody, components.schemas, required, and additionalProperties.
Parameter validation fails. Verify parameter in, name, required, and schema.
JWT validation fails. Verify issuer, audience, required-scope, jwks-uri, and token claims.
Open Integration invocation fails. Verify Open Integration host, port, context, authentication, certificate trust, and network connectivity.