Skip to main content
Glama
Sign In

Krusgraph

by com.krusgraph
OverviewDiscussions(1)Admin

Keep the reviewed plan as a file (nothing in Fabric changes)

review_plan
Read-only

Builds a review file of the plan: each key and relationship with a review status and a check status, plus a Markdown report. Requires workspace and source. Returns JSON with the file, the report and what needs attention first, no row values. 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": "review_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
keysNoPrimary keys replacing the inferred ones. Default: inferred. Example: {"order_items": ["order_id", "line_no"]}.
schemaNoSchema in the source. Default "dbo".dbo
sourceYesLakehouse, warehouse or SQL database, name or id.
tablesNoTable names or globs to show. Default all. Example: ["sales_*"].
previousNoAn earlier file from review_plan (object or JSON text); its decisions are applied again and checks on changed tables become stale. Default: none. Example: the "file" of the last answer.
validateNotrue runs validate_plan's counting queries and includes the counts; false (default) reads metadata only.
confirmedNoRelationships the user confirmed, added to the plan. Default none. Example: [{"source": "orders", "source_cols": ["ship_to_id"], "target": "addresses", "target_cols": ["address_id"]}].
decisionsNoReview decisions, [{"item", "review", "reason"}]; review is accepted, rejected, open or proposed; item ids are in the file. Default: none. Example: [{"item": "rel:orders.ship_to_id>addresses", "review": "accepted", "reason": "checked with sales"}].
max_itemsNoCap on counting queries (one per key and relationship), 1–200. Default 60.
workspaceYesFabric workspace, name or id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "review_planOutput",
-  "type": "object"
-}New value: +null
  2. Changed10 schema fields changed
    • 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 / decisions / description
      Added value: +"Review decisions, [{\"item\", \"review\", \"reason\"}]; review is accepted, rejected, open or proposed; item ids are in the file. Default: none. Example: [{\"item\": \"rel:orders.ship_to_id>addresses\", \"review\": \"accepted\", \"reason\": \"checked with sales\"}]."
    • 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 / max_items / description
      Added value: +"Cap on counting queries (one per key and relationship), 1–200. Default 60."
    • addedInput schema / properties / previous / description
      Added value: +"An earlier file from review_plan (object or JSON text); its decisions are applied again and checks on changed tables become stale. Default: none. Example: the \"file\" of the last answer."
    • 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: +"Table names or globs to show. Default all. Example: [\"sales_*\"]."
    • addedInput schema / properties / validate / description
      Added value: +"true runs validate_plan's counting queries and includes the counts; false (default) reads metadata only."
    • addedInput schema / properties / workspace / description
      Added value: +"Fabric workspace, name or id."
  3. First observed

TDQS

A3.8/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.' Beyond that it adds genuinely new behavior: no row values are returned, the response shape is JSON with file, report and what needs attention first, and errors come back as {error, kind, hint}. That is meaningful context the annotations do not supply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is telegraphic but front-loaded: what is built, what it requires, what it returns, that it mutates nothing, and the error shape, in five short clauses. No sentence is filler, and the safety statement is placed prominently.

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?

For a 10-parameter, read-only, no-output-schema tool, the description covers the essentials: required inputs, return payload, the 'no row values' limitation, side-effect freedom, and the error contract. It could go slightly further on how the returned file is meant to be fed back via 'previous', but nothing critical 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%, so each of the 10 parameters is already documented in the schema, which sets the baseline at 3. The description only adds that workspace and source are required and gestures at max_items as a cap on counting queries; it does not elaborate on the non-obvious semantics of keys, confirmed, or previous beyond what the schema already says.

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 states a specific verb and artifact: it 'builds a review file of the plan' containing keys and relationships with review and check statuses plus a Markdown report. That is clearly distinct from a plain validate or suggest operation. It does not explicitly name the sibling it differs from (validate_plan appears only inside a parameter description), so it stops short of full sibling differentiation.

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?

Usage is implied rather than stated: the 'previous' parameter and the 'decisions' parameter sketch an iterative review workflow, and the 'validate' parameter hints at when to escalate to counting queries. There is no explicit when-to-use or when-not-to-use guidance, and no direct routing statement such as 'use validate_plan instead when you only need counts'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Krusgraph toolsInspect
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.

Resources