Krusgraph

Create or update the silver-tables notebook in Fabric (dry run by default)

create_silver_notebook

DestructiveIdempotent

Creates a Fabric notebook item with silver_notebook_draft's notebook, attached to the lakehouse, or updates the notebook of that name in place. Requires workspace, a lakehouse source and name; Notebook.ReadWrite.All or Item.ReadWrite.All and Contributor. Returns JSON with the notebook and the REST call; with dry_run=false also the result, or kind consent. Changes Fabric only with dry_run=false: the notebook's content is replaced, no item is deleted, and nothing runs; when run, it writes only in silver_schema. 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_silver_notebook"
  }
}

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: "silver_shop".
`fixes`	No	Ids from validate_plan(fixes=true).
`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.
`order_by`	No	{table: column} deciding which duplicate row is kept (the latest wins). Default: a column named like updated_at. Example: {"orders": "modified_at"}.
`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.
`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.

Changed1 schema field changedNov 8, 2026

addedInput schema / properties / fixes

Added value: +{
+  "anyOf": [
+    {
+      "items": {},
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Ids from validate_plan(fixes=true).",
+  "title": "Fixes"
+}

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 / 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: \"silver_shop\"."

addedInput schema / properties / order_by / description

Added value: +"{table: column} deciding which duplicate row is kept (the latest wins). Default: a column named like updated_at. Example: {\"orders\": \"modified_at\"}."

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?

Beyond the annotations, it discloses the exact mutation boundary ('the notebook's content is replaced, no item is deleted, and nothing runs'), the write target ('writes only in silver_schema'), the permission requirements, and the error envelope. That reconciles the destructiveHint with the no-deletion guarantee in a way the hints alone cannot.

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 create-or-update behaviour and the dry_run gate are front-loaded, and every clause carries information. The middle sentence is a dense semicolon run-on, and restating the return payload is partly redundant with the output schema, keeping it just below top marks.

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 a 12-parameter idempotent mutation with side effects, the definition covers prerequisites, permissions, mutation scope, dry-run behaviour, and error shape. Nothing an agent needs in order to invoke it safely is missing.

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 percent, so each parameter already carries its own description and example. The prose only reinforces the required trio and the dry_run default, adding no format or interaction detail beyond the schema, so the baseline 3 applies.

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 first sentence names a specific verb and resource ('Creates a Fabric notebook item ... or updates the notebook of that name in place') and ties it to the silver_notebook_draft output, which cleanly separates it from the drafting sibling. An agent can tell create_silver_notebook apart from silver_notebook_draft or create_pipeline without opening a 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 the prerequisite set (workspace, lakehouse source and name), required permissions, and the two modes. What it never states explicitly is when to prefer it over alternatives such as running silver_notebook_draft alone or using create_pipeline for the same load, so the agent must infer the draft-then-create sequence.

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.