Krusgraph

Create or update the gold-views notebook in Fabric (dry run by default)

create_gold_views

DestructiveIdempotent

Creates a Fabric notebook item with gold_views_draft's notebook, or updates the notebook of that name in place. Requires workspace, a lakehouse source with schemas and name; Notebook.ReadWrite.All or Item.ReadWrite.All and Contributor. Returns JSON with the views, the notebook and the REST call; with dry_run=false also the result. Changes Fabric only with dry_run=false: the notebook's content is replaced, no item is deleted, and nothing runs; when run, it stops before writing over a table it did not create. 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_gold_views"
  }
}

Input Schema

Name	Required	Description	Default
`keys`	No	Primary keys replacing the inferred ones. Default: inferred. Example: {"order_items": ["order_id", "line_no"]}.
`name`	Yes	Display name of the notebook item; an existing item with this name is updated in place. Example: "gold_shop".
`schema`	No	Schema in the source. Default "dbo".	dbo
`source`	Yes	Lakehouse, warehouse or SQL database, name or id.
`tables`	No	Exact table names to include. Default all.
`dry_run`	No	true (default) returns what would be created and the REST calls, changing nothing; false creates or updates.
`confirmed`	No	Relationships the user confirmed, added to the plan. Default none. Example: [{"source": "orders", "source_cols": ["ship_to_id"], "target": "addresses", "target_cols": ["address_id"]}].
`workspace`	Yes	Fabric workspace, name or id.
`gold_schema`	No	Lakehouse schema for the gold views. Default "gold". Example: "gold".	gold
`silver_schema`	No	Lakehouse schema with the silver tables create_silver_notebook writes. Default "silver".	silver
`show_personal_data`	No	true includes columns named like personal data; false (default) masks or omits them.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedOct 29, 2026

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 / gold_schema / description

Added value: +"Lakehouse schema for the gold views. Default \"gold\". Example: \"gold\"."

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 notebook item; an existing item with this name is updated in place. Example: \"gold_shop\"."

addedInput schema / properties / schema / description

Added value: +"Schema in the source. Default \"dbo\"."

addedInput schema / properties / show_personal_data / description

Added value: +"true includes columns named like personal data; false (default) masks or omits them."

addedInput schema / properties / silver_schema / description

Added value: +"Lakehouse schema with the silver tables create_silver_notebook writes. Default \"silver\"."

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."
```

First observedOct 27, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already flag readOnly=false, destructive=true, idempotent=true, openWorld=true, but the description adds the operationally important details: nothing changes unless dry_run=false, the notebook's content is replaced rather than any item being deleted, nothing executes, and a run halts before overwriting a table it did not create. It also documents the error shape {error, kind, hint} and the conditional return payload.

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?

Four dense sentences, front-loaded with the create-or-update behavior followed by requirements, return shape, and safety scope — no filler. Slight clutter from the parenthetical in the title and the inline permission list, but every sentence carries information.

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?

For an 11-parameter, open-world, destructive mutation tool with annotations and an output schema present, the description covers the prerequisite permissions, the dry-run safety model, the scope of what is replaced or preserved, and the error contract. An agent has everything needed to call it correctly without opening the schema.

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 description coverage is 100%, so the schema already explains keys, tables, confirmed, show_personal_data, etc., and the description largely restates the required parameters rather than adding semantics. It does usefully note that this is the schema create_silver_notebook writes to, but per-parameter meaning beyond the schema is minimal — baseline 3.

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?

States a specific verb+resource with scope: creates a Fabric notebook item from gold_views_draft's notebook, or updates the same-named notebook in place. It also distinguishes itself from neighbors by naming gold_views_draft as the source artifact and by framing silver_schema around create_silver_notebook, so an agent can pick it over create_views or create_silver_notebook.

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 preconditions (workspace, lakehouse source with schemas and a name, Notebook.ReadWrite.All or Item.ReadWrite.All plus Contributor) and explains the dry_run default gate, which is effectively when-to-use guidance. It stops short of explicit routing rules like 'use gold_views_draft first to preview the plan' — that is only implied by 'with gold_views_draft's notebook'.

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

All Krusgraph tools Inspect

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.