Generated banner for Ontology CLI
Generated logo for Ontology CLI

Ontology CLI

MicrosoftOfficialPublished by Microsoft

  • Skill
  • Tool integration
  • Data and AI
  • MIT
  • No issues found

From the author

Manages Microsoft Fabric Ontology items: authors legacy V1 entity/relationship definitions and answers questions for new-experience (V2) Ontologies through ask_ontology. Use for Ontology item operations or grounded questions; V2 authoring/upgrades and V1 queries are unsupported. Power BI data questions use fabriciq, report authoring powerbi-report-cli, and model/DAX changes semantic-model-authoring.
— the description by Microsoft

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The ontology-cli skill provides a specialized interface for interacting with Microsoft Fabric Ontology items. It operates in two distinct, non-convertible modes: an authoring mode for managing legacy V1 entity and relationship definitions, and a consumption mode for querying new-experience (V2) Ontologies. The skill acts as a mode dispatcher, requiring users to read specific reference documentation before executing commands to ensure correct payload generation and state management. It does not support V1-to-V2 upgrades or V2 authoring.

What it does

  • Creates and updates legacy V1 Ontology entity and relationship definitions.
  • Answers natural-language questions about existing new-experience (V2) Ontologies.
  • Generates grounded code or data insights from V2 Ontologies via the Ontology Agent.
  • Manages data bindings for V1 Ontology entity types.
  • Provides a structured workflow for resolving workspace and item identifiers.

When to use it

  • When you need to define or modify the structure of a legacy V1 Ontology.
  • When you need to query data or metadata from a new-experience (V2) Ontology.
  • When you need to generate runnable code based on V2 Ontology rules.
  • When you are working within the Microsoft Fabric ecosystem and require specific Ontology item operations.

Advantages

  • Ensures grounded, validated responses by using the Ontology Agent for V2 queries.
  • Provides a clear separation between legacy authoring and modern consumption workflows.
  • Reduces errors by enforcing mandatory reference reading before command execution.
  • Maintains consistency in Fabric item management through standardized CLI patterns.

Usage examples

“Using the ClinicOperations ontology, how many clinics are there?”
The agent enters consumption mode, verifies the ontology, and queries the data to return the clinic count.
“Create a legacy V1 ontology item with Customer and Order entity types bound to the lakehouse.”
The agent enters authoring mode, prepares the required JSON definition tree, and executes the creation call.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/microsoft/ontology-cli/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip ontology-cli.zip -d .agents/skills

Documentation by Microsoft

Telemetry — MANDATORY. Every api.fabric.microsoft.com call must carry x-ms-fabric-skill: ontology-cli (az rest: --headers "x-ms-fabric-skill=ontology-cli"), including every LRO poll, fabric_lro and retry. Snippets omit it — add it anyway.

CRITICAL NOTES

  1. To find the workspace details (including its ID) from workspace name: list all workspaces and, then, use JMESPath filtering

  2. To find the item details (including its ID) from workspace ID, item type, and item name: list all items of that type in that workspace and, then, use JMESPath filtering

  3. Skill disambiguation: use ontology-cli for operations on an Ontology item and questions grounded in that Ontology. Natural-language data questions over existing Power BI reports/models are fabriciq; report creation, editing, publishing, or rebinding is powerbi-report-cli; semantic-model or DAX authoring is semantic-model-authoring. Naming an Ontology as a report's data source does not move report authoring into this skill.

  4. Consumption runs through the Ontology Agent MCP server, never around it. Do not decode an ontology definition to hand-compose KQL / T-SQL / Spark SQL, and do not delegate ontology data questions to eventhouse-cli / sqldw-cli / spark-cli. That path loses the agent's grounding and validation and is not metered.

  5. Natural-language consumption supports only new-experience (V2) Ontologies. Call tools/list first. If ask_ontology is absent, stop and tell the user that V1 natural-language queries are unsupported and the Ontology must be upgraded or recreated in the new experience outside this skill's authoring flow. Never fall back to search_ontology.

  6. Authoring is legacy V1-only. The JSON EntityTypes/.../definition.json item-definition flow below cannot create, convert, or upgrade a new-experience (V2) Ontology. Do not route a V2 upgrade/recreation request into authoring.

  7. Kusto bindings use the parent Eventhouse item ID, never the KQL database ID. Validate the staged binding against discovered source metadata before presenting an authoring preview; unresolved or mismatched source identities block the write.

Ontology CLI Skill

