Enabling the MCP Server on Self-Hosted Deployments

Last updated: November 5, 2026

Tier Deployment
Enterprise On-Prem

Availability: Self-hosted deployments · Sisense 2026.3.1 and later

On self-hosted deployments, the Sisense MCP Server runs on your own Sisense instance. It is disabled by default and is deployed only after an administrator enables it at install or upgrade. Once enabled, your instance serves the MCP endpoint, and users connect to it with the same OAuth 2.1 sign-in used on Managed Cloud.

Note:

This topic is for administrators of self-hosted deployments. On Managed Cloud, the MCP Server is hosted by Sisense and is on by default. To connect an AI client after the server is enabled, see Connecting an AI Agent.

What Enabling the MCP Server Deploys

Enabling the MCP Server adds the following to your deployment:

  • oauth-gateway - Handles the OAuth 2.1 sign-in and issues each user a short-lived, per-user credential.

  • mcp-service - The MCP backend that runs the tools on behalf of the signed-in user.

Your existing API gateway is configured to serve the endpoint on your current host at https://<your-deployment>/mcp. No separate ingress or DNS entry is required.

No encryption-key setup is required. The keys the OAuth gateway uses are generated and stored by Sisense automatically.

Prerequisites

  • Your deployment is on Sisense 2026.3.1 or later.

  • The DNS name of your deployment (application_dns_name, also known as the system alias) is set to the URL your users use to reach Sisense. See The DNS Name and the OAuth Sign-In below.

  • If multitenancy is enabled on your deployment, review Limitations before you begin.

Enabling the MCP Server

  1. Confirm that your deployment is on Sisense 2026.3.1 or later.

  2. Add the sisenseMcp setting under global: in the override values for the Sisense Helm chart. Where you add it depends on how you install Sisense:

    • sisense.sh installer (single node or cluster): Add it to installer/extra_values/helm/sisense.yml. See Using Override Values with Helm Chart Deployments.

    • Provisioner: Add it to your Sisense override values file, and pass the file to helm install or helm upgrade with --set-file sisense=<your-file>. See "Using the Extra-Values Feature to Override Extended Configuration" in Installing Sisense using Provisioner and Helm.

    • Helm: Add it to the values file that you pass to helm install or helm upgrade with -f.

    Copy
    global:
      sisenseMcp:
        enabled: true

    Important:

    In Sisense 2026.3.x, do not add this setting to your installer configuration file (config.yaml or cluster_config.yaml). The installer does not pass it to the Sisense Helm chart from that file, so the MCP Server is not deployed, even though the installation or upgrade completes without errors.

    Note:

    The sisenseMcp setting is not in these files by default, so you must add it yourself. If your file already has a global: section, add sisenseMcp inside it rather than creating a second global: section. Indentation matters: a top-level sisenseMcp: entry that is not nested under global: is ignored.

  3. Run the installer or upgrade to apply the change (sisense.sh, or helm install or helm upgrade for the Provisioner or Helm).

  4. Verify that the oauth-gateway and mcp-service pods are running:

    Copy
    kubectl -n sisense get pods | grep -E 'oauth-gateway|mcp-service'

    If Sisense is installed in a different namespace, replace sisense with your namespace.

  5. Under System Configuration > MCP, make sure the Enabled toggle is on.

  6. Give your users the endpoint https://<your-deployment>/mcp (for example, https://company.sisense.com/mcp). In Claude, users add this endpoint as a custom connector. The Sisense listing in Claude's connector directory connects to the Sisense-hosted endpoint, not to your instance. See Connecting an AI Agent.

  7. Optional: To use the AI-powered tools (buildQuery and the chart and dashboard tools), enable Cloud-Linked Features and set up an LLM provider, as described in the prerequisites of Sisense MCP Server. To display interactive charts and dashboards in Claude, add the CORS entry described in Interactive Charts and Dashboards in Claude. Without it, Claude users get text-only answers.

The DNS Name and the OAuth Sign-In

The OAuth gateway builds its issuer and sign-in redirect addresses from your deployment's DNS name (application_dns_name, also known as the system alias). Make sure this value is the URL your users actually use to reach Sisense. The MCP endpoint is that URL followed by /mcp.

If you change the DNS name during an upgrade, the OAuth gateway is restarted automatically so that it picks up the new name.

For more information about application_dns_name, see Installing Sisense on Linux.

Branding the Consent Page

Availability: Self-hosted deployments · Sisense 2026.4.1 and later

When a user connects an AI client, the OAuth sign-in includes a consent page where the user approves the client's access to Sisense. Because the OAuth gateway runs on your own instance, the consent page automatically uses your instance's branding instead of the default Sisense branding. Users see your organization's logo, name, and colors when they approve access, which helps them confirm that they are connecting to the right server.

No additional configuration is required. The consent page uses the branding that is already configured in Sisense:

  • Logo and name: Taken from Admin > App Configuration > White Labeling: the logo, and the page title set under General, which is displayed as your organization's name. These are applied only when white labeling is enabled. See White Labeling Sisense.

  • Colors: The button and text colors are taken from your Look and Feel theme (Admin > App Configuration > Look and Feel). These are applied even when white labeling is not enabled. See Customizing the Sisense User Interface.

If your branding cannot be fully applied, the consent page falls back to the Sisense defaults:

  • If white labeling is not enabled, the page shows the Sisense logo and name, with your Look and Feel colors.

  • If your logo cannot be loaded, the page shows the Sisense icon, with your name and colors.

  • If your branding cannot be retrieved, the page shows the default Sisense branding. Sign-in is not delayed.

Branding changes only the appearance of the consent page. The OAuth sign-in and approval flow are unchanged.

Note:

Branding applies only when users connect through your instance's own endpoint (https://<your-deployment>/mcp). The Sisense-hosted endpoint used on Managed Cloud (https://mcp.sisense.com/mcp) always shows the default Sisense branding.

To verify the branding:

  1. Make sure white labeling and your Look and Feel theme are configured in Sisense.

  2. In an AI client, add https://<your-deployment>/mcp as a connector. If the connector already exists, remove it and add it again so that the client signs in again.

  3. Sign in to Sisense, and confirm that the consent page shows your logo, name, and colors.

Deployment Notes

  • mcp-service is an internal service (Kubernetes ClusterIP) and is not exposed outside the cluster. All client traffic reaches it through the /mcp endpoint on your existing host.

  • mcp-service runs as a single replica by design. Do not enable autoscaling for it. See Horizontal Pod Autoscaling (HPA).

Limitations

  • Multitenancy: On self-hosted deployments with multitenancy enabled and more than one tenant, requests to /mcp return the Sisense "Page not Found" page instead of reaching the MCP Server, so AI clients cannot connect. There is no workaround. This is fixed in Sisense 2026.4.1. Single-tenant deployments are not affected.

Troubleshooting