Skip to main content
Glama
Jasuni69

Microsoft Fabric MCP Server

by Jasuni69

create_measure

Add a DAX measure to a semantic model by specifying name, expression, and target table, with optional formatting and visibility settings.

Instructions

Create a new DAX measure in a semantic model.

Args:
    measure_name: Name of the measure to create
    dax_expression: DAX formula for the measure
    table_name: Name of the table to add the measure to
    workspace: Name or ID of the workspace (optional)
    model: Name or ID of the semantic model (optional)
    format_string: Display format string (e.g., "#,0.00", "0.0%") (optional)
    description: Description of the measure (optional)
    is_hidden: Whether to hide the measure from client tools (default: False)
    ctx: Context object containing client information

Returns:
    A dictionary containing success status and the created measure details.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelNo
is_hiddenNo
workspaceNo
table_nameYes
descriptionNo
measure_nameYes
format_stringNo
dax_expressionYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior3/5

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

There are no annotations, so the description carries the behavioral disclosure burden. It does state that this creates a measure and that the return value includes a success status and created details. However, it does not disclose behavior around duplicate measure names, persistence/commit semantics, or how optional workspace/model defaults are resolved from ctx.

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?

The description is a one-line purpose followed by a structured Args list that maps directly to the 8 parameters, plus a Returns line. There is no fluff, and the examples for format_string earn their place because the schema provides no descriptions.

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 no annotations, no output schema, and no schema descriptions, the description is substantially complete: it covers the operation, every parameter, and the return contract. Minor gaps remain around duplicate handling, error behavior, and a fuller explanation of how ctx supplies default workspace/model context.

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?

The input schema has 0% description coverage, but the description's Args section defines all 8 parameters with plain-language meaning, defaults, optionality, and format string examples. This fully compensates for the schema gap.

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 opens with a specific verb+resource: 'Create a new DAX measure in a semantic model.' The word 'new' clearly distinguishes this from update_measure and delete_measure, and the artifact type is specific enough to avoid confusion with other siblings.

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 gives clear context for when to use the tool: when a new DAX measure should be created. Sibling names like update_measure and delete_measure make the lifecycle role obvious, but the description does not explicitly direct agents away from those alternatives or mention prerequisites like an existing semantic model.

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

Latest Blog Posts

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/Jasuni69/ms-core-mcp'

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