Enabling the MCP Server on Self-Hosted Deployments
Last updated: November 5, 2026
| Tier | Deployment |
|
|
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
-
Confirm that your deployment is on Sisense 2026.3.1 or later.
-
Add the
sisenseMcpsetting underglobal: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 installorhelm upgradewith--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 installorhelm upgradewith-f.
Copyglobal:
sisenseMcp:
enabled: trueImportant:
In Sisense 2026.3.x, do not add this setting to your installer configuration file (
config.yamlorcluster_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
sisenseMcpsetting is not in these files by default, so you must add it yourself. If your file already has aglobal:section, addsisenseMcpinside it rather than creating a secondglobal:section. Indentation matters: a top-levelsisenseMcp:entry that is not nested underglobal:is ignored. -
-
Run the installer or upgrade to apply the change (
sisense.sh, orhelm installorhelm upgradefor the Provisioner or Helm). -
Verify that the
oauth-gatewayandmcp-servicepods are running:Copykubectl -n sisense get pods | grep -E 'oauth-gateway|mcp-service'If Sisense is installed in a different namespace, replace
sisensewith your namespace. -
Under System Configuration > MCP, make sure the Enabled toggle is on.
-
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. -
Optional: To use the AI-powered tools (
buildQueryand 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:
-
Make sure white labeling and your Look and Feel theme are configured in Sisense.
-
In an AI client, add
https://<your-deployment>/mcpas a connector. If the connector already exists, remove it and add it again so that the client signs in again. -
Sign in to Sisense, and confirm that the consent page shows your logo, name, and colors.
Deployment Notes
-
mcp-serviceis an internal service (Kubernetes ClusterIP) and is not exposed outside the cluster. All client traffic reaches it through the/mcpendpoint on your existing host. -
mcp-serviceruns 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
/mcpreturn 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
Check the following:
-
The
sisenseMcpsetting is in the Sisense Helm override values (for example,installer/extra_values/helm/sisense.yml), not inconfig.yamlorcluster_config.yaml. It must be nested underglobal:, withenabled: true, and the installer or upgrade must be run afterward. See Enabling the MCP Server. -
The
oauth-gatewayandmcp-servicepods are running (see step 4 of Enabling the MCP Server). -
The Enabled toggle is on under System Configuration > MCP.
-
If multitenancy is enabled and the endpoint returns the Sisense "Page not Found" page, see Limitations.
Make sure your deployment's DNS name is set to the URL your users use to reach Sisense. See The DNS Name and the OAuth Sign-In.