Krusgraph

Lineage: what builds on a source's tables

lineage

Read-only

Shows which Fabric objects in the workspace build on a source's tables: GraphQL APIs, semantic models, views on the SQL endpoint and data agents. Requires workspace and source. Returns JSON: a graph (nodes, edges), objects per table, tables nothing uses, items that could not be read, and with table, what a change to it reaches; format="openlineage" returns OpenLineage events instead; runs= returns its latest runs, per-activity status and Fabric's error text with a heuristic category and next step. Read-only: starts, cancels and fixes 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": "lineage"
  }
}

Input Schema

Name	Required	Description	Default
`runs`	No	A data pipeline or notebook in the workspace, by name or id: the answer is then its latest runs, each activity's status, Fabric's error text and a heuristic category with a next step, instead of the graph. Default: none. Example: "pipeline_shop".
`table`	No	One table to trace: the answer adds what a change to it reaches. Default: none. Example: "orders".
`format`	No	"graph" (default) or "openlineage": one OpenLineage RunEvent per object, tables as datasets with column names and types, relationship rules and counts in a custom facet; no row values.	graph
`schema`	No	Schema in the source. Default "dbo".	dbo
`source`	Yes	Lakehouse, warehouse or SQL database, name or id.
`workspace`	Yes	Fabric workspace, name or id.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 7, 2026

addedInput schema / properties / runs

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "A data pipeline or notebook in the workspace, by name or id: the answer is then its latest runs, each activity's status, Fabric's error text and a heuristic category with a next step, instead of the graph. Default: none. Example: \"pipeline_shop\".",
+  "title": "Runs"
+}

Changed1 schema field changedNov 6, 2026

addedInput schema / properties / format

Added value: +{
+  "default": "graph",
+  "description": "\"graph\" (default) or \"openlineage\": one OpenLineage RunEvent per object, tables as datasets with column names and types, relationship rules and counts in a custom facet; no row values.",
+  "enum": [
+    "graph",
+    "openlineage"
+  ],
+  "title": "Format",
+  "type": "string"
+}

Changed4 schema fields changedOct 29, 2026

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

Added value: +"One table to trace: the answer adds what a change to it reaches. Default: none. Example: \"orders\"."

addedInput schema / properties / workspace / description
```
Added value: +"Fabric workspace, name or id."
```

First observedOct 27, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint, so the safety bar is lower; the description still reinforces '(Read-only: starts, cancels and fixes nothing)' and adds real behavioral context — partial-read reporting ('items that could not be read') and a documented error shape {error, kind, hint}. It doesn't cover cost, rate limits or latency for an open-world traversal.

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 core scope and the two mode switches are front-loaded in the first two sentences, and no sentence is pure filler. The back half becomes a dense semicolon chain that packs runs/format/error behavior together, which is efficient but harder to scan than the opening.

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 six-parameter, read-only, open-world traversal tool with an output schema, the description covers what's needed: required context, the three result modes, read-only guarantees and the error contract. Return-value detail is largely carried by the output schema, so nothing important is left to guesswork.

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 documents workspace, source, schema, table, runs and format. The description restates the effect of the optional parameters (table adds impact, runs swaps the graph for run status, format=openlineage swaps the payload) but adds little syntax or format detail beyond the schema text.

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 ('Shows which Fabric objects in the workspace build on a source's tables') and enumerates the object types covered (GraphQL APIs, semantic models, SQL endpoint views, data agents). That scope makes it distinguishable from neighbors like list_tables, data_dictionary and query_graphql 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?

It states required context ('Requires workspace and source') and explains the three operating modes: default graph, table=<x> for impact-of-change, and runs=<pipeline|notebook> for run history instead of the graph. What's missing is an explicit comparison to siblings — it never says when to reach for data_dictionary or list_tables instead.

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.