Krusgraph

Create or alter T-SQL views in a schema of their own (dry run by default)

create_views

DestructiveIdempotent

Creates or alters wide T-SQL views over the plan on the source's SQL analytics endpoint or warehouse: one per fact table with its dimensions, one per header table. Requires workspace and source; rights to create objects (Contributor is enough). Returns JSON with the SQL; with dry_run=false also what ran. Changes Fabric only with dry_run=false and only in views_schema: CREATE OR ALTER replaces views of the same name; nothing is dropped. 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": "create_views"
  }
}

Input Schema

Name	Required	Description	Default
`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.
`dry_run`	No	true (default) returns what would be created and the REST calls, changing nothing; false creates or updates.
`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.
`views_schema`	No	Schema the T-SQL views go into; created if missing. Default "krusgraph". Example: "reporting".	krusgraph

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 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 / 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 / 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 / views_schema / description

Added value: +"Schema the T-SQL views go into; created if missing. Default \"krusgraph\". Example: \"reporting\"."

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

First observedOct 27, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Goes well beyond the annotations: names the required permission level (Contributor), explains that Fabric is only mutated when dry_run=false and only inside views_schema, that CREATE OR ALTER replaces same-named views, that nothing is dropped, and that errors come back as {error, kind, hint}. The replacement semantics reconcile with destructiveHint=true rather than contradicting it.

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?

Three tight sentences, front-loaded with the operation and its scope, then requirements, then side effects, then error shape. The middle clause about fact/header tables is dense but earns its place by explaining output structure; nothing is padding.

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?

Given an output schema exists and annotations cover read-only/destructive/idempotent hints, the description supplies the remaining decision-critical facts: permission requirement, dry-run default, mutation scope, and replacement behavior. Minor gap: no hint about scale/cost or when the inferred keys need overriding, which is the most likely failure mode.

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 keys, confirmed, views_schema, and dry_run are already fully documented with defaults and examples. The description only reinforces required-vs-context (workspace, source) and the views_schema scoping; it adds no syntax or default detail beyond the schema. Baseline 3 applies.

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?

States a specific verb pair (creates or alters) and resource (wide T-SQL views over the plan on the SQL analytics endpoint or warehouse), plus the shape of what it emits (one per fact table with dimensions, one per header table). That is far more than a restatement of the name. It does not name the nearest sibling (create_gold_views, gold_views_draft) to sharpen the boundary, so it falls short of 5.

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 operating context: requires workspace and source, Contributor rights suffice, and dry_run defaults to true so the safe path is the default. It does not say when an agent should prefer create_gold_views or gold_views_draft instead, so there is no explicit alternative routing.

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.