Krusgraph

Compare today's plan with an existing GraphQL API

plan_drift

Read-only

Compares today's plan with an existing API for GraphQL item: new tables and columns, mapped columns the source no longer has, relationships the plan no longer supports, and whether create_backend with that name would change anything. Requires workspace, source and api. Returns JSON. Changes nothing; lineage shows what else builds on the tables. 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>",
      "api": "<api>"
    },
    "name": "plan_drift"
  }
}

Input Schema

Name	Required	Description	Default
`api`	Yes	Existing API for GraphQL item to compare with, by name or id. Example: "shop_api".
`keys`	No	Primary keys replacing the inferred ones. Default: inferred. Example: {"order_items": ["order_id", "line_no"]}.
`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.
`writable`	No	Whether the update create_backend would make includes mutations, as its writable. Default false. Example: true.
`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.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedOct 29, 2026

addedInput schema / properties / api / description

Added value: +"Existing API for GraphQL item to compare with, by name or id. Example: \"shop_api\"."

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

Added value: +"Exact table names to include. Default all."

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

addedInput schema / properties / writable / description

Added value: +"Whether the update create_backend would make includes mutations, as its writable. Default false. Example: true."

First observedOct 27, 2026

TDQS

A4.1/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 reinforces this with 'Changes nothing' plus a rare and useful disclosure that lineage reveals downstream dependents of the tables. It also documents the error envelope ({error, kind, hint}), which annotations cannot express. Missing only cost/latency or scale expectations for an openWorldHint tool.

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?

Front-loaded with the comparison itself, then scope of drift, then prerequisites, then side-effect note and error shape. Dense packing of the drift list into a comma chain and the run-on 'whether create_backend with that name would change anything' clause cost a little readability.

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, so return values need not be explained, and the description still covers side effects, lineage behavior and error structure. With 8 parameters and open-world source access, a brief note on what the comparison reads or its cost would complete the picture.

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% and the schema documents every parameter with examples (keys, tables, confirmed, writable). The description only restates the three required names, adding no format or interaction semantics beyond the schema. Baseline 3 is appropriate.

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 and resource ('Compares today's plan with an existing API for GraphQL item') and enumerates exactly what classes of drift are detected: new tables/columns, orphaned mapped columns, unsupported relationships, and whether create_backend would change anything. An agent can tell this apart from plan_backend, validate_plan and review_plan from the description alone.

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?

Implies the pre-flight use case relative to create_backend ('whether create_backend with that name would change anything'), which is the key routing signal. It gives prerequisites (workspace, source, api) but never explicitly contrasts against validate_plan or review_plan, which sit nearby in the sibling list.

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.