Krusgraph

Create or update the nightly drift monitor in Fabric (dry run by default)

create_drift_monitor

DestructiveIdempotent

Creates drift_monitor_draft's notebook and pipeline, or updates the items of those names in place; with schedule=true also adds a daily schedule unless one at that time exists. Requires workspace, a lakehouse source and name; Notebook.ReadWrite.All and DataPipeline.ReadWrite.All (or Item.ReadWrite.All), and Contributor. schedule is false by default: the schedule needs DataPipeline.Execute.All, which the hosted app does not request. Returns JSON with the items and REST calls; with dry_run=false also each step's result. Changes Fabric only with dry_run=false: the two items' definitions are replaced, existing schedules are kept, nothing is deleted and no secret is written. 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_drift_monitor"
  }
}

Input Schema

Name	Required	Description	Default
`at`	No	Daily run time, hh:mm in time_zone. Default "02:00". Example: "05:30".	02:00
`name`	Yes	Base name of the notebook and pipeline; existing items with these names are updated in place. Example: "drift_shop".
`schema`	No	Schema in the source. Default "dbo".	dbo
`source`	Yes	Lakehouse, warehouse or SQL database, name or id.
`dry_run`	No	true (default) returns what would be created and the REST calls, changing nothing; false creates or updates.
`schedule`	No	false (default) creates the items without a schedule: a schedule needs DataPipeline.Execute.All, which the hosted app does not request; true adds the daily schedule where that permission is granted. Example: true.
`time_zone`	No	Windows time zone id for `at`. Default "W. Europe Standard Time". Example: "UTC".	W. Europe Standard Time
`workspace`	Yes	Fabric workspace, name or id.
`library_ref`	No	Git tag, branch or commit of fabric-backend that the notebook installs. Default: the tag of this server's version. Example: "main".

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 8, 2026

changedInput schema / properties / schedule / default
```
Previous value: -trueNew value: +false
```

changedInput schema / properties / schedule / description

Previous value: -"true (default) adds the daily schedule to the pipeline; false creates the items without one. Example: false."New value: +"false (default) creates the items without a schedule: a schedule needs DataPipeline.Execute.All, which the hosted app does not request; true adds the daily schedule where that permission is granted. Example: true."

Changed9 schema fields changedOct 29, 2026

addedInput schema / properties / at / description

Added value: +"Daily run time, hh:mm in time_zone. Default \"02:00\". Example: \"05:30\"."

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

Added value: +"Git tag, branch or commit of fabric-backend that the notebook installs. Default: the tag of this server's version. Example: \"main\"."

addedInput schema / properties / name / description

Added value: +"Base name of the notebook and pipeline; existing items with these names are updated in place. Example: \"drift_shop\"."

addedInput schema / properties / schedule / description

Added value: +"true (default) adds the daily schedule to the pipeline; false creates the items without one. Example: false."

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

Added value: +"Windows time zone id for `at`. Default \"W. Europe Standard Time\". Example: \"UTC\"."

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?

Goes well beyond annotations: it spells out that nothing changes unless dry_run=false, that the two items' definitions are replaced, that existing schedules are preserved, that nothing is deleted and no secret is written, and it reports the {error, kind, hint} error shape. This reconciles the destructiveHint=true annotation with the reassuring 'nothing is deleted' claim in a way an agent can act on.

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?

Dense but front-loaded: creation/update scope first, then prerequisites, then the dry_run safety contract. The permission rationale for schedule is stated both in the description and the schema, a minor duplication, and the mid-sentence clause runs long, but no sentence is pure filler.

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 9-parameter mutation with an output schema, the description covers the missing pieces: required auth, the dry-run gate, what gets replaced vs kept, and the error envelope. An agent has everything needed to decide and call safely.

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 every parameter already carries its own description with defaults and examples. The description reinforces the dry_run and schedule semantics and their permission coupling but adds little syntax or meaning the schema does not already contain; 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?

States a specific verb+resource pair: creates the notebook and pipeline that drift_monitor_draft produces, or updates items of those names in place. The reference to the sibling draft tool makes it distinguishable from drift_monitor_draft, plan_drift and create_pipeline without opening any 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?

Gives clear preconditions (workspace, lakehouse source, name, Contributor plus the listed scopes) and explains the schedule=false default is driven by a permission the hosted app does not hold. It does not explicitly tell the agent to run drift_monitor_draft first, but the item-name linkage makes the sequencing implied rather than stated.

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.