This skill owns two explicit, non-convertible surfaces: legacy V1 JSON-definition authoring, and read-only questions over existing new-experience (V2) Ontologies through the Ontology Agent MCP endpoint. It does not upgrade V1 items to V2 or author V2 items.

It is a mode dispatcher and contains NO procedures. Pick the mode that matches the request from the table below, then read the matching references/<mode>.md file end to end with your file-reading tool BEFORE issuing a single command. That file holds the endpoints, payload shapes, templates and gotchas; acting without it produces wrong payloads and wrong results.

Mode selection

ModeUse when the request ...Example triggersRead this first
authoringcreates or updates a legacy V1 Ontology's JSON entity/relationship definitions or data bindings; V2 creation/upgrade is out of scopecreate legacy ontology item, bind V1 entity type, add V1 relationship type, update legacy ontology definitionreferences/authoring.md
consumptionasks a question about an existing new-experience (V2) Ontology -- its data, entities, or rules -- or wants grounded runnable code generated from ithow many clinics are there, which treatment rooms are busiest, what entities exist, list the ontology rules, generate KQL from this ontologyreferences/consumption.md

Consumption sub-references (read directly, not through chained links):

Mode boundary rule

consumption is read-only. Any definition write goes through the authoring mode's preview-and-confirm flow -- never call updateDefinition from a consumption request.

If a request genuinely spans modes, handle them one at a time and read each reference before you start that part. If the mode is ambiguous after reading this table, ask one short clarifying question instead of guessing.

Terminal write -- the step you must not skip

Reading the reference and planning the change is NOT completing the task. Each mutating mode ends with one state-changing call. If you did not issue it, nothing was persisted -- say so explicitly rather than reporting success.

ModeTerminal write
authoringcreateItem (POST /v1/workspaces/{ws}/items) to create a legacy V1 Ontology, then POST .../updateDefinition to persist entity types, relationships and bindings. This cannot create or upgrade V2.
consumptionnone -- this mode is read-only

Before you report the task done, confirm the terminal call returned success and, where the reference documents a readback, read the artefact back to prove the change landed.

Shared essentials (all modes)

Resolve the workspace and item first; every mode depends on it.

TaskReferenceNotes
Finding Workspaces and Items in FabricCOMMON-CLI.mdMandatory -- read before resolving any workspace or item id
Catalog SearchCOMMON-CORE.mdRequest/response shape, Catalog.Read.All scope, 24 h indexing delay
Pagination PatternCOMMON-CLI.mdCatalog Search and item listings both page via continuationToken
Fabric Topology & Key ConceptsCOMMON-CORE.mdItem types, workspaces, capacities
Environment URLsCOMMON-CORE.mdSovereign / non-public cloud hosts
Authentication & Token AcquisitionCOMMON-CORE.mdWrong audience = 401; read before any auth issue
Authentication RecipesCOMMON-CLI.mdaz login flows and token acquisition
Core Control-Plane REST APIsCOMMON-CORE.mdPagination, LRO polling, rate limiting
Gotchas & TroubleshootingCOMMON-CLI.mdaz rest audience, shell escaping, token expiry

Rules

MUST
  • Select exactly one mode from the table above before doing anything else.

  • Read references/<mode>.md end to end, as your FIRST tool call, before the first command of that mode. Read it ONCE, in a single full read: do not re-open it, do not grep it again, and do not page through it. You already have it.

  • Apply the same read-once discipline to every other file you load, including nested references/<mode>/*.md sub-references and shared common/*.md files: open only the ones you actually need, read each ONCE end to end, and never grep or re-open one you already loaded.

  • Resolve workspace and item ids by listing and filtering, never by guessing a GUID.

  • In consumption, call tools/list before the first tools/call. Continue only when ask_ontology is present; otherwise report that V1 natural-language consumption is unsupported and stop without calling another ontology tool.

  • Announce a mode switch explicitly when the request crosses a boundary.

  • Treat the reference as instructions, never as the deliverable. After reading it, RUN the documented commands against the live workspace and report the real results. Quoting what the reference says instead of executing it does not answer the request.

PREFER
  • The narrowest mode that satisfies the request.

  • Reading exactly ONE mode reference. Load a second only when the request genuinely spans modes, and say so before you do.

  • Reporting the mode you chose in your first response so the user can correct you.

AVOID
  • Acting from this dispatcher alone -- it intentionally omits the operational detail.

  • Answering with a summary of the reference instead of executing it.

  • Re-reading or re-grepping a reference you already loaded; it costs turns and tokens.

  • Mutating anything while in a read-only mode.

  • Answering an ontology data question with a hand-composed source query instead of the Ontology Agent MCP (see CRITICAL NOTE 4).

  • Loading a different skill for work this family already owns (see CRITICAL NOTES 3).

Examples

User requestModeReference to read
"Using the ClinicOperations ontology, how many clinics are there?"consumptionreferences/consumption.md
"Create a legacy V1 ontology item with Customer and Order entity types bound to the lakehouse."authoringreferences/authoring.md
"Upgrade this V1 ontology to the new V2 experience."out of scopeExplain that V2 upgrade/recreation is unavailable through this skill's authoring flow
"What entity types exist in the Sales ontology and how are they bound?"consumptionreferences/consumption.md
"Generate Eventhouse-runnable KQL for appointments per practitioner from this ontology."consumptionreferences/consumption.md

Files

references/authoring/ONTOLOGY-AUTHORING-CORE.md

ONTOLOGY-AUTHORING-CORE.md — Fabric IQ Ontology (preview) Authoring Reference

Purpose: Shared reference for authoring Fabric IQ Ontology (preview) items via the Fabric item-definition REST API. Covers the definition tree (entity types, data bindings, relationship types, contextualizations), schema constraints, value-type mappings, supported source kinds, and platform limitations. Not a tutorial — assumes familiarity with the Fabric control-plane REST API and base64-encoded item definitions. Focus is the JSON shapes and rules the skill must generate correctly. Preview: The Ontology item type is in public preview. Wire format and limitations may change; validate against the latest Microsoft docs before production use.


Capability Matrix

CapabilityLakehouse (OneLake)Eventhouse (Kusto)
Entity type creation✅✅
Entity type static binding✅❌ (OneLake only)
Entity type time-series binding✅✅
Multiple static bindings per entity type❌ (at most one)n/a
Multiple time-series bindings per entity type✅✅
Relationship type creation✅✅
Relationship contextualization✅ (Lakehouse linking table)❌
Ontology-scoped uniqueness for entity / property / relationship IDs✅ required✅ required
Refresh on upstream data changesManual refresh requiredManual refresh required

Definition Tree

All authoring flows produce or mutate a tree of JSON files carried as parts[] inside the Fabric item-definition envelope (payloadType = "InlineBase64").

Definition part pathRequiredShape
.platform✅{"metadata":{"type":"Ontology","displayName":"<name>"}}
definition.json✅{} (empty object)
EntityTypes/{entityTypeId}/definition.jsonper entity typeEntityType file
EntityTypes/{entityTypeId}/DataBindings/{guid}.jsonper bindingDataBinding file
EntityTypes/{entityTypeId}/Documents/{name}.jsonoptionalDocument link
EntityTypes/{entityTypeId}/Overviews/definition.jsonoptionalWidgets layout
EntityTypes/{entityTypeId}/ResourceLinks/definition.jsonoptionalPower BI / item links
RelationshipTypes/{relTypeId}/definition.jsonper relationship typeRelationshipType file
RelationshipTypes/{relTypeId}/Contextualizations/{guid}.jsonper contextualizationContextualization file

{entityTypeId} and {relTypeId} are positive 64-bit integers (BigInt) that are unique across the ontology. Binding and contextualization IDs are GUIDs.


EntityType file — EntityTypes/{id}/definition.json

PropertyTypeRequiredNotes
idBigInt✅Positive 64-bit integer, unique across the ontology
namespacestring✅Allowed value: usertypes
baseEntityTypeIdBigInt❌ID of base entity type (inheritance is limited; treat as null)
namestring✅Regex ^[a-zA-Z][a-zA-Z0-9_-]{0,127}$. Portal UI additionally limits entity type names to 1–26 alphanumeric/hyphen/underscore and requires starting and ending with an alphanumeric character.
entityIdPartsBigInt[]❌Property IDs forming the entity key. Must all be valueType String or BigInt (integer)
displayNamePropertyIdBigInt❌Property ID used as the instance display name
namespaceTypestring✅Allowed value: Custom
visibilitystring❌Allowed value: Visible
propertiesEntityTypeProperty[]❌Static / non-timeseries properties
timeseriesPropertiesEntityTypeProperty[]❌Time-series properties (must include a timestamp property bound via timestampColumnName)
untypedPropertiesUntypedEntityTypeProperty[]❌Properties whose valueType is Any. Use only when the source column type cannot be mapped to a concrete valueType; downstream consumers must treat the value as opaque
EntityTypeProperty
PropertyTypeRequiredNotes
idBigInt✅Positive 64-bit integer, unique across the ontology
namestring✅Regex ^[a-zA-Z][a-zA-Z0-9_-]{0,127}$. Portal custom property names additionally limited to 1–26 alphanumeric/hyphen/underscore. Property names are unique across the ontology — two entity types cannot share a property name unless both use the same valueType
redefinesstring❌Pointer to inherited property being redefined
baseTypeNamespaceTypestring❌Namespace of the base entity type
valueTypestring✅Allowed values (exact): String, Boolean, DateTime, Object, BigInt, Double
UntypedEntityTypeProperty

Same shape as EntityTypeProperty except valueType is the literal string Any. Untyped properties cannot back keys (must not appear in entityIdParts) and are not safely queryable as scalars.

Value-type mapping from source

Use this table when picking valueType based on the source column type:

Ontology valueTypeLakehouse column typesEventhouse column types
BigInt (integer)tinyint, smallint, bigint, integer, long, shortint, long
Booleanbooleanbool
DateTimedatetime, date, timestampdatetime
Doubledouble, decimal, floatdecimal, real
Stringchar, decimal(p,s), string, array, binary, binary16, byte, map, object, struct, timestampint64, timestamp_ntzdynamic, string, guid, timespan

Timestamp for a time-series binding must map to DateTime (source of type datetime, date, or timestamp).

Entity type key (entityIdParts) may only reference properties whose valueType is String or BigInt.


DataBinding file — EntityTypes/{id}/DataBindings/{guid}.json

PropertyTypeRequiredNotes
idGuid✅Unique per binding
dataBindingConfigurationDataBindingConfiguration✅See below
DataBindingConfiguration
PropertyTypeRequiredNotes
dataBindingTypestring✅NonTimeSeries or TimeSeries
timestampColumnNamestringonly for TimeSeriesSource column name carrying the timestamp
propertyBindingsEntityTypePropertyBinding[]❌Source-column → property-ID mappings
sourceTablePropertiesLakehouse…Properties or Eventhouse…Properties✅Eventhouse sources are allowed only when dataBindingType is TimeSeries
EntityTypePropertyBinding
PropertyTypeRequiredNotes
sourceColumnNamestring✅Column in the source table
targetPropertyIdstring✅Property ID inside the entity type (matches a property from properties[] or timeseriesProperties[])
LakehouseTableDataBindingProperties
PropertyTypeRequiredNotes
sourceTypestring✅LakehouseTable
workspaceIdGuid✅Workspace containing the lakehouse
itemIdGuid✅Lakehouse ArtifactId
sourceTableNamestring✅Table name
sourceSchemastring❌Typically dbo
EventhouseTableDataBindingProperties
PropertyTypeRequiredNotes
sourceTypestring✅KustoTable
workspaceIdGuid✅Workspace containing the eventhouse
itemIdGuid✅Parent Eventhouse ArtifactId (properties.parentEventhouseItemId on the KQL database), not the KQL database id
clusterUristring✅Kusto cluster URL
databaseNamestring✅Database name
sourceTableNamestring✅Source table in the cluster

Before previewing or writing, compare the decoded staged KustoTable.itemId with the discovered properties.parentEventhouseItemId. A missing parent ID or a mismatch blocks the write; a valid GUID alone does not establish source identity.

Binding rules
  • Each entity type has at most one NonTimeSeries (static) binding sourced from a lakehouse table.

  • Entity types support multiple TimeSeries bindings across lakehouse and eventhouse sources.

  • Static bindings must exist before time-series bindings — the time-series binding needs a key property populated by static data.

  • Lakehouse data sources must be managed tables (same OneLake directory as the lakehouse) — external tables are not supported.

  • Lakehouses with OneLake security enabled cannot be used as data sources.

  • Delta tables with column mapping enabled are not supported. Column mapping is enabled automatically on tables with column names that contain ,, ;, {, }, (, ), \n, \t, =, or space, and on delta tables used for import-mode semantic models.

  • Renaming a lakehouse source table after bindings are created can break the preview experience.

DataBinding examples

Non-timeseries (static) — lakehouse source:

{
  "id": "66253a71-c26f-4c9d-877f-3af5632a4be2",
  "dataBindingConfiguration": {
    "dataBindingType": "NonTimeSeries",
    "propertyBindings": [
      { "sourceColumnName": "DisplayName",  "targetPropertyId": "3117068036374594013" },
      { "sourceColumnName": "Manufacturer", "targetPropertyId": "3117068031950000331" }
    ],
    "sourceTableProperties": {
      "sourceType": "LakehouseTable",
      "workspaceId": "580f410e-733d-43bd-8a87-be12b536f7ff",
      "itemId": "d0d863bc-48e1-45b2-8f4b-54795c97ba71",
      "sourceTableName": "equipment1nontimeseries",
      "sourceSchema": "dbo"
    }
  }
}

Time-series — lakehouse source (note: static binding must already exist on this entity type):

{
  "id": "39a3889b-77e4-4851-8960-e3b779a5d9ba",
  "dataBindingConfiguration": {
    "dataBindingType": "TimeSeries",
    "timestampColumnName": "PreciseTimestamp",
    "propertyBindings": [
      { "sourceColumnName": "PreciseTimestamp", "targetPropertyId": "3114584981368796953" },
      { "sourceColumnName": "Name",             "targetPropertyId": "3114584979743320934" },
      { "sourceColumnName": "AltitudeFt",      "targetPropertyId": "3114584977562679672" },
      { "sourceColumnName": "Name",             "targetPropertyId": "3117068036374594013" }
    ],
    "sourceTableProperties": {
      "sourceType": "LakehouseTable",
      "workspaceId": "580f410e-733d-43bd-8a87-be12b536f7ff",
      "itemId": "d0d863bc-48e1-45b2-8f4b-54795c97ba71",
      "sourceTableName": "equipment1timeseries",
      "sourceSchema": "dbo"
    }
  }
}

Time-series — eventhouse source:

{
  "id": "d8b4e4f5-12aa-4db7-b5c3-0f8b1f2ad7c1",
  "dataBindingConfiguration": {
    "dataBindingType": "TimeSeries",
    "timestampColumnName": "PreciseTimestamp",
    "propertyBindings": [
      { "sourceColumnName": "PreciseTimestamp", "targetPropertyId": "3114584981368796953" },
      { "sourceColumnName": "AltitudeFt",      "targetPropertyId": "3114584977562679672" }
    ],
    "sourceTableProperties": {
      "sourceType": "KustoTable",
      "workspaceId": "580f410e-733d-43bd-8a87-be12b536f7ff",
      "itemId": "a1f22aaa-b5c2-4d12-a3d4-8821c50a90cd",
      "clusterUri": "https://trd-xxxx.z0.kusto.fabric.microsoft.com",
      "databaseName": "Zava_Telemetry",
      "sourceTableName": "equipment_timeseries"
    }
  }
}

RelationshipType file — RelationshipTypes/{id}/definition.json

PropertyTypeRequiredNotes
idBigInt✅Positive 64-bit integer, unique across the ontology
namespacestring✅usertypes
namestring✅Regex ^[a-zA-Z][a-zA-Z0-9_-]{0,127}$
namespaceTypestring✅Custom
sourceRelationshipEnd✅{ "entityTypeId": "<id>" }
targetRelationshipEnd✅{ "entityTypeId": "<id>" }

Rules:

  • source.entityTypeId and target.entityTypeId must reference entity types that already exist in the ontology parts list and must be distinct from each other.

  • The source data for the relationship must be a OneLake lakehouse table that contains keys for both the source and target entity types.

Example:

{
  "namespace": "usertypes",
  "id": "3110733855942077719",
  "name": "contains",
  "namespaceType": "Custom",
  "source": { "entityTypeId": "8813598896083" },
  "target": { "entityTypeId": "159990879905613" }
}

Contextualization file — RelationshipTypes/{id}/Contextualizations/{guid}.json

PropertyTypeRequiredNotes
idGuid✅Unique per contextualization
dataBindingTableLakehouseTableDataBindingProperties✅The link table (lakehouse only)
sourceKeyRefBindingsEntityTypePropertyBinding[]✅Columns in the link table that form the source entity's key
targetKeyRefBindingsEntityTypePropertyBinding[]✅Columns in the link table that form the target entity's key

Rules:

  • Each targetPropertyId in sourceKeyRefBindings must be in the source entity type's entityIdParts. Same for targetKeyRefBindings and the target entity type.

  • The link table must physically contain both sets of key columns — confirm with the data owner before generating.

Example:

{
  "id": "62bbbf52-39a4-47ed-b7bf-651debaca6ab",
  "dataBindingTable": {
    "sourceType": "LakehouseTable",
    "workspaceId": "580f410e-733d-43bd-8a87-be12b536f7ff",
    "itemId": "d0d863bc-48e1-45b2-8f4b-54795c97ba71",
    "sourceTableName": "relationshiptable",
    "sourceSchema": "dbo"
  },
  "sourceKeyRefBindings": [
    { "sourceColumnName": "Equipment1Name", "targetPropertyId": "3117068036374594013" }
  ],
  "targetKeyRefBindings": [
    { "sourceColumnName": "Equipment2Name", "targetPropertyId": "3113493256674129151" }
  ]
}

Optional parts

Document — EntityTypes/{id}/Documents/document{n}.json
{ "displayText": "Install guide", "url": "https://example.com/guide" }

displayText is optional; url is required.

Overviews — EntityTypes/{id}/Overviews/definition.json

Widgets: lineChart, barChart, file, graph, liveMap. Settings type: fixedTime or customTime. interval: OneMinute, FiveMinutes, FifteenMinutes, ThirtyMinutes, OneHour, SixHours, TwelveHours, OneDay. aggregation: Average, Count, Maximum, Minimum, Sum, LastKnownValue. fixedTimeRange: Last30Minutes, Last1Hour, Last4Hours, Last12Hours, Last24Hours, Last48Hours, Last3Days, Last7Days, Last30Days.

{ "resourceLinks": [ { "type": "PowerBIReport", "workspaceId": "<ws>", "itemId": "<item>" } ] }

type allowed value: PowerBIReport.


Item-management contract

OperationHTTPURLNotes
Create ontology itemPOST/v1/workspaces/{ws}/itemsBody: {"displayName","type":"Ontology","definition":{"parts":[...]}}. Long-running; returns 202 with an x-ms-operation-id header — poll /v1/operations/{operationId} on api.fabric.microsoft.com (not the Location redirect host). Creation can also be done with only .platform + empty definition.json, then populate via updateDefinition.
Get ontology definitionPOST/v1/workspaces/{ws}/items/{id}/getDefinitionLong-running. 200 returns the envelope directly. 202 carries x-ms-operation-id; poll /v1/operations/{operationId} until Succeeded, then GET /v1/operations/{operationId}/result to retrieve the envelope.
Update ontology definitionPOST/v1/workspaces/{ws}/items/{id}/updateDefinitionLong-running. Replaces all included parts — always fetch, mutate locally, then send the full desired tree. To rename or change .platform, add ?updateMetadata=true.
List items of type OntologyGET/v1/workspaces/{ws}/items?type=OntologyUsed to resolve the ontology itemId by name.

All calls target https://api.fabric.microsoft.com and require the https://api.fabric.microsoft.com token audience.


Platform limitations (preview)

  • Names (entity type, relationship type, property) are globally scoped inside the ontology. A relationship type name must be unique within the ontology item; property names must be unique across entity types unless both share the same valueType.

  • Column mapping on delta tables breaks bindings (see binding rules).

  • OneLake security on a lakehouse breaks bindings.

  • External tables are not supported as binding sources.

  • Upstream data changes require a manual graph-model refresh before instance counts change in the preview experience.

  • Object / nested JSON properties are not fully queryable like scalar properties — treat as opaque payload unless the consumer explicitly targets Fabric Graph/GraphQL.

  • The Ontology item is in public preview; features and the above schema may change.


ID generation guidance

  • Entity type / property / relationship type IDs must be positive 64-bit integers unique across the ontology. Generate 15–18 digit random positive integers and persist the name → id map in source control so re-runs reuse the same IDs.

  • Data binding and contextualization IDs are GUIDs; persist them too so updateDefinition doesn't orphan bindings.

  • Never reuse an ID for a different concept. Never change the ID of an existing concept — add a new one and delete the old one if needed.


Authoritative upstream references

  • Ontology overview and core concepts — Fabric IQ Ontology (preview) docs on Microsoft Learn.

  • Entity types, data binding, and relationship types how-to — Fabric IQ Ontology (preview) how-to articles.

  • Item definition JSON schema — Ontology definition article under Fabric REST API item management.

  • Create / Update / Get Item Definition — Fabric REST API core item management endpoints.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs an MCP server

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Microsoft
Publisher
Microsoft (Official)
Source
microsoft/skills-for-fabric · skills/ontology-cli · commit f8fac11
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Also distributed in
microsoft/skills-for-fabric

AutoGineer is not affiliated with or endorsed by Microsoft.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download ontology-cli.zip