The MCP server is available on Premium and Enterprise plans.
Users need the Viewer role or higher to interact with the MCP server. Which tools a user sees depends on their role — see Available actions.
Users need the Viewer role or higher to interact with the MCP server. Which tools a user sees depends on their role — see Available actions.
What is MCP?
Model Context Protocol (MCP) is an open standard that enables AI assistants to securely connect to external data sources and tools. The Cube MCP server acts as a bridge between your AI assistant and Cube’s analytics platform, allowing you to ask data questions directly from your coding environment.Overview
Cube hosts an MCP server endpoint. MCP clients connect over HTTPS and authenticate via OAuth.- Endpoint:
https://cubecloud.dev/mcp - OAuth flow: Authorization Code + PKCE,
client_id=cube-mcp-client, scope =mcp-agent-access. Clients discover it automatically from the endpoint — there is nothing to configure by hand. - Account selection: You sign in to Cube as part of the OAuth flow and, if you belong to more than one account, choose which one to connect.
- Deployment selection: On connect, the client lands on the tenant default deployment set by your admin (or the first deployment you can access). Clients can also target a specific deployment and agent per request — see Select a deployment and agent.
One endpoint for everyone
https://cubecloud.dev/mcp is the same URL for every account, deployment and region. Cube
identifies your account from the OAuth token and routes each request to whichever
deployment serves it, so there is no per-tenant host to look up before you can connect.
If Cube runs in your own cloud account or on your own domain, use that console domain
instead —
https://<your-console-domain>/mcp.Admin setup
Prerequisites
Before enabling MCP, make sure you have:- Admin privileges in your Cube instance
- An active Cube tenant
1) Check the MCP page
Go to Admin → MCP Server. The page shows the endpoint to hand to clients along with ready-made setup snippets for each supported client. If it reads “MCP configuration is unavailable,” the MCP server host isn’t configured for the account yet.2) Configure deployment access
Go to Admin → MCP Server and use the Deployment Access section to control which deployments MCP clients can reach and where they connect by default:- Default deployment — the deployment MCP clients connect to unless they explicitly request another one. Choose Automatic (first available) to land each user on the first deployment they can access.
- Limit available deployments — when off (the default), MCP clients can access all deployments the user is permitted to see. Turn it on to restrict MCP to a chosen subset.
- Available deployments — when the limit is on, pick the deployments MCP clients may access. Selecting none disables MCP access for the account.
Deployment access is always intersected with the user’s
role-based permissions — clients can only reach deployments the
authenticated user is allowed to see.

