powerbi-modeling
Verifiedby github · Updated Apr 16, 2026
Power BI semantic modeling assistant for building optimized data models. Use when working with Power BI semantic models, creating measures, designing star schemas, configuring relationships, implementing RLS, or optimizing model performance. Triggers on queries about DAX calculations, table relationships, dimension/fact table design, naming conventions, model documentation, cardinality, cross-filter direction, calculation groups, and data model best practices. Always connects to the active model first using power-bi-modeling MCP tools to understand the data structure before providing guidance.
See It In Action
Let me explore the codebase first to understand the current state of the model.
Now I have the full picture. Here are the problems:
- Region totals wrong: Two bidirectional relationships create an ambiguous filter path from Region → Sales (direct path AND through Customer). This causes double-counting/inconsistent aggregations.
- No gross margin measures: Missing
Gross ProfitandGross Margin %.
Let me fix both issues now.
Now add the gross margin measures and the USERELATIONSHIP measure.
Now add the USERELATIONSHIP measure so the Region slicer can still filter customer names (the original reason for the bidir filter).
Let me verify the final model looks correct.
Now let me clean up the stale comment in the relationships section header.
All done. Here's a summary of what was wrong and what changed:
Root Cause: Region Totals Off
Two relationship problems were compounding:
-
rel_Sales_RegionhadBothDirectionscross-filter — filters were flowing back from Sales into Region, causing unexpected aggregation behavior. -
rel_Customer_Regionwas alsoBothDirectionsand active — this created a second active path from Region to Sales (Region → Customer → Sales), on top of the direct path (Region → Sales). Power BI couldn't resolve the ambiguity, inflating/double-counting region totals.
Changes Made (2026-04-12)
Relationship Fixes
| Relationship | Before | After |
|---|---|---|
rel_Sales_Region | BothDirections | OneDirection |
rel_Customer_Region | BothDirections, active | OneDirection, inactive |
New Measures Added
| Measure | DAX | Format |
|---|---|---|
Gross Profit | [Total Sales] - [Total Cost] | $#,##0 |
Gross Margin % | DIVIDE([Gross Profit], [Total Sales], BLANK()) | 0.0% |
Customers by Region | CALCULATE(DISTINCTCOUNT(...), USERELATIONSHIP(...)) | #,##0 |
Why Customers by Region?
The original bidir filter was set up so a Region slicer could filter customer names. Deactivating rel_Customer_Region breaks that. The new Customers by Region measure uses USERELATIONSHIP to activate that path only when needed — same functionality, no ambiguity.
After deploying
- Region totals (Total Sales, Sales YTD, etc.) should now match correctly across all slicers
- Gross Profit and Gross Margin % are ready for the exec dashboard
- If any visual was relying on the Region slicer to directly filter a Customer Name table/list, swap it to use the
Customers by Regionmeasure or add a similar USERELATIONSHIP-based measure for that visual
External Tools
| Tool | Type |
|---|---|
| power-bi-modeling | mcp |
| microsoft-learn | mcp |
Permissions
| Scope | Description |
|---|---|
| network:outbound |
SKILL.md
Power BI Semantic Modeling
Guide users in building optimized, well-documented Power BI semantic models following Microsoft best practices.
When to Use This Skill
Use this skill when users ask about:
- Creating or optimizing Power BI semantic models
- Designing star schemas (dimension/fact tables)
- Writing DAX measures or calculated columns
- Configuring table relationships (cardinality, cross-filter)
- Implementing row-level security (RLS)
- Naming conventions for tables, columns, measures
- Adding descriptions and documentation to models
- Performance tuning and optimization
- Calculation groups and field parameters
- Model validation and best practice checks
Trigger phrases: "create a measure", "add relationship", "star schema", "optimize model", "DAX formula", "RLS", "naming convention", "model documentation", "cardinality", "cross-filter"
Prerequisites
Required Tools
- Power BI Modeling MCP Server: Required for connecting to and modifying semantic models
- Enables: connection_operations, table_operations, measure_operations, relationship_operations, etc.
- Must be configured and running to interact with models
Optional Dependencies
- Microsoft Learn MCP Server: Recommended for researching latest best practices
- Enables: microsoft_docs_search, microsoft_docs_fetch
- Use for complex scenarios, new features, and official documentation
Workflow
1. Connect and Analyze First
Before providing any modeling guidance, always examine the current model state:
1. List connections: connection_operations(operation: "ListConnections")
2. If no connection, check for local instances: connection_operations(operation: "ListLocalInstances")
3. Connect to the model (Desktop or Fabric)
4. Get model overview: model_operations(operation: "Get")
5. List tables: table_operations(operation: "List")
6. List relationships: relationship_operations(operation: "List")
7. List measures: measure_operations(operation: "List")
2. Evaluate Model Health
After connecting, assess the model against best practices:
- Star Schema: Are tables properly classified as dimension or fact?
- Relationships: Correct cardinality? Minimal bidirectional filters?
- Naming: Human-readable, consistent naming conventions?
- Documentation: Do tables, columns, measures have descriptions?
- Measures: Explicit measures for key calculations?
- Hidden Fields: Are technical columns hidden from report view?
3. Provide Targeted Guidance
Based on analysis, guide improvements using references:
- Star schema design: See STAR-SCHEMA.md
- Relationship configuration: See RELATIONSHIPS.md
- DAX measures and naming: See MEASURES-DAX.md
- Performance optimization: See PERFORMANCE.md
- Row-level security: See RLS.md
Quick Reference: Model Quality Checklist
| Area | Best Practice |
|---|---|
| Tables | Clear dimension vs fact classification |
| Naming | Human-readable: Customer Name not CUST_NM |
| Descriptions | All tables, columns, measures documented |
| Measures | Explicit DAX measures for business metrics |
| Relationships | One-to-many from dimension to fact |
| Cross-filter | Single direction unless specifically needed |
| Hidden fields | Hide technical keys, IDs from report view |
| Date table | Dedicated marked date table |
MCP Tools Reference
Use these Power BI Modeling MCP operations:
| Operation Category | Key Operations |
|---|---|
connection_operations | Connect, ListConnections, ListLocalInstances, ConnectFabric |
model_operations | Get, GetStats, ExportTMDL |
table_operations | List, Get, Create, Update, GetSchema |
column_operations | List, Get, Create, Update (descriptions, hidden, format) |
measure_operations | List, Get, Create, Update, Move |
relationship_operations | List, Get, Create, Update, Activate, Deactivate |
dax_query_operations | Execute, Validate |
calculation_group_operations | List, Create, Update |
security_role_operations | List, Create, Update, GetEffectivePermissions |
Common Tasks
Add Measure with Description
measure_operations(
operation: "Create",
definitions: [{
name: "Total Sales",
tableName: "Sales",
expression: "SUM(Sales[Amount])",
formatString: "$#,##0",
description: "Sum of all sales amounts"
}]
)
Update Column Description
column_operations(
operation: "Update",
definitions: [{
tableName: "Customer",
name: "CustomerKey",
description: "Unique identifier for customer dimension",
isHidden: true
}]
)
Create Relationship
relationship_operations(
operation: "Create",
definitions: [{
fromTable: "Sales",
fromColumn: "CustomerKey",
toTable: "Customer",
toColumn: "CustomerKey",
crossFilteringBehavior: "OneDirection"
}]
)
When to Use Microsoft Learn MCP
Research current best practices using microsoft_docs_search for:
- Latest DAX function documentation
- New Power BI features and capabilities
- Complex modeling scenarios (SCD Type 2, many-to-many)
- Performance optimization techniques
- Security implementation patterns
FAQ
What does powerbi-modeling do?
Power BI semantic modeling assistant for building optimized data models. Use when working with Power BI semantic models, creating measures, designing star schemas, configuring relationships, implementing RLS, or optimizing model performance. Triggers on queries about DAX calculations, table relationships, dimension/fact table design, naming conventions, model documentation, cardinality, cross-filter direction, calculation groups, and data model best practices. Always connects to the active model first using power-bi-modeling MCP tools to understand the data structure before providing guidance.
When should I use powerbi-modeling?
Use it when you need a repeatable workflow that produces code diff.
What does powerbi-modeling output?
In the evaluated run it produced code diff.
How do I install or invoke powerbi-modeling?
Ask the agent to use this skill when the task matches its documented workflow.
Which agents does powerbi-modeling support?
Agent support is inferred from the source, but not explicitly declared.
What tools, channels, or permissions does powerbi-modeling need?
It uses power-bi-modeling, microsoft-learn; channels commonly include diff; permissions include network:outbound.
Is powerbi-modeling safe to install?
Static analysis marked this skill as medium risk; review side effects and permissions before enabling it.
How is powerbi-modeling different from an MCP or plugin?
A skill packages instructions and workflow conventions; tools, MCP servers, and plugins are dependencies the skill may call during execution.
Does powerbi-modeling outperform not using a skill?
About powerbi-modeling
When to use powerbi-modeling
When you need to inspect an existing Power BI semantic model before recommending or making modeling changes. When creating or refining DAX measures, relationships, naming conventions, descriptions, or row-level security in Power BI. When validating a model against star schema and performance best practices.
When powerbi-modeling is not the right choice
When the task is general BI advice that does not require connecting to a live Power BI semantic model. When working outside the Power BI semantic modeling ecosystem.
What it produces
Produces code diff.