Cube

Premium or Enterprise. Cube states the MCP server is available on those plans only, and that users need the Viewer role or higher to interact with it. Which tools a user actually sees depends on their role, so two people on the same deployment can be offered different capabilities from the same endpoint.

No, by construction. Cube documents that every model write goes to a personal dev branch named dev-user-hash, and that the write tools reject any branch that is not a dev branch, so the deploy branch is never writable over MCP. Promotion to production requires a person committing the branch in the Cube UI.

It exposes no commit tool at all. Cube states this is deliberate: an AI client can prepare changes on a dev branch, but only a person can ship them, by committing from the Cube UI. Combined with dev-branch-only writes, that keeps the promotion step human without relying on a client approval prompt.

No. Cube documents cubecloud.dev/mcp as the same URL for every account, deployment and region, identifying your account from the OAuth token and routing each request to whichever deployment serves it. Region-specific endpoints also exist under Admin then MCP Server, but the single URL is the documented default.

Only that the model compiles. Cube is explicit that it does not mean the edit is correct, and recommends passing the dev branchName to runQuery to check the edit returns the right data. Verification happens on the branch before a merge rather than after, which is the point of the dev-branch workflow.

No. Cube documents that tool registration is permission-gated: the six model-editing tools, getBranchDiff, getDeploymentEnv and both pre-aggregation tools are offered only to users whose role allows editing the semantic model. A Viewer never sees them at all, so the restriction is on tool visibility rather than on call failure.