Connect to Claude
Claude Code
Authentication and usage flow:
- Run the command copied from Admin → MCP Server → AI Clients → Claude Code.
- Then run Claude and use
/mcpto list available servers. - Select
cube-mcp-serverand chooseAuthenticate. - A browser window opens for authentication.
- Log into Cube and choose your tenant.
- Return to Claude Code and start asking questions.
Claude (Team/Enterprise)
- Open Settings in Claude (web or desktop).
- Scroll to Integrations and click Add more.
- Use:
- Integration name: Cube MCP
- Integration URL:
https://cubecloud.dev/mcp
- Complete the OAuth flow to grant access.
- Enable tools in any new chats.
Use Cube in Claude chat
- Start a new chat in Claude.
- Open the tools menu and enable Cube MCP (use the tools search if you have many tools).
- Ask a data question. Toggle the tool off to disable it for that chat.
Claude (Desktop app)
Connect to Cursor
Add the MCP endpoint under Tools & MCP Settings, then complete the OAuth flow.Connect to Codex
Preferred (CLI):~/.codex/config.toml:
codex mcp login cube-mcp-server to authenticate.
Connect to other MCP clients
For any MCP-compatible client:- Add a new server with the MCP endpoint.
- The client will auto-discover OAuth and prompt for authentication.
- Complete the OAuth flow to grant access to your Cube deployment.
Select a deployment and agent
An MCP client is not locked to a single deployment for the whole session. After connecting, it can discover the deployments and agents you can access and target a specific one on each request. Three tools work together:listDeployments— discovery. Returns every deployment you can access via MCP (already filtered by the admin’s deployment-access settings and your permissions) and each deployment’s agents. Use it to find validdeploymentIdandagentIdvalues before callingchat. Every deployment offers an Auto agent (agentId: null) in addition to any configured agents.chat— accepts two optional selection parameters:deploymentId— the deployment to use for this request. When omitted, the chat uses the deployment from the current session (the default resolved at connect time).agentId— the agent to use for this request. When omitted ornull, the deployment’s Auto agent is used. Pass a specificagentIdto route to a configured agent.
loadQueryResults— paginates through the results of a previous query on the same deployment context.
1
Connect
Complete the OAuth flow. The session is scoped to the tenant default deployment (or
the first one you can access).
2
Discover
Call
listDeployments to see the available deploymentId / agentId values.3
Chat
Call
chat with your input, optionally passing deploymentId and/or agentId to
target a specific deployment or agent. Omit both to use the session default deployment
with its Auto agent.Deployment <id> is not available via MCP for this account), so
neither listDeployments nor the chat selection can reach an excluded deployment.
Available actions
The MCP server exposes 20 tools, grouped below. Every tool runs as the authenticated user. Queries respect the same permissions as the rest of Cube, including row-level security — MCP is a new way to reach your data, not a new access surface.Read and write tools
Each tool is annotated as read-only or destructive. MCP clients that honor these annotations — including Claude — run read-only tools automatically and always ask for confirmation before any of the four destructive ones:updateDashboard,
publishDashboard, writeDataModelFile, and deleteDataModelFile. Nothing that changes
a dashboard or your data model happens without an explicit approval.
Deployments and chat
See Select a deployment and agent for how these three
work together.
Query and discovery
Call
searchDataModel before runQuery to find exact view and member names rather than
guessing them.
Dashboard authoring
These tools build workbooks and dashboards programmatically. Creating and editing workbooks requires the Explorer role or higher.
Drafts are the safety net here:
updateDashboard only ever writes to the draft, so a
published dashboard keeps serving its previous version until you approve
publishDashboard. See Build a dashboard for the full sequence.
Data model editing
These tools read and edit the semantic model source files. They are registered only for users whose role grants permission to edit the semantic model — Admin and Developer by default. Users without it never see them.getDataModelChanges answers “what have I changed?” for your own dev branch against its
immediate parent. getBranchDiff answers “what did this branch change?” for any branch,
including feature branches — reach for it when a change edits existing cubes, where the
file list looks identical on both branches and listDataModelFiles reveals nothing.
getDeploymentEnv never returns secret values. Anything that looks like a credential is
replaced with [ENCRYPTED] before it leaves Cube, so an AI client can verify that a
variable is set without ever seeing what it is set to.How model edits stay safe
Letting an AI client edit your semantic model is safe because of four constraints built into the MCP server:- Edits never touch production. Every write goes to a personal dev branch named
dev-<user>-<hash>. The write tools reject any branch that isn’t a dev branch, so the deploy branch is never writable over MCP. startDataModelEditis the only entry point. It returns the devbranchName, andwriteDataModelFileanddeleteDataModelFilerequire it. There is no way to write without going through it first.- Promotion is manual and human. To publish model changes you commit the dev branch from the Cube UI, as described in Development mode. The MCP server deliberately exposes no commit tool — an AI client can prepare changes, but only a person can ship them.
- Registration is permission-gated. Every tool in the two sections above — the six
model-editing tools,
getBranchDiff,getDeploymentEnv, and both pre-aggregation tools — is offered only to users whose role allows editing the semantic model. A Viewer never sees them at all.
getDataModelChanges before you commit.
Pre-aggregations
These tools inspect and trigger pre-aggregation builds. They are registered under the same semantic-model permission as the data model tools above.
Together these close the loop on pre-aggregation work: a query alone cannot prove a rollup
was used, and external pre-aggregations fail in configuration-specific ways — a missing
export bucket, denied bucket permissions — that only an actual build surfaces. Call
buildPreAggregation, then poll getPreAggregationStatus to see whether the partitions
built or to read the failure.
buildPreAggregation runs real queries against your data warehouse and, for external
pre-aggregations, writes through the export bucket. It consumes warehouse resources, so
expect a cost per build.Example workflows
Ask a data question
Ask a question in natural language and let the agent do the planning:chat returns the
answer along with the SQL it generated, and loadQueryResults pages through large result
sets. Use this for summaries, trends, and ad-hoc analysis.
To drive the query yourself instead, call searchDataModel to find the right view and
members, then run your own SQL with runQuery.
Build a dashboard
The five dashboard tools are designed to be used in order.1
Create the workbook
Call
createWorkbook with a name. It returns the workbookId every later step needs.
If you were given an existing workbook to build into, call readWorkbook instead and
skip to the next step.2
Create a report per chart
Call
createReport once per chart, KPI tile, or table, passing the workbookId and
the SQL query that powers it. Each call returns a reportId.3
Lay out the dashboard
Call
updateDashboard with the complete widget set, referencing each reportId from
the previous step. This replaces the draft layout and saves to the workbook draft —
the live dashboard is unchanged. Your client will ask you to confirm.4
Publish
Review the draft, then call
publishDashboard to make it live. This also prompts for
confirmation. It returns the dashboard URL.readWorkbook first and edit on top of the current
draft rather than overwriting it.
Edit the data model
CallstartDataModelEdit to enter development mode and get a dev branchName. Explore
the current source with listDataModelFiles and readDataModelFile, then apply changes
with writeDataModelFile or deleteDataModelFile, passing that branchName. Each write
recompiles the model and reports validation errors, so you can iterate until it compiles.
Review the result with getDataModelChanges, then commit the branch from the Cube UI to
publish it.
To review a branch you didn’t author — a colleague’s feature branch, say — call
getBranchDiff with its name instead. It compares against the deploy branch and returns
the full changed-file list even when the patch itself is trimmed.
Verify a pre-aggregation
After adding or changing a pre-aggregation, callgetPreAggregationStatus to see whether
its partitions exist and when they were last built. If nothing has been built yet — or you
want to confirm an external pre-aggregation’s export bucket actually works — call
buildPreAggregation, then poll getPreAggregationStatus again. A failed build reports
the exact error, which is usually a configuration problem rather than a modeling one;
getDeploymentEnv will tell you whether the expected variables (CUBEJS_DB_EXPORT_BUCKET
and friends) are set.
Troubleshooting
- MCP configuration is unavailable: Configure the MCP server URL.
- MCP OAuth integration is not configured: Enable MCP in Admin → Team & Security → OAuth Integrations.
- No deployments available / MCP access is disabled: In Admin → MCP Server → Deployment Access, make sure Limit available deployments is off, or that at least one deployment is selected and the user has permission to access it.
Deployment <id> is not available via MCP for this account(403): The requested deployment is excluded by the deployment-access allow-list or by the user’s permissions. CalllistDeploymentsto see which deployments are reachable, or adjust the allow-list in Admin → MCP Server → Deployment Access.