Krusgraph

Create or update a Fabric data agent from the plan (dry run by default)

create_data_agent

DestructiveIdempotent

Creates a Fabric data agent over the source, with the plan as its instructions (business names, the joins that are safe and those that are not, header amounts not to sum over lines), the plan's tables selected and 3–5 example question/T-SQL pairs over safe joins, or updates the agent of that name in place. Only joins validate=true counted are called safe. Requires workspace, source and name; Item.ReadWrite.All or DataAgent.ReadWrite.All. Returns JSON with the instructions, examples, sizes against the documented limits and the REST calls; with dry_run=false also the result, or kind consent. Changes Fabric only with dry_run=false: instructions, data source and examples are replaced; nothing is deleted. 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": "<name>"
    },
    "name": "create_data_agent"
  }
}

Input Schema

Name	Required	Description	Default
`keys`	No	Primary keys replacing the inferred ones. Default: inferred. Example: {"order_items": ["order_id", "line_no"]}.
`name`	Yes	Display name of the data agent; an existing item with this name is updated in place. Example: "shop_agent".
`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.
`publish`	No	true (default) publishes the agent after creating or updating it; false leaves a draft. Example: false.
`validate`	No	true runs validate_plan's counting queries and includes the counts; false (default) reads metadata only.
`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.
`test_questions`	No	true also checks the plan against the rows (counts only, as validate_plan) and drafts 10-20 test questions for the agent, each with the T-SQL that gives the right answer, the answer's shape and the finding it tests. Default false.
`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.

Changed2 schema fields changedNov 6, 2026

addedInput schema / properties / test_questions

Added value: +{
+  "default": false,
+  "description": "true also checks the plan against the rows (counts only, as validate_plan) and drafts 10-20 test questions for the agent, each with the T-SQL that gives the right answer, the answer's shape and the finding it tests. Default false.",
+  "title": "Test Questions",
+  "type": "boolean"
+}

addedInput schema / properties / validate

Added value: +{
+  "default": false,
+  "description": "true runs validate_plan's counting queries and includes the counts; false (default) reads metadata only.",
+  "title": "Validate",
+  "type": "boolean"
+}

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

Added value: +"Display name of the data agent; an existing item with this name is updated in place. Example: \"shop_agent\"."

addedInput schema / properties / publish / description

Added value: +"true (default) publishes the agent after creating or updating it; false leaves a draft. Example: false."

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

Added value: +"Lakehouse, warehouse or SQL database, name or id."

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

First observedOct 27, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well past the annotations by naming the exact permission scopes required (Item.ReadWrite.All or DataAgent.ReadWrite.All), the precise mutation boundary with dry_run=false (instructions, data source and examples are replaced; nothing is deleted), the error envelope {error, kind, hint}, and the personal-data masking default. The 'nothing is deleted / replaced' framing also refines what destructiveHint=true actually means in practice.

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-loads the action and keeps every clause information-bearing: safety rule, permissions, return shape, mutation scope, error format. It is dense to the point of being a single sprawling sentence with parenthetical lists, which costs some readability, but no sentence is filler.

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 an 11-parameter, open-world mutation tool this covers everything an agent needs before calling: defaults, required fields, permission prerequisites, what is and isn't modified, and the failure shape. Return values are already covered by the output schema, so the extra return summary is a bonus rather than a gap.

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 carries parameter meaning; the description only echoes the three required inputs (workspace, source, name). It adds the derived rule that only validate=true-counted joins are treated as safe and that 3-5 example pairs are generated, but does not explain keys, confirmed, or publish beyond what the schema states.

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 ('Creates a Fabric data agent over the source') and immediately distinguishes the create vs. update path ('or updates the agent of that name in place'). It also names the upstream artifact the plan supplies and the sibling whose logic it reuses (validate_plan), so an agent can separate it from plan/review tools without opening the 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?

Gives clear operating context: dry_run=true by default changes nothing, dry_run=false commits, and validate=true reuses validate_plan's counting queries to determine which joins count as safe. It never explicitly states when to prefer a sibling (e.g. review_plan or plan_backend) over this tool, so the when-not guidance is only implied.

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.