Tools
All tools take the workspace by id or display name. schema defaults to dbo; keys overrides a table's key ({"order_items": ["order_id", "line_no"]}), confirmed adds relationships the rules did not make ([{"source": "orders", "source_cols": ["ship_to_id"], "target": "addresses", "target_cols": ["address_id"]}]), tables limits what is built. A confirmed entry can also name the relationship's two GraphQL fields: field_name on the source ("address": orders.address) and reverse_name on the target ("orders": addresses.orders); without them the rules name the fields (ship_to and orders_as_ship_to here). When an API of that name exists, create_backend and plan_drift keep the field names it already has for the same relationship (the same columns in the same direction) unless confirmed names them otherwise, and their keep_with_confirmed entries carry both names.
| Tool | Status | What it changes | Does | Arguments |
|---|---|---|---|---|
list_workspaces | Tested end to end | nothing | the workspaces the signed-in account can see, with id, name and capacity | — |
list_sources | Tested end to end | nothing | lakehouses, warehouses, SQL databases, Snowflake databases, mirrored databases and catalogs in the workspace, plus existing API for GraphQL items | workspace |
list_tables | Tested end to end | nothing | tables and columns with types in one schema; tables narrows to names or patterns (["sales_*"]), detail is auto (full up to 60 tables, then the column count per table), full or summary | workspace, source, schema, tables, detail |
plan_backend | Tested end to end | nothing (counting queries for rule R5) | inferred keys and relationships, each with its rule, ambiguous columns, keyless tables, suggested composite keys, the names read through the synonym table (synonyms), a Mermaid ER diagram; rule R5 counts code and role columns the names left unlinked against the rows (the first 200 distinct values per candidate, at most 20 counting queries; counted_in_rows says what it took and what was left); tables narrows the answer to names or patterns while the plan is still made from the whole schema, detail is auto (full up to 60 tables, then one line per key and relationship without field names or diagram), full or summary, mermaid=false leaves the diagram out; every answer stays under 60 000 characters and says when it was cut | workspace, source, schema, keys, confirmed, tables, detail |
validate_plan | Tested end to end | nothing (counting queries) | checks the plan against the rows: is each key unique and free of NULLs, does every reference find its target (orphan count); one small counting query per key and relationship over the whole table, up to max_items of them (default 60; the summary says when fewer than the plan has were checked); returns counts and a verdict, no row values | workspace, source, schema, keys, confirmed, max_items |
sample_rows | Tested end to end | nothing | the first n rows (at most 20) of one table, long text shortened, to check what a column means; columns that look like personal data come back as *** with the rule, and the source's sensitivity label is named | workspace, source, table, schema, n, show_personal_data |
create_backend | Tested end to end (27 October 2026: update in place of shop_api with confirmed; updated in place again from Lovable on 30 October 2026; consumed live by a Lovable app on 30 October 2026) | creates/updates one item; never deletes | creates the API for GraphQL item with nested relationships, or updates the item of that name in place, keeping the field names it has for the same relationships; refuses an update that would drop relationships the API has unless allow_removals=true, and names the confirmed entries (with field_name and reverse_name) that keep them; returns the endpoint and the two portal steps; no dry run, and it does not run validate_plan | workspace, source, name, schema, writable, keys, confirmed, tables, allow_removals |
describe_backend | Tested end to end | nothing | types, fields and relationships of an existing API for GraphQL item, in the names a query uses, read from its definition (no introspection needed) | workspace, api |
query_graphql | Tested end to end | nothing | runs a read-only GraphQL query against an API (name or id); mutations are refused; with question, tables and source instead of query it builds the query answer_query_draft suggests, runs it, and shows it beside the result | workspace, api, query, variables, question, tables, source, schema |
rayfin_connector | Tested end to end (a draft; creates nothing) | nothing | Rayfin (Fabric Apps) connector entity classes and schema.ts | workspace, source, connector, schema, keys, confirmed, tables, relationships |
ontology_draft | Tested end to end (a draft; creates nothing) | nothing | the plan as a Fabric IQ ontology (preview) draft: summary, binding checklist, a Turtle file for the portal import, the item definition | workspace, source, name, schema, keys, confirmed, tables |
semantic_model_draft | Tested end to end (a draft; creates nothing) | nothing | a Power BI semantic model in TMDL (definition/ files) with suggested measures (the row count of each fact table, sums only where summarizeBy sums, each with its reason) and a calendar marked as the date table when fact tables have date columns: one Direct Lake table per source table on the SQL analytics endpoint, relationships with cardinality and one active path per table pair, keyless tables unrelated, README.generated.md with every decision to check; unit-tested against Microsoft's sample definitions | workspace, source, name, schema, keys, confirmed, tables |
join_path | Tested end to end | nothing | the shortest chain of relationships between two tables with the rule per hop and a ready T-SQL SELECT … JOIN …; equally short paths all listed; with no path, which relationship is missing as a confirmed entry | workspace, source, start, end, schema, keys, confirmed |
data_dictionary | Tested end to end (a draft; creates nothing) | nothing | hand-over documentation in Markdown: tables, columns and types, keys and relationships with rules, keyless and ambiguous items, the ER diagram, an empty Description column; validate=true adds the counts from validate_plan; tables (names or patterns) documents one part of a large schema at a time, with the roles and subject areas of the whole schema, and an answer over 60 000 characters is cut on a line and says so | workspace, source, schema, keys, confirmed, validate, max_items, tables |
dbt_schema | Tested end to end (a draft; creates nothing) | nothing | a dbt schema.yml with sources: unique and not_null on key columns, relationships on single-column relationships, in the syntax of the dbt documentation; composite keys noted as comments; tables takes names or patterns, an answer over 60 000 characters is cut and says so | workspace, source, schema, source_name, keys, confirmed, tables, arguments_block |
domain_draft | Draft only | nothing | proposed domains (candidate data products) from the plan's graph: deterministic Leiden-style communities weighted by each relationship's rule, a name and a reason per table, the relationships that cross domains (interfaces), unassigned tables, and one ODCS v3.2.0 contract per domain; the customer's Fabric admin creates the domains | workspace, source, schema, confirmed, check_rows (inferred keys) |
sap_pack_draft | Draft only | nothing | which tables the SAP pack recognises (with or without a prefix such as sap_), their keys with MANDT, the order-to-cash relationships it applies with the public source of each, what it lists but does not apply (VBFA is many-to-many), what is missing, and the traps; optionally one export: Krusgraph keys/confirmed, Data API builder config, an extraction list with open-mirroring keyColumns, or dbt sources. See SAP on Fabric | workspace, source, schema, keys, confirmed, variant, export |
plan_drift | Tested end to end | nothing | today's plan against an existing API for GraphQL item: new tables and columns, columns the API still maps that are gone, relationships the plan no longer supports, and whether create_backend with that name would change anything | workspace, source, api, schema, keys, confirmed, tables, writable |
create_semantic_model | Available when enabled by the operator; created live on 29 October 2026 (shop_model_live), refreshed and reviewed in the Fabric portal by Gustav the same day; shop_model updated in place from Lovable (experimental) on 30 October 2026 | creates/updates one item; never deletes | creates a Power BI semantic model item from the TMDL draft (Direct Lake on the SQL analytics endpoint) or updates the one of that name in place; dry_run=true (default) returns the parts and the REST call only; needs SemanticModel.ReadWrite.All or Item.ReadWrite.All | workspace, source, name, schema, keys, confirmed, tables, dry_run |
create_report | Experimental; created live on 30 October 2026 (shop_report_live, shop_report), opened and reviewed in the Fabric portal by Gustav the same day | creates one item; never updates or deletes | creates an empty Power BI report item (one blank page, no visuals) bound to an existing semantic model through Fabric's creationPayload; no report definition is sent; a report of that name is left alone and the call answers kind: already_exists; dry_run=true (default) returns the REST call only; needs Report.ReadWrite.All or Item.ReadWrite.All and read permission on the model | workspace, model, name, dry_run |
create_views | Tested end to end as a dry run; creating them: Experimental | creates/alters views in that schema only; never drops | CREATE OR ALTER VIEW in a schema of its own (default krusgraph, created if missing) on the source's SQL analytics endpoint or warehouse: one wide view per fact table with its dimensions, one per header table (vw_orders: each order with its customer and, once orders.ship_to_id is confirmed, its ship-to address), one per hard-to-read relationship; dry_run=true returns the SQL; needs the SQL right to create objects (Contributor) | workspace, source, schema, views_schema, keys, confirmed, dry_run |
create_data_agent | Available when enabled by the operator; tested end to end as a dry run | creates/updates one item and its staging config; never deletes | creates or updates a Fabric data agent through the staging REST API: the plan as instructions, the source as data source with the plan's tables selected, 5–10 question/T-SQL examples, then publishes; columns that look like personal data are left out of the instructions and the examples unless show_personal_data=true (the key stands in); dry_run=true returns instructions, examples and the calls; needs Item.ReadWrite.All | workspace, source, name, schema, keys, confirmed, publish, show_personal_data, dry_run |
create_ontology | Available when enabled by the operator; created live on 28 October 2026 (shop_ontology), reviewed in the Fabric portal on 29 October 2026; first stopped by HTTP 403 FeatureNotAvailable while the ontology was turned off in that tenant's settings | creates/updates one item; never deletes | creates a Fabric IQ ontology (preview) item from the plan or updates the one of that name in place: entity types with keys and properties, relationship types and Direct Lake-style bindings in the item's generation-2 definition; dry_run=true (default) returns the parts and the REST call only; needs Item.ReadWrite.All and Contributor on the workspace (POST /workspaces/{id}/ontologies, updateDefinition; fabric-rest-api-specs read 26 October 2026) | workspace, source, name, schema, keys, confirmed, tables, dry_run |
app_starter | Tested end to end (a draft; creates nothing) | nothing | from an existing API's definition: a Lovable prompt with the data model and main views, a connection description, five GraphQL queries walking the relationships, the portal checklist, and the backend an app needs so that no secret reaches the browser: a Supabase edge function (service principal, client credentials, secrets as Supabase secrets), the frontend helper, and the per-user alternative | workspace, api |
app_readiness | Tested end to end | nothing (one introspection query) | what an app still needs on an existing API: types without a key, types in no relationship, write access (from the definition), whether introspection is on (one introspection query to the endpoint), and "unknown" with the portal path for what the Fabric API cannot read (permissions, the tenant setting for service principals); a next step per item | workspace, api |
analyze_schema | Tested end to end | nothing | the plan as a graph, metadata only (tables and detail as in plan_backend; the summary groups tables by role and keeps the central tables, the areas by size and counts): table roles (fact, dimension, bridge, isolated) with the numbers behind them, the ten most central tables (degree, betweenness, PageRank), subject areas, cycles and table pairs with more than one path, and which relationships can be active at once | workspace, source, schema, keys, confirmed, tables, detail |
lineage | Tested end to end | nothing | which objects in the workspace build on the source's tables: GraphQL APIs (from their definition), semantic models (from their TMDL definition), views on the SQL analytics endpoint (INFORMATION_SCHEMA.VIEW_TABLE_USAGE), data agents (named in their definition, marked as not certain); a graph of tables and objects, the objects per table, the tables used by nothing, the items that could not be read; with table, what a change to it reaches | workspace, source, schema, table |
silver_notebook_draft | Tested end to end (a draft; creates nothing); the notebook ran on a local PySpark 4.0.1, not yet in Fabric | nothing | a Fabric notebook (PySpark) that builds silver tables from a lakehouse's tables: de-duplicated on each table's key (the latest row by order_by wins), every relationship checked with the rows whose reference is missing put in krusgraph_quarantine with the reason, Delta tables written only in silver_schema, each step commented with its rule; re-runnable. The steps and the notebook source | workspace, source, schema, silver_schema, order_by, keys, confirmed, tables |
create_silver_notebook | Experimental; created live on 28 October 2026 (silver_shop), not yet run in Fabric | creates/updates one item; never deletes | creates that notebook in the workspace, attached to the lakehouse, or updates the one of that name; creating runs nothing; dry_run=true (default) returns the notebook and the call; needs Notebook.ReadWrite.All or Item.ReadWrite.All (fabric-rest-api-specs notebook/swagger.json) | workspace, source, name, schema, silver_schema, order_by, keys, confirmed, tables, dry_run |
drift_monitor_draft | Tested end to end (a draft; creates nothing); the notebook ran two nights on a local PySpark, not yet in Fabric | nothing | a notebook and a pipeline that every night read the lakehouse's schema, compare the plan with the last saved one (the plan_drift and lineage logic as a library), save the new plan in krusgraph.plans, and send a short summary to a webhook (Teams or Power Automate) set as a pipeline parameter in Fabric; plus the daily schedule; the notebook installs the library at the tag of the server's version unless library_ref names another tag, a commit or main | workspace, source, schema, name, at, time_zone, library_ref |
create_drift_monitor | Experimental; created live on 28 October 2026 with schedule=false (drift_shop, drift_shop_nightly), not yet run in Fabric; the schedule needs DataPipeline.Execute.All, which the app does not have | creates/updates two items and a schedule; never deletes | creates or updates that notebook and pipeline and adds the daily schedule unless one at that time exists; no secret anywhere; dry_run=true (default) returns the items and the calls; needs Notebook.ReadWrite.All and DataPipeline.ReadWrite.All (or Item.ReadWrite.All), and DataPipeline.Execute.All (or Item.Execute.All) for the schedule | workspace, source, name, schema, at, time_zone, library_ref, schedule, dry_run |
answer_query_draft | Tested end to end (a draft; creates nothing) | nothing | a question in Swedish or English about the given tables as T-SQL over the safest join path (each step with its rule), and with api as GraphQL in that API's field names, or why GraphQL cannot answer it; reads counts, sums, averages, "per"/"för varje" groupings, top N and "latest", and lists what it assumed; runs nothing; columns that look like personal data are left out unless show_personal_data=true (the key stands in) | workspace, source, question, tables, schema, api, keys, confirmed, show_personal_data |
suggest_relationships | Tested end to end | nothing (counting queries) | columns that could point at another table's key but are in no relationship, ranked by name, type and triangular closure, the best check counted against the data (inclusion share, distinct values); each with a ready confirmed entry; suggests only, never applies | workspace, source, schema, keys, confirmed, check |
compare_semantic_model | Available when enabled by the operator; with tmdl: Experimental; live on 27 October 2026 only as far as the model lookup (the demo workspace had no model that day) | nothing | an existing semantic model (name or id) against the plan: relationships the model lacks, ones a rule or the data contradicts (with the rule or the count), other cardinality, filters in both directions, active against inactive, links the plan lacks (with a confirmed entry), columns summed that the summarizeBy rule would not sum, suggested measures it lacks; reads the model's TMDL through Fabric's getDefinition (needs SemanticModel.ReadWrite.All or Item.ReadWrite.All), or tmdl from a PBIP folder or Git, which needs nothing; check_data=true counts against the rows | workspace, source, model, schema, keys, confirmed, check_data, max_items, tmdl |
gold_views_draft | Tested end to end (a draft; creates nothing); the SQL ran on SQLite and a local PySpark 4.0.1, not yet in Fabric | nothing | materialized lake views in Spark SQL for a lakehouse with schemas: one wide view per fact table in gold_schema over the silver tables, joined over the safest many-to-one paths, with CONSTRAINT … CHECK … ON MISMATCH DROP rules for the plan's keys and relationships, each commented with its rule; personal-data columns left out unless show_personal_data=true; the notebook that creates them | workspace, source, schema, silver_schema, gold_schema, keys, confirmed, tables, show_personal_data |
create_gold_views | Experimental; created live on 28 October 2026 (gold_shop), not yet run in Fabric | creates/updates one notebook; never deletes | creates that notebook in the workspace, attached to the lakehouse, or updates the one of that name; the views are created when the notebook runs, and it stops before a source table, a silver table or any table it did not create; dry_run=true (default) returns the views, the notebook and the call; needs Notebook.ReadWrite.All or Item.ReadWrite.All | workspace, source, name, schema, silver_schema, gold_schema, keys, confirmed, tables, show_personal_data, dry_run |
export_item_definitions | Tested end to end (a draft; creates nothing) | nothing | what create_backend, create_semantic_model, create_silver_notebook, create_drift_monitor and create_gold_views would create, as folders in Fabric's Git format (<name>.<type> with .platform and the definition files), plus create_views' T-SQL as a script (Fabric's Git integration does not carry SQL analytics endpoint views) and a README; for your own repository, so that Fabric's Git integration or a deployment pipeline makes the change; calls no Git provider | workspace, source, schema, items, names, keys, confirmed, tables, silver_schema, gold_schema, views_schema, writable, show_personal_data |
review_plan | Tested end to end; reading a file back is unit-tested | nothing (counting queries with validate=true) | the plan with the decisions made about it and its checks as one JSON file for your own repository, plus a short Markdown report and what needs attention: each key and relationship with a review status (proposed, accepted, rejected, open, with a reason) and, apart from it, a check status (not checked, passed, failed, stale); validate=true records validate_plan's counts with the time; previous takes an earlier file, applies its corrections again, lists what changed in the schema and marks checks on changed tables stale; names, types, rules, decisions and counts only, never row values or credentials | workspace, source, schema, keys, confirmed, decisions, previous, validate, tables, max_items |
When a call cannot be completed, the tool answers with three fields instead of a bare failure: error (what happened, in plain words), kind (a stable code such as not_found, no_access, capacity, sign_in, consent, schema_not_found, table_not_found, bad_input, timeout, or rate_limited with retry_after in seconds when an account or organisation makes too many calls in a short time) and hint (what to do next). Tokens, request headers and stack traces never appear in these answers. A query result too large for one answer comes back as valid JSON with every list cut to its first items and a truncated note saying so; page with first:/after for the rest.