5. Deployment and Configuration
The Hopex MCP Server is included in the Hopex bundle. Deployment follows the standard Hopex bundle deployment process; the MCP module is then started and configured from the HAS console.
As the MCP Server is delivered with the bundle, its deployed version always matches the installed Hopex bundle. No manual version selection is required for the MCP Server itself.
After the bundle is deployed, administration is performed from the HAS console. The MCP module can be started and stopped from the console. The same console provides the MCP Server settings, including the default GraphQL schema, mutation authorization, deferred authentication, API key mode, authentication mode, and technical parameters. The AI client is configured separately with the MCP endpoint URL, authentication settings, and optional headers.
1. Deploy the Hopex bundle.
2. Open the HAS console.
3. Start the MCP module.
4. Configure the default GraphQL schema.
5. Configure authentication and API key mode if required.
6. Enable mutations only when required.
7. Register the MCP endpoint in the AI client.
8. Run validation tests.
5.1. MCP module management in the HAS console
In the HAS console, the Hopex MCP module is managed through a start/stop action and a set of MCP Server settings. These settings include the default GraphQL schema, mutation authorization, deferred authentication, API key mode, authentication mode, and other technical parameters.
Screenshot of a configuration interface for a default GraphQL schema, showing several options that can be enabled using checkboxes, including GraphQL mutations, deferred authentication, and API key authentication. Each option includes a description explaining how it works and under which conditions it is enabled, with a “Submit” button at the bottom to confirm the selected settings.HAS console — MCP Server module settings.
5.1.1. Default GraphQL schema
The default GraphQL schema is configured in the Hopex MCP module settings from the HAS console. It is used when the AI client does not send an x-schema header.
The x-schema HTTP header allows the AI client to target a GraphQL schema different from the default schema for a given call. When the header is absent, the MCP Server uses the schema configured in the HAS console. Customer-specific metamodel extensions are addressed in section 5.2 Customized metamodel exposure.
5.1.2. Mutation authorization
The Allow mutation option is configured in the Hopex MCP module settings from the HAS console. It authorizes the execution of GraphQL mutations by the MCP Server.
Allow mutation is required to execute mutations, regardless of the authentication mode. In API key mode, the AI client must also send the x-allow-mutation header. The MCP Server uses both the HAS setting and the client header to authorize mutation execution.
5.1.3. Deferred authentication
Deferred authentication is configured in the Hopex MCP module settings from the HAS console. When enabled, the MCP Server can defer user authentication to a later stage of the connection flow, depending on the authentication mode and client behavior.
This option is used when the AI client first connects to discover the MCP Server capabilities and completes authentication only when an authenticated operation is required. The effective behavior depends on the selected authentication mode and the AI client implementation.
5.1.4. API key mode
API key mode is enabled in the Hopex MCP module settings.
The AI client sends the key in the x-api-key HTTP header. How this header is declared depends on the AI client: connector configuration, environment variable, managed secret, or dedicated configuration screen.
5.2. Customized metamodel exposure
When Hopex customizations are used, the GraphQL schema exposed through MCP must cover the customized metamodel elements that are relevant for AI usage. The customer may either extend an existing schema or create a dedicated schema for the AI scenarios to be supported.
The schema scope should be defined from the questions the organization expects users to ask, not from the full customized repository model. This limits data exposure, avoids unnecessary complexity, and helps the LLM build more accurate GraphQL queries.
For each exposed customization, metaclasses, meta-associations, and meta-attributes should be documented with clear labels and descriptions. These descriptions should explain the business meaning of the concept, when it should be used, and how it relates to standard Hopex concepts or to other customer-specific extensions.
These descriptions help the LLM select the relevant types, relationships, and attributes when translating a user question into a GraphQL query.
5.3. AI client configuration
The AI client declares the HTTPS URL of the MCP endpoint exposed by HAS, then configures the authentication mode, optional HTTP headers, and connector-specific options.
Common headers are x-api-key for machine-to-machine scenarios, x-schema to target a specific GraphQL schema, and x-allow-mutation for mutations in API key mode. Exact syntax varies by AI client and should be checked in the client documentation.
Headers are declared in the AI client or its connector, not by the LLM. The AI client sends them with MCP calls; the LLM uses the declared capabilities and available context.
The MCP Server interprets these headers on the Hopex side; the client-side declaration remains specific to the connector, configuration model, or administration interface.
Vendor-specific configuration examples are provided in section 14.5 AI client configuration examples.
5.4. Secret management
Secrets used by AI clients, such as API keys or OAuth secrets, are managed on the AI client side using the mechanisms provided by the vendor: secret vault, secure configuration, environment variable, or administration screen.
The Hopex documentation describes the headers and parameters interpreted by the MCP Server. Secret protection, rotation, and declaration are handled by the AI client and by the organization's security practices.
5.5. SaaS and on-premises deployment
In a SaaS environment, the MCP endpoint is reached through the published Hopex URL and the authentication framework available for the tenant. AI client access must be validated against the authorized connection mode and identity provider.
In an on-premises environment, endpoint exposure depends on the customer network design. The main deployment checks are HTTPS opening, certificate trust, firewall rules, reverse proxy or gateway configuration, and any DMZ constraints.
5.6. Network prerequisites
The AI client must be able to reach the MCP endpoint exposed by HAS over HTTPS. Communications follow the same framework as other Hopex services exposed by HAS.
Network configuration depends on the customer environment: DNS resolution, TLS certificate, outbound proxy, inbound reverse proxy, IP filtering, HTTPS inspection, and security rules for exposed services.