Skip to main content
Glama
Sign In

Krusgraph

by com.krusgraph
OverviewDiscussions(1)Admin

Create or update a Power BI semantic model (dry run by default)

create_semantic_model
DestructiveIdempotent

Creates a Fabric semantic model item from semantic_model_draft's TMDL (Direct Lake), or updates the item of that name in place. Requires workspace, source and name; SemanticModel.ReadWrite.All or Item.ReadWrite.All and Contributor on the workspace. Returns JSON with the parts and the REST call; with dry_run=false also the result, or kind consent. Changes Fabric only with dry_run=false: an update replaces the model's definition, so tables, relationships and measures added outside the plan leave it; no item is deleted. Errors: {error, kind, hint}.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "workspace": "<workspace>",
      "source": "<source>",
      "name": "<name>"
    },
    "name": "create_semantic_model"
  }
}

Input Schema

NameRequiredDescriptionDefault
keysNoPrimary keys replacing the inferred ones. Default: inferred. Example: {"order_items": ["order_id", "line_no"]}.
nameYesDisplay name of the semantic model item; an existing item with this name is updated in place. Example: "shop_model".
schemaNoSchema in the source. Default "dbo".dbo
sourceYesLakehouse, warehouse or SQL database, name or id.
tablesNoExact table names to include. Default all.
dry_runNotrue (default) returns what would be created and the REST calls, changing nothing; false creates or updates.
confirmedNoRelationships the user confirmed, added to the plan. Default none. Example: [{"source": "orders", "source_cols": ["ship_to_id"], "target": "addresses", "target_cols": ["address_id"]}].
workspaceYesFabric workspace, name or id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "create_semantic_modelOutput",
-  "type": "object"
-}New value: +null
  2. Changed8 schema fields changed
    • addedInput schema / properties / confirmed / description
      Added value: +"Relationships the user confirmed, added to the plan. Default none. Example: [{\"source\": \"orders\", \"source_cols\": [\"ship_to_id\"], \"target\": \"addresses\", \"target_cols\": [\"address_id\"]}]."
    • addedInput schema / properties / dry_run / description
      Added value: +"true (default) returns what would be created and the REST calls, changing nothing; false creates or updates."
    • addedInput schema / properties / keys / description
      Added value: +"Primary keys replacing the inferred ones. Default: inferred. Example: {\"order_items\": [\"order_id\", \"line_no\"]}."
    • addedInput schema / properties / name / description
      Added value: +"Display name of the semantic model item; an existing item with this name is updated in place. Example: \"shop_model\"."
    • addedInput schema / properties / schema / description
      Added value: +"Schema in the source. Default \"dbo\"."
    • addedInput schema / properties / source / description
      Added value: +"Lakehouse, warehouse or SQL database, name or id."
    • addedInput schema / properties / tables / description
      Added value: +"Exact table names to include. Default all."
    • addedInput schema / properties / workspace / description
      Added value: +"Fabric workspace, name or id."
  3. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the supplied annotations (destructiveHint=true, idempotentHint=true, openWorldHint=true), the description explains exactly what destruction means: with dry_run=false an update replaces the model definition, so tables, relationships and measures added outside the plan are dropped, while no item is ever deleted. It also discloses the return payload (parts plus REST call, result or consent kind) and the error shape, which annotations cannot convey.

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 purpose and the safety modifier come first, followed by prerequisites, return shape, and side effects, which is good front-loading. The prose is dense and a few clauses are crammed into single long sentences, but every sentence carries information an agent needs to call it safely.

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?

For an eight-parameter mutation tool with no output schema, the description covers permissions, the dry-run gate, the destructive update semantics, the return payload, and the error envelope, which is close to complete. Residual gaps are the unexplained 'kind consent' response mode and no guidance on the optional keys, tables, or confirmed parameters.

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

Parameters3/5

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

Schema coverage is 100%, so all eight parameters are already documented in the schema, including the dry_run and confirmed semantics; the description mostly restates the required trio (workspace, source, name). It adds only a small amount of meaning, notably that dry_run=false is what actually flips the tool into a mutation, so the baseline 3 is appropriate.

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 and resource pair ('Creates a Fabric semantic model item from semantic_model_draft's TMDL (Direct Lake), or updates the item of that name in place'), naming both the create and upsert semantics. It explicitly names the sibling `semantic_model_draft` as the upstream source of the TMDL, so an agent can place it in the workflow without opening the schema.

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?

It gives clear operating context: dry_run defaults to true so nothing changes unless explicitly requested, and it lists the required arguments and required permissions. However, it never states when to choose this over neighbours like `create_backend`, `create_report`, or `compare_semantic_model`, so routing between mutation siblings is left to inference.

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

All Krusgraph toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources