Krusgraph

Draft a PySpark notebook that builds silver tables (nothing created)

silver_notebook_draft

Read-only

Drafts a PySpark notebook writing de-duplicated silver Delta tables: one row per key, references checked, broken rows to krusgraph_quarantine. Requires workspace and a lakehouse source. Returns JSON with the steps and the notebook source. Changes nothing. 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": "silver_notebook_draft"
  }
}

Input Schema

Name	Required	Description	Default
`keys`	No	Primary keys replacing the inferred ones. Default: inferred. Example: {"order_items": ["order_id", "line_no"]}.
`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.
`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"
+}

Changed9 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 / keys / description

Added value: +"Primary keys replacing the inferred ones. Default: inferred. Example: {\"order_items\": [\"order_id\", \"line_no\"]}."

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

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description corroborates with 'Changes nothing' plus the return shape ('Returns JSON with the steps and the notebook source') and the error contract '{error, kind, hint}'. It also discloses a side destination (broken rows to krusgraph_quarantine) and validation behavior ('references checked'), which are real behavioral details not present in the annotations.

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 compact sentences that front-load the artifact, then prerequisites, output, and the no-change guarantee. No filler, though the telegraphic phrasing ('references checked') is denser than it needs to be for a first read.

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?

An output schema exists and the description still summarizes the return and error shapes, and all 10 parameters are documented in the schema, so nothing an agent needs is missing. The one gap is the absence of explicit routing guidance against the sibling draft/create tools in a crowded 38-tool namespace.

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%, including examples for keys, order_by and confirmed, so the schema carries the parameter burden. The description only gestures at parameters indirectly through 'one row per key', 'references checked' and 'de-duplicated', adding marginal semantics beyond the structured fields. Baseline 3 is appropriate here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and artifact ('Drafts a PySpark notebook writing de-duplicated silver Delta tables') and the title reinforces the no-side-effect nature with '(nothing created)'. It implicitly separates drafting from the sibling create_silver_notebook via 'Changes nothing', but never names that sibling explicitly, so differentiation requires inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States prerequisites ('Requires workspace and a lakehouse source') and implies a preview-then-create workflow through 'Changes nothing', but gives no explicit when-to-use vs. create_silver_notebook or gold_views_draft. The agent must infer that this is the review step before the create step.

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.