SSAS MCP Server: Let AI Agents Query Your Analysis Services Cubes

If you work with SSAS, you know the drill. The data is there, the cubes are well-modeled, but actually getting answers out of them requires someone who knows DAX or MDX. For most organizations that means a small group of people becomes the bottleneck for every ad-hoc question.

We got tired of that pattern, so we built an MCP server that gives AI agents direct access to SSAS. It connects through ADOMD.NET, supports both DAX and MDX, and works with any MCP client (Claude Desktop, GitHub Copilot, Cursor, Claude Code, whatever you prefer).

It's open source, MIT licensed, and you can install it with pip.

Repo: NexusAI-Solutions/ssas-mcp-server

What it does

Six tools, all read-only:

Tool	What it does
execute_query	Run DAX or MDX queries
list_catalogs	List databases on the instance
list_tables	Tables, dimensions, measure groups
list_columns	Columns for a specific table
list_measures	All measures with their DAX expressions
describe_model	Model overview with tables, measures, metadata

The AI agent uses these tools to figure out the model structure, write the appropriate query, run it, and return the results. You ask a question in plain English, it handles the rest.

Setup

pip install ssas-mcp-server

Environment variables:

set SSAS_SERVER=YOUR_SERVER\INSTANCE
set SSAS_DATABASE=Your Cube Name

Claude Desktop

claude_desktop_config.json:

{
  "mcpServers": {
    "ssas": {
      "command": "python",
      "args": ["-m", "ssas_mcp_server"],
      "env": {
        "SSAS_SERVER": "YOUR_SERVER\\INSTANCE",
        "SSAS_DATABASE": "Your Cube Name"
      }
    }
  }
}

VS Code / GitHub Copilot

.vscode/mcp.json:

{
  "servers": {
    "ssas": {
      "command": "python",
      "args": ["-m", "ssas_mcp_server"],
      "env": {
        "SSAS_SERVER": "YOUR_SERVER\\INSTANCE",
        "SSAS_DATABASE": "Your Cube Name"
      }
    }
  }
}

Claude Code

claude mcp add ssas -- python -m ssas_mcp_server

Why not just use CData or the Power BI MCP Server?

Fair question. Here's the short version:

	SSAS MCP Server	CData SSAS MCP	Power BI MCP Server
Data source	SSAS (Tabular + Multidimensional)	SSAS (via JDBC)	Power BI semantic models only
Queries	Native DAX + MDX	SQL (translated)	DAX (via Copilot)
License	MIT (free)	Commercial (paid)	Free
Runtime	Python	Java	Cloud / VS Code
Setup	pip install	JDBC driver + config	Microsoft ecosystem

CData requires a paid license and runs on Java. It translates queries to SQL instead of using native DAX/MDX, which limits what you can do analytically.

Microsoft's Power BI MCP Server only works with Power BI semantic models. If your cubes run on standalone SSAS or Azure Analysis Services, it doesn't apply.

This server fills the gap: lightweight, open source, direct SSAS connection, native query languages.

Security

Read-only by design. No network endpoint exposed (runs via stdio). Authentication goes through your existing SSAS instance security, so whatever permissions the Windows user has, the AI agent inherits. Nothing more.

Where it's useful

The most common scenario we see: someone in a meeting needs a number that doesn't exist in any pre-built report. Normally that becomes a request that takes a day or two. With this, the analyst opens Claude and asks the question directly. Answer comes back in seconds, and you can see the actual DAX query it ran if you want to verify.

Also useful for onboarding. New people on the team can ask "describe the data model" and get a structured overview instead of digging through documentation that's probably outdated anyway.

Limitations

Windows only, because ADOMD.NET requires .NET Framework. We're looking into cross-platform options but nothing concrete yet.

Links

• GitHub: NexusAI-Solutions/ssas-mcp-server
• PyPI: ssas-mcp-server
• Full writeup: nexus-ai.nl

If you run into issues or have feature requests, open an issue on GitHub. And if you need help integrating MCP servers into your BI stack, we do that too.

Comments

[Mads Hansen]

Interesting direction. OLAP cubes are exactly the kind of data source where an MCP layer needs more than a raw query bridge.

The useful guardrails I’d expect around this kind of server:

• expose measures and dimensions as discoverable context
• keep row-level/security roles enforced by the source system
• make generated MDX/DAX inspectable before execution
• put hard limits on expensive queries
• log the natural-language request and final query together
• return metadata with the answer, not just values

The main risk is that an agent can make a result look simple while hiding a very expensive or semantically wrong query underneath.

For analytics data, explainability is part of correctness. The user needs to know not only the answer, but which cube, measure, filters, and time grain produced it.

[Nexus AI]

Good points. Let me go through them.

Discoverable context: already there. list_measures gives you all visible measures with their DAX expressions, list_tables and list_columns expose the dimensional structure, and describe_model gives the agent a full overview before it writes anything. That's what makes the difference between the agent guessing and actually generating correct DAX.

Security roles: fully handled by the source system. The server connects as the Windows user running the process, so RLS and cube permissions carry over as-is. No extra auth layer needed.

Query inspectability: the MCP client (Claude, Copilot, etc.) shows the generated DAX/MDX alongside the result, so you can see what ran. No built-in approval gate at the server level though. A confirm-before-execute mode for production setups is interesting, might add that.

Query cost limits: not there yet. Fair point. SSAS doesn't expose query cost estimates like some SQL engines do, so the options are more limited (timeouts, result set caps), but it's doable.

Audit logging: not in the current version. Pairing the natural language request with the generated query and result metadata makes a lot of sense, especially in compliance-heavy environments.

Metadata with results: partially there. The tools return structured data, but adding cube name, applied filters, time grain, and measure definitions to every response would help. That's exactly how you prevent the "looks right, is wrong" problem.

For context: the open source version is meant as a clean starting point. When we deploy this for clients we add things like audit logging, query guardrails, and richer metadata as part of the production setup. Some of that will land in the open source version over time, but the idea is to keep it lean and easy to extend.

Curious which of these you'd prioritize for the open source version.