Krusgraph

Draft gold views as materialized lake views (nothing created)

gold_views_draft

Read-only

Drafts materialized lake views (Spark SQL) over the silver tables: one wide view per fact table in gold_schema, dimensions joined over many-to-one paths, the plan's keys and relationships as CHECK rules. Requires workspace and a lakehouse with schemas. Returns JSON with the SQL per view and the notebook that creates them. Changes nothing; create_gold_views creates the notebook. 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": "gold_views_draft"
  }
}

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.
`tables`	No	Exact table names to include. Default all.
`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.
`gold_schema`	No	Lakehouse schema for the gold views. Default "gold". Example: "gold".	gold
`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.

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

Added value: +"Lakehouse schema for the gold views. Default \"gold\". Example: \"gold\"."

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

A4.6/5.0

Behavior4/5

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

The 'Changes nothing' statement and the pointer to create_gold_views reinforce the readOnlyHint=true / destructiveHint=false annotations rather than contradicting them, and the description adds the error contract {error, kind, hint}. It does not add much about the openWorldHint=true externality (e.g., cost or latency of reading the source), which keeps it from a 5.

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?

One dense but front-loaded paragraph: purpose, then mechanics, prerequisites, return shape, safety, and error contract in that order. No sentence is filler and the most decision-critical clause ('Changes nothing') is not buried.

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 9-parameter tool this is well covered: annotations carry safety, an output schema exists, and the description supplies prerequisites, return shape, and error format. The one real gap is that 'the plan' is referenced without saying where it comes from (validate_plan/review_plan/suggest_relationships among siblings), leaving an agent to infer the prior step.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema baseline is 3; the description earns more by explaining how keys and confirmed relationships are consumed ('the plan's keys and relationships as CHECK rules', 'dimensions joined over many-to-one paths'). That conceptual framing adds value over the per-parameter examples, though it never touches show_personal_data masking behavior.

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 ('Drafts materialized lake views (Spark SQL) over the silver tables') plus the scope rule 'one wide view per fact table in gold_schema'. It also explicitly separates itself from create_gold_views, so the agent can distinguish the two without opening either schema.

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

Usage Guidelines5/5

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

Gives the prerequisite ('Requires workspace and a lakehouse with schemas') and names the alternative with the condition that selects it ('Changes nothing; create_gold_views creates the notebook'). An agent knows this is the safe preview 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.