How do I use SSAS MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SSAS MCP Server list measures in the Sales cube" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

SSAS MCP Server

by dbdave

Overview Schema Related Servers Score Discussions

Python

Remote

SSAS MCP Server

A read-only Model Context Protocol server for querying SQL Server Analysis Services — both multidimensional cubes (MDX) and tabular models (DAX) — with Windows Integrated Security (Kerberos/NTLM, no passwords).

Companion to mssql_mcp_server, but for the OLAP side of the house.

Features

list_metadata — discover a cube/model's measures, dimensions and hierarchies (via MDSCHEMA_* DMVs, which work for both model types), so the agent never guesses bracketed unique names. The overview stays compact — measures, dimension names and multi-level user hierarchies; pass dimension="[Dim Event]" to drill into one dimension's full attribute hierarchies and levels (a whole cube's attribute list can run to tens of thousands of tokens).
execute_query — run an MDX (SELECT/WITH) or DAX (EVALUATE/DEFINE) query and get a flattened JSON table back.
execute_dmv — guarded passthrough for SELECT ... FROM $SYSTEM.* schema rowsets (MDSCHEMA_*, TMSCHEMA_*, DISCOVER_*) for deeper introspection.
Read-only by construction — statements that don't start with SELECT/WITH/EVALUATE/DEFINE are rejected, XMLA payloads are rejected, and there is no DDL/process surface at all.
Row cap + query timeout on every call so a runaway crossjoin can't flood the context window.

Requirements

Windows-only by construction (the server drives ADOMD.NET via pythonnet):

Windows, domain-joined, with network access to the SSAS instance (default instance = TCP 2383).
The Windows account running the server has Read access to the SSAS database (role membership). Integrated auth means "whoever runs the process".
ADOMD.NET client libraries — ships with SSMS, or install the Analysis Services client libraries redistributable. Typically lands in C:\Program Files\Microsoft.NET\ADOMD.NET\160.
Python 3.11+

Installation

git clone https://github.com/dbdave/mssas_mcp_server
cd mssas_mcp_server
pip install -e .

Smoke-test connectivity before wiring up MCP (if this fails it's network/auth/ADOMD install, not the server):

python test_connection.py <server> <catalog>

Configuration

Variable	Required	Default	Notes
`SSAS_SERVER`	yes	—	Host, `host\instance`, or an `http(s)://.../msmdpump.dll` URL
`SSAS_CATALOG`	yes	—	SSAS database name
`SSAS_DEFAULT_CUBE`	no	—	Cube/model `list_metadata` uses when none is given
`SSAS_ROW_LIMIT`	no	`10000`	Hard cap on returned rows
`SSAS_QUERY_TIMEOUT`	no	`60`	Per-query timeout, seconds
`SSAS_ADOMD_DLL_DIR`	no	auto-detected	Folder containing `Microsoft.AnalysisServices.AdomdClient.dll`

Authentication is always Windows Integrated Security (Integrated Security=SSPI) — no credentials in config.

MCP registration (Claude Code / Claude Desktop)

{
  "mcpServers": {
    "ssas-cube": {
      "command": "python",
      "args": ["-m", "ssas_mcp.server"],
      "env": {
        "SSAS_SERVER": "my-ssas-host",
        "SSAS_CATALOG": "My_Cube_Db",
        "SSAS_DEFAULT_CUBE": "Sales"
      }
    }
  }
}

One registered server targets one SSAS database. To use both a multidimensional and a tabular instance, register the server twice with different SSAS_SERVER/SSAS_CATALOG env blocks — the query language is chosen per call (execute_query accepts MDX or DAX, and the engine itself only accepts the language matching the model type).

Example usage

Multidimensional (MDX):

SELECT NON EMPTY { [Measures].[Tickets Issued] } ON COLUMNS,
       NON EMPTY { [Sales Item Fact Ordered Date].[Calendar].[Year Name].MEMBERS } ON ROWS
FROM [Sales]

Tabular (DAX):

EVALUATE SUMMARIZECOLUMNS('Date'[Year], "Total Sales", [Total Sales])

DMV introspection:

SELECT [MEASURE_NAME], [MEASUREGROUP_NAME] FROM $SYSTEM.MDSCHEMA_MEASURES WHERE [CUBE_NAME] = 'Sales'
SELECT * FROM $SYSTEM.TMSCHEMA_MEASURES  -- tabular models

Result format

Tools return JSON:

{
  "columns": ["[Sales Item Fact Ordered Date].[Calendar].[Year Name].[MEMBER_CAPTION]", "[Measures].[Tickets Issued]"],
  "rows": [["2025", 123456], ["2026", 98765]],
  "row_count": 2,
  "truncated": false
}

Cells can be null and columns can be mixed-type — MDX cellsets are flattened defensively (nulls preserved, Decimal → float, DateTime → ISO string).

Tests

pip install pytest
pytest tests/

License

MIT

Available Tools

3 tools

execute_dmvA

Execute a Dynamic Management View query for deeper metadata introspection.

Only SELECT ... FROM $SYSTEM.<rowset> is accepted. Useful rowsets: MDSCHEMA_* (cubes, measures, dimensions, hierarchies, levels, members) for multidimensional; TMSCHEMA_* (tables, columns, measures, relationships) and DISCOVER_CALC_DEPENDENCY for tabular models; DISCOVER_* for server state. Note DMV SQL is limited: no JOIN, no GROUP BY, WHERE supports only simple = comparisons combined with AND/OR.

Args: query: The DMV SELECT query. max_rows: Optional per-call row cap (0 = use the server default).

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`max_rows`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses query constraints (no JOIN, GROUP BY, simple WHERE), supported rowsets, and the optional max_rows cap. It does not mention side effects or permissions, but for a read-only introspection tool this is acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: purpose, accepted format, rowsets, limitations, and parameter definitions. It is comprehensive without being overly verbose, though it could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists (so return values are documented), the description covers all necessary aspects: input parameters, usage guidelines, behavioral constraints, and relevant rowsets. It is fully sufficient for an agent to decide when and how to invoke this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It clearly documents both parameters: 'query' as the DMV SELECT query and 'max_rows' as an optional row cap with default 0. This adds essential meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states it executes DMV queries for metadata introspection. It distinguishes from sibling tools like execute_query and list_metadata by specifying the DMV SQL format and target system rowsets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description details the accepted query format (SELECT ... FROM $SYSTEM.<rowset>), lists useful rowsets for different models, and notes SQL limitations. It provides clear context for when to use this tool but does not explicitly exclude alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

execute_queryA

Execute a read-only MDX or DAX query against the SSAS database.

Use MDX (SELECT ... FROM [Cube]) for multidimensional cubes and DAX (EVALUATE ...) for tabular models. Results are returned as a JSON table {columns, rows, row_count, truncated}. Rows are capped (default 10000, or SSAS_ROW_LIMIT) and 'truncated' is true when the cap was hit. Only SELECT/WITH (MDX) and EVALUATE/DEFINE (DAX) statements are accepted - anything else is rejected.

Args: query: The MDX or DAX query text. max_rows: Optional per-call row cap (0 = use the server default).

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`max_rows`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses read-only nature, statement acceptance criteria, return format (JSON table with columns/rows/row_count/truncated), row cap defaults (10000 or SSAS_ROW_LIMIT), and truncation flag. With no annotations, the description fully covers behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise, front-loaded with the primary action, uses bullet points and structured Args section. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (context indicates yes), the description still adequately covers return format and row limiting. It also addresses accepted query types, making the tool fully understandable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema coverage, the description fully explains both parameters: query is the MDX/DAX text, max_rows is an optional row cap (0 = server default). This adds complete semantic meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool executes read-only MDX or DAX queries against an SSAS database, with specific syntax for each. It differentiates from sibling tools (execute_dmv, list_metadata) by specifying the query types and database context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly guides when to use MDX vs DAX and lists accepted statement types (SELECT/WITH for MDX; EVALUATE/DEFINE for DAX). Implicitly excludes DMV queries and metadata calls, providing clear context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_metadataA

List the queryable metadata of an SSAS cube or tabular model.

Returns the exact bracketed unique names to use in MDX/DAX - call this before writing queries so names aren't guessed. Without a dimension, the overview lists measures (with measure group and display folder), dimension names, and multi-level user hierarchies. Pass a dimension to drill into that dimension's full set of attribute hierarchies and levels.

Args: cube_name: Cube (multidimensional) or model (tabular, usually 'Model') to describe. If omitted, uses the SSAS_DEFAULT_CUBE environment variable; if that is unset too, returns the list of available cubes/models so one can be chosen. dimension: Optional dimension unique name (e.g. '[Dim Event]') to list every hierarchy and level in that dimension.

ParametersJSON Schema

Name	Required	Description	Default
`cube_name`	No
`dimension`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, so description must disclose all behavior. It explains output content (measures, dimensions, hierarchies) and fallback for cube_name. No hidden side effects noted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with Args section, but somewhat lengthy. Could be more concise, though every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given output schema exists, return values are covered. Input behavior thoroughly explained. Lacks only minor details like error cases or permission requirements.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage 0%, but description fully explains both parameters: cube_name default behavior and dimension usage with example bracketed name. Adds significant value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Describes specific action: listing queryable metadata of SSAS cube/tabular model for obtaining bracketed unique names. Distinguishes from sibling tools (execute_dmv, execute_query) as a preparatory step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states to call before writing queries to avoid guessing names. Explains when to use dimension parameter. Does not mention when not to use but context is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0

Disambiguation5/5

Each tool serves a distinct purpose: execute_dmv for DMV system queries, execute_query for MDX/DAX against the cube/model, and list_metadata for exploring metadata structure. No functional overlap.

Naming Consistency5/5

All tools follow a consistent verb_noun snake_case pattern: execute_dmv, execute_query, list_metadata. The naming is predictable and unambiguous.

Tool Count5/5

Three tools cover the essential read-only query and metadata exploration workflow for SSAS, with no extraneous or missing operations. The count is well-scoped for the domain.

Completeness5/5

The tool set provides complete coverage for the stated purpose: listing metadata to discover names, executing queries via MDX/DAX or DMV, and handling cube/model selection. No obvious gaps.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

The Quiet Protocol Growth Offense MCP A
com.thequietprotocol.www
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Databases Research & Data Finance
292
LemonadoOAuth
io.github.lemonadolabs
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
Marketing Research & Data Databases
3
classquill-mcp
io.github.EquateItAu
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
Education & Learning Tools CRM
2
RevoGrid DataGrid MCP B
io.github.revolist
Token-free MCP server for structured RevoGrid Core, Pro, and Enterprise knowledge retrieval.
Documentation Access Developer Tools
423,392

Related MCP Servers

Snowflake Cube Server
Databases Data Platforms
isaacwasserman
A
license
Not graded
quality
C
maintenance
MCP Server for interacting with Cube semantic layers that provides tools for querying and describing data from Cube deployments.
Updated 2 years ago (2025-01-30 23:51 UTC)
15
GPL 3.0
SQL Server Analysis Servicesofficial
Databases Search
CDataSoftware
A
license
Not graded
quality
D
maintenance
This read-only MCP Server allows you to connect to SQL Server Analysis Services data from Claude Desktop through CData JDBC Drivers. For full CRUD support, check out our MCP Server for SQL Server Analysis Services (https://www.cdata.com/drivers/ssas/download/mcp).
Updated a year ago (2025-10-18 19:18 UTC)
1
MIT
sql-explorer-mcp
Databases Search
govern-agents
A
license
Not graded
quality
F
maintenance
Read-only MCP server for SQL databases (SQL Server, Postgres, SQLite) with multi-server support and three-layer safety using AST validation and linting.
Updated a month ago (2026-07-29 13:07 UTC)
MIT
SQL Query Tools MCP Server
Databases Security
negrip
F
license
A
quality
D
maintenance
MCP server for connecting to SQL Server in readonly mode. Allows any MCP client to explore the schema and run SELECT queries against a SQL Server database.
Updated 5 months ago (2026-04-01 20:52 UTC)
6

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dbdave/mssas_mcp_server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

SSAS MCP Server

Features

Requirements

Installation

Configuration

MCP registration (Claude Code / Claude Desktop)

Example usage

Result format

Tests

License

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Output Schema

TDQS

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Snowflake Cube Server

SQL Server Analysis Servicesofficial

sql-explorer-mcp

SQL Query Tools MCP Server

Latest Blog Posts

MCP directory API