Activator CLI

MicrosoftOfficialPublished by Microsoft

Skill
Tool integration
Data and AI
MIT
Low risk

From the author

Creates and inspects Fabric Activator (Reflex) alerts: rules, their data sources, conditions, and the Teams or email action they fire, plus decoding an existing ReflexEntities definition. Choose it whenever someone wants to be told, or something done, when values cross a threshold. The pipeline delivering those values is eventstream-cli.

— the description by Microsoft

AutoGineer summary

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

The activator-cli skill provides a structured interface for interacting with Microsoft Fabric Activator (Reflex) items. It acts as a mode-based dispatcher that separates authoring tasks (creating, updating, or deleting alert rules, sources, and actions) from consumption tasks (listing, inspecting, and decoding existing definitions). The skill enforces strict validation gates for data sources and requires specific handling of JSON payloads to ensure compatibility with Fabric APIs.

What it does

Creates and configures Activator alert rules and data sources.
Defines automated actions including Teams notifications, emails, and Fabric item invocations.
Inspects and decodes existing ReflexEntities definitions.
Lists and filters workspaces and Activator items for management.
Validates data sources and signals before rule authoring.
Manages the lifecycle of Reflex items through REST API operations.

When to use it

When you need to set up automated alerts based on data thresholds.
When you need to inspect or audit existing alert rules and their configurations.
When you need to integrate Fabric Activator with Teams or email for operational notifications.
When you need to programmatically manage Reflex item definitions.

Advantages

Provides a clear separation between read-only inspection and state-changing authoring.
Includes built-in validation gates to prevent invalid rule creation.
Supports complex alert logic including transition-based detectors.
Standardizes the handling of Fabric API authentication and telemetry.

Usage examples

“Create an Activator named sales_alert in my workspace.”: The agent will switch to authoring mode, read the authoring reference, and execute the POST request to create the Reflex item.
“Show me all Activators in this workspace.”: The agent will use consumption mode to list and filter the Reflex items within the specified workspace.
“Notify me on Teams when the average temperature goes above 30.”: The agent will validate the temperature source, configure the rule condition, and set up the TeamsMessage action.
“What rule and action are behind SkillsTestActivator?”: The agent will use consumption mode to retrieve and decode the ReflexEntities definition for the specified item.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/microsoft/activator-cli/download

Unzip it into the cross-client skills folder of your project:

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

Documentation by Microsoft

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

CRITICAL NOTES
To find the workspace details (including its ID) from workspace name: list all workspaces and, then, use JMESPath filtering
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
Skill disambiguation: use activator-cli for every Fabric Activator / Reflex item — both authoring alert rules and inspecting existing alerts. The streaming topology that feeds an alert belongs to eventstream-cli, the KQL database behind it to eventhouse-cli, and Power BI report questions to fabriciq.

Fabric Activator (Reflex) — CLI Skill

This one skill owns Fabric Activator / Reflex items: alert rules, their sources, their actions, and the ReflexEntities.json definition that holds them.

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, entity schemas, templates and gotchas; acting without it produces invalid ReflexEntities.json payloads and 400s.

The reference is needed to act, not to ask. If the request is under-specified and your next message will be a clarifying question with no Fabric call in it, ask it now and read the reference when you go on to act.

Mode selection

Mode	Use when the request ...	Example triggers	Read this first
`authoring`	creates, updates, configures or deletes an Activator item, rule, source or action	create an alert, create an activator, create a reflex, notify me when, let me know when, take action when, send me an email when, send a teams message when, run a pipeline when, update an alert, delete an alert	references/authoring.md
`consumption`	lists, inspects, decodes or explains existing Activators, rules, sources or actions	show my alerts, what alerts do I have, list activators, inspect this alert, show me the rule, show me the source, get reflex definition, why does this alert fire	references/consumption.md

Mode boundary rule

consumption is read-only. A request to create, update, configure or delete an Activator item, rule, source or action requires authoring: say so, read references/authoring.md, then proceed.

A pure GET / explain request stays in consumption — do not switch to authoring and do not mutate anything to answer it.

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, decoding a definition and assembling entities is NOT completing the task. Authoring ends with one state-changing call. If you did not issue it, nothing was persisted — say so explicitly rather than reporting success.

Mode	Terminal write
`authoring`	`POST /v1/workspaces/{ws}/reflexes` to create the item, `POST /v1/workspaces/{ws}/reflexes/{id}/updateDefinition` to persist rules, sources and actions, or `DELETE /v1/workspaces/{ws}/reflexes/{id}` to remove it. Building, stringifying or base64-encoding `ReflexEntities.json` is not the write.
`consumption`	none — this mode is read-only

Before you report an authoring task done, confirm the terminal call returned an explicit success (HTTP 200/201, or a terminal LRO success for a 202), then read the definition back where the mode reference documents a readback. Power BI sources are the exception: public ALM export can reject an artifact that imported successfully, so an empty or unavailable readback is not proof the write failed — report the updateDefinition result and the readback limitation separately, per references/authoring/powerbi-source.md.

Source validation gate (authoring only)

Before authoring any rule that references a signal, confirm the source is real: resolve it in the requested workspace only, validate that the requested column/field/property exists on it, and observe at least one representative row, event or sample carrying that signal.

Schema-only, zero-row, non-emitting or stale evidence is missing source data. When the source is missing, stop and ask which source and fields provide the signal — do not create a Reflex and do not call updateDefinition on an unrelated existing Activator or Eventstream to force-fit the request, and state plainly that no Activator / Reflex / Eventstream was created or updated. The only exception is an explicit instruction to author against a future / not-yet-emitting source, which you must state as an assumption.

Everything you need to run this gate is on this page. When the request already lacks the source mapping, threshold, recipients or action target, ask for them first — do not read references/authoring.md, and do not call a Fabric API, just to discover that the request is under-specified.

Shared essentials (all modes)

Resolve the workspace and the Activator item first; every mode depends on it — list and filter by display name exactly as CRITICAL NOTES 1 and 2 describe. That recipe is self-contained and is all you need to start.

The table below is optional background living in the shared common/ docs. Open a row only when you actually need that detail. If common/ is not present in your environment, say so in one line and continue with the mode reference — never glob, list or search the filesystem looking for it.

Task	Reference	Notes
Finding Workspaces and Items in Fabric	COMMON-CLI.md	Pagination and JMESPath filtering detail
Fabric Topology & Key Concepts	COMMON-CORE.md	Item types, workspaces, capacities
Authentication & Token Acquisition	COMMON-CORE.md	Wrong audience = 401; read before any auth issue
Authentication Recipes	COMMON-CLI.md	`az login` flows and token acquisition
Core Control-Plane REST APIs	COMMON-CORE.md	Pagination, LRO polling, rate limiting
Fabric Item Definitions	ITEM-DEFINITIONS-CORE.md	Base64-encoded `parts` structure
Gotchas & Troubleshooting	COMMON-CLI.md	`az rest` audience, shell escaping, token expiry

Activator uses the reflexes collection, not the generic items collection: /v1/workspaces/{workspaceId}/reflexes[/{reflexId}].

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. A reply that only asks a clarifying question, and issues no Fabric call, does not need it yet.
Pass --resource https://api.fabric.microsoft.com on every az rest call — without it the token audience is wrong and the call returns 401.
Call getDefinition as a POST with --body '{}', then Base64-decode the ReflexEntities.json part before inspecting it; a GET returns 405 and an omitted body can return 411.
Poll the Location header when create, getDefinition or updateDefinition returns 202.
Resolve workspace and Activator ids by listing and filtering, never by guessing a GUID.
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.
In authoring, clear the source validation gate before you author a rule, and build ReflexEntities.json with Python json.dumps() — PowerShell's ConvertTo-Json corrupts the nested JSON strings that definition.instance requires.

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.
Read-modify-write over full replacement in authoring: get the current definition, modify the entity array, then update.
Transition-based detectors (NumberBecomes, NumberEntersOrLeavesRange, LogicalBecomes) over steady-state conditions in authoring, unless the user explicitly asks for repeated firing while the value stays in the triggered state.
A summary view before individual entities in consumption: give the high-level picture, then drill in.
Offering an alert when earlier work in this session surfaced a timely operational signal — a spike, failure, anomaly, SLA risk or capacity constraint — rather than waiting to be asked. Ask once, and author nothing until the user agrees.

AVOID

Acting from this dispatcher alone — it intentionally omits the entity schemas and templates.
Answering with a summary of the reference instead of executing it.
Mutating anything while in the read-only consumption mode, including "just to check".
Hardcoded workspace or item ids in either mode — always resolve dynamically.
Globbing, listing or shell-searching the filesystem for the common/ docs. They are optional background; if a link does not resolve, note it in one line and carry on.
Building the Eventstream topology that feeds an alert here; that is eventstream-cli. Querying the KQL data behind an alert is eventhouse-cli.
Loading a different skill for work this skill already owns (see CRITICAL NOTES 3).

Examples

User request	Mode	Reference to read
"Create an Activator named eval_smoke_activator in my workspace."	`authoring`	references/authoring.md
"Notify me on Teams when the average temperature goes above 30."	`authoring`	references/authoring.md
"Delete the alert that emails me about failed pipeline runs."	`authoring`	references/authoring.md
"Show me all Activators in this workspace."	`consumption`	references/consumption.md
"What rule and action are behind SkillsTestActivator?"	`consumption`	references/consumption.md
"Decode this Reflex definition and explain the Power BI source."	`consumption`	references/consumption.md

Files

ATTRIBUTION.mdAdded by AutoGineer871 B
LICENSELicence file added by AutoGineer1.1 KiB
SKILL.md11.3 KiB
apm.yml413 B
references/authoring.md31.0 KiB
references/authoring/action-types.md19.9 KiB
references/authoring/dtb-source.md7.6 KiB
references/authoring/eventstream-source.md4.9 KiB
references/authoring/kql-source.md8.8 KiB
references/authoring/powerbi-source.md16.8 KiB
references/authoring/real-time-hub-source.md4.0 KiB
references/authoring/rule-conditions.md23.8 KiB
references/authoring/source-types.md10.5 KiB
references/consumption.md17.3 KiB

references/consumption.md

activator-cli consumption mode — Read-Only Activator Exploration via CLI

Task	Reference	Notes
Finding Workspaces and Items in Fabric	COMMON-CLI.md § Finding Workspaces and Items in Fabric	Optional background — workspace/item ID resolution detail; skip if `common/` is unavailable
Fabric Topology & Key Concepts	COMMON-CORE.md § Fabric Topology & Key Concepts
Authentication & Token Acquisition	COMMON-CORE.md § Authentication & Token Acquisition	Wrong audience = 401
Core Control-Plane REST APIs	COMMON-CORE.md § Core Control-Plane REST APIs
Long-Running Operations (LRO)	COMMON-CORE.md § Long-Running Operations (LRO)	`getDefinition` may return 202
Rate Limiting & Throttling	COMMON-CORE.md § Rate Limiting & Throttling
Fabric Item Definitions	ITEM-DEFINITIONS-CORE.md § Definition Envelope	Base64 payload structure
Authentication Recipes	COMMON-CLI.md § Authentication Recipes	`az login` flows
Fabric Control-Plane API via `az rest`	COMMON-CLI.md § Fabric Control-Plane API via az rest	Always pass `--resource https://api.fabric.microsoft.com`
LRO Pattern	COMMON-CLI.md § Long-Running Operations (LRO) Pattern
Pagination Pattern	COMMON-CLI.md § Pagination Pattern
Tool Stack	Consumption mode § Tool Stack
Connection	Consumption mode § Connection
Listing Activator Items	Consumption mode § Listing Activator Items
Inspecting a Single Activator	Consumption mode § Inspecting a Single Activator
Reading the Definition	Consumption mode § Reading the Definition
Exploring Rules, Sources, and Actions	Consumption mode § Exploring Rules, Sources, and Actions
Inspecting Power BI Sources	Consumption mode § Inspecting Power BI Sources	`powerBiSource-v1`, stored query JSON, `metricDefinition`, report/model lineage
Must / Prefer / Avoid	Consumption mode § Must / Prefer / Avoid
Examples	Consumption mode § Examples

Tool Stack

Tool	Purpose	Install
az cli	Fabric REST API calls for reading Activator items and definitions	`winget install Microsoft.AzureCLI`
jq	JSON processing, Base64 decoding, definition inspection	`winget install jqlang.jq`

Connection

Use the shared authentication guidance in COMMON-CLI.md § Authentication Recipes. Resolve workspace and item IDs per COMMON-CLI.md § Finding Workspaces and Items in Fabric. Examples below assume WS_ID and REFLEX_ID are already resolved.

Listing Activator Items

List All Activators in a Workspace

az rest --method GET \
  --url "https://api.fabric.microsoft.com/v1/workspaces/${WS_ID}/reflexes" \
  --resource "https://api.fabric.microsoft.com" \
  | jq '.value[] | {id, displayName, description}'

Required scopes: Workspace.Read.All or Workspace.ReadWrite.All

Paginated Listing

For workspaces with many items, follow the continuationUri returned in each response:

NEXT_URL="https://api.fabric.microsoft.com/v1/workspaces/${WS_ID}/reflexes"
while [ -n "$NEXT_URL" ]; do
  RESPONSE=$(az rest --method GET \
    --url "$NEXT_URL" \
    --resource "https://api.fabric.microsoft.com")
  echo "$RESPONSE" | jq '.value[] | {id, displayName, description}'
  NEXT_URL=$(echo "$RESPONSE" | jq -r '.continuationUri // empty')
done

Filter by Folder

az rest --method GET \
  --url "https://api.fabric.microsoft.com/v1/workspaces/${WS_ID}/reflexes?recursive=true&rootFolderId=${FOLDER_ID}" \
  --resource "https://api.fabric.microsoft.com" \
  | jq '.value[] | {id, displayName}'

Inspecting a Single Activator

az rest --method GET \
  --url "https://api.fabric.microsoft.com/v1/workspaces/${WS_ID}/reflexes/${REFLEX_ID}" \
  --resource "https://api.fabric.microsoft.com" \
  | jq '{id, displayName, description, type, workspaceId}'

Reading the Definition

getDefinition is a POST (not GET), requires ReadWrite scopes (Reflex.ReadWrite.All or Item.ReadWrite.All) even for read-only inspection, and may return 202 LRO. Use the fabric_lro helper from COMMON-CLI.md § Long-Running Operations (LRO) Pattern so 202 responses can be polled via the Location header before decoding.

Decode the Full Definition

DEFINITION=$(fabric_lro POST \
  "https://api.fabric.microsoft.com/v1/workspaces/${WS_ID}/reflexes/${REFLEX_ID}/getDefinition" \
  '{}')

echo "$DEFINITION" \
  | jq '.definition.parts[] | select(.path=="ReflexEntities.json") | .payload' -r \
  | base64 -d | jq .

Save Definition to File

DEFINITION=$(fabric_lro POST \
  "https://api.fabric.microsoft.com/v1/workspaces/${WS_ID}/reflexes/${REFLEX_ID}/getDefinition" \
  '{}')

echo "$DEFINITION" \
  | jq '.definition.parts[] | select(.path=="ReflexEntities.json") | .payload' -r \
  | base64 -d | jq . > reflex-entities.json

Exploring Rules, Sources, and Actions

Once you have the decoded ReflexEntities.json, use jq to extract specific components.

List All Entity Types

cat reflex-entities.json | jq '[.[] | .type] | sort | group_by(.) | map({type: .[0], count: length})'

List Data Sources

cat reflex-entities.json | jq '.[] | select(.type | endswith("Source-v1")) | {name: .payload.name, type: .type, id: .uniqueIdentifier}'

List Rules

cat reflex-entities.json | jq '.[] | select(.type == "timeSeriesView-v1" and .payload.definition.type == "Rule") | {name: .payload.name, id: .uniqueIdentifier, shouldRun: .payload.definition.settings.shouldRun}'

List Objects and Their Attributes

# Objects
cat reflex-entities.json | jq '.[] | select(.type == "timeSeriesView-v1" and .payload.definition.type == "Object") | {name: .payload.name, id: .uniqueIdentifier}'

# Attributes for a specific object
OBJECT_ID="<object-guid>"
cat reflex-entities.json | jq --arg oid "$OBJECT_ID" '.[] | select(.type == "timeSeriesView-v1" and .payload.definition.type == "Attribute" and .payload.parentObject.targetUniqueIdentifier == $oid) | {name: .payload.name, id: .uniqueIdentifier}'

Inspect a Rule's Condition

RULE_ID="<rule-guid>"
cat reflex-entities.json \
  | jq --arg rid "$RULE_ID" '.[] | select(.uniqueIdentifier == $rid) | .payload.definition.instance' -r \
  | jq '.steps[] | {step: .name, rows: [.rows[] | .kind]}'

List Actions (Fabric Item Actions)

cat reflex-entities.json | jq '.[] | select(.type == "fabricItemAction-v1") | {name: .payload.name, itemType: .payload.fabricItem.itemType, itemId: .payload.fabricItem.itemId}'

Summary View

Get a high-level overview of an Activator's configuration:

cat reflex-entities.json | jq '{
  containers: [.[] | select(.type == "container-v1") | .payload.name],
  sources: [.[] | select(.type | endswith("Source-v1")) | {name: .payload.name, type: .type}],
  objects: [.[] | select(.type == "timeSeriesView-v1" and .payload.definition.type == "Object") | .payload.name],
  rules: [.[] | select(.type == "timeSeriesView-v1" and .payload.definition.type == "Rule") | {name: .payload.name, active: .payload.definition.settings.shouldRun}],
  actions: [.[] | select(.type == "fabricItemAction-v1") | {name: .payload.name, type: .payload.fabricItem.itemType}]
}'

Inspecting Power BI Sources

Power BI-backed Activator sources use powerBiSource-v1. The source's parent container-v1 must use exact case-sensitive payload.type: "pbiMetrics". The source query.queryString is a JSON-string Power BI source query payload, and metricDefinition describes the same semantic model metric, dimensions, filters, and report visual lineage. The Activator API does not accept semantic-model query text in query.queryString.

Current public API limitation: Power BI-backed Activator definitions cannot currently be relied on for public ALM readback. getDefinition can reject an artifact that was imported successfully when PBI ALM export is disabled. Preserve the exact response and request/correlation ID, describe inspection as unavailable, and do not claim that persistence failed or that the source is absent solely because the definition cannot be exported.

Flag a missing parent container or any container type other than pbiMetrics. In particular, powerBiQueries is invalid.

Parse the Stored Query and Metric Definition

jq -r '.[] | select(.type == "powerBiSource-v1")
  | .payload.query.queryString' reflex-entities.json | jq .

metricDefinition can be either a JSON string or an object. Parse both forms before explaining the metric:

import json
from pathlib import Path

entities = json.loads(Path("reflex-entities.json").read_text(encoding="utf-8"))
for entity in entities:
    if entity.get("type") != "powerBiSource-v1":
        continue
    payload = entity["payload"]
    metric = payload.get("metricDefinition")
    if isinstance(metric, str):
        metric = json.loads(metric)
    print(json.dumps({
        "sourceName": payload.get("name"),
        "datasetId": payload.get("datasetId") or payload.get("metadata", {}).get("datasetId"),
        "reportId": payload.get("reportId") or payload.get("metadata", {}).get("reportId"),
        "pageId": payload.get("pageId") or payload.get("metadata", {}).get("pageId"),
        "visualId": payload.get("visualId") or payload.get("metadata", {}).get("visualId"),
        "measureName": payload.get("measureName") or payload.get("metadata", {}).get("measureName"),
        "dimensionValue": payload.get("dimensionValue"),
        "metricDefinition": metric,
    }, indent=2))

Persisted Power BI source queries should omit top.

Consistency Checks

Call out any of these issues:

getDefinition is blocked because PBI ALM export is disabled. Report the limitation rather than fabricating source details.
query.queryString or metricDefinition is not parseable JSON.
The parent container is missing or is not exact pbiMetrics.
metricDefinition.type is not DatasetMetric.
Source datasetId, query provider.datasetId, and metricDefinition.definition.datasetId disagree.
The persisted query includes top.
A personalized source has dimensionValue, but the same value is absent from the query filters or metricDefinition.definition.filter.
metricDefinition.definition.filter uses BasicFilter instead of the semantic-query Version / From / Where contract.
Report, page, visual, or measure lineage is missing.

Must / Prefer / Avoid

MUST DO

Always use --resource https://api.fabric.microsoft.com with az rest
Always send --body '{}' for getDefinition — it is a POST and omitting the body can cause 411 errors
Handle LRO responses — getDefinition may return 202; poll the Location header
Base64-decode the ReflexEntities.json payload before inspection — it is Base64-encoded in the API response
JSON-parse the definition.instance field in rule entities — it is a JSON-encoded string, not a nested object
For Power BI sources, JSON-parse both query.queryString and metricDefinition before explaining metrics, dimensions, or filters

PREFER

Summary view first — give users a high-level overview before diving into individual entities
Save to file when the definition is large — decode once and explore with jq locally
Discover IDs dynamically via workspace and item listing + JMESPath filtering
Paginated listing for workspaces with many Activator items
Report Power BI lineage — include dataset/report/page/visual/measure metadata when available
Flag Power BI filter inconsistencies — especially missing personalized dimension values

AVOID

Hardcoded workspace or item IDs — always resolve dynamically
Using GET for getDefinition — it is a POST endpoint; GET will return 405
Attempting to read definitions of items with encrypted sensitivity labels — it will be blocked
Modifying data — this is a read-only skill; use authoring mode for write operations
Treating Power BI source queries as semantic-model query text — they are source payloads stored as JSON strings

Examples

List All Activators and Show Their Rules

# Step 1: List activators
az rest --method GET \
  --url "https://api.fabric.microsoft.com/v1/workspaces/${WS_ID}/reflexes" \
  --resource "https://api.fabric.microsoft.com" \
  | jq '.value[] | {id, displayName}'

# Step 2: For a specific activator, get and decode its definition
az rest --method POST \
  --url "https://api.fabric.microsoft.com/v1/workspaces/${WS_ID}/reflexes/${REFLEX_ID}/getDefinition" \
  --resource "https://api.fabric.microsoft.com" \
  --headers "Content-Type=application/json" \
  --body '{}' \
  | jq '.definition.parts[] | select(.path=="ReflexEntities.json") | .payload' -r \
  | base64 -d \
  | jq '.[] | select(.type == "timeSeriesView-v1" and .payload.definition.type == "Rule") | {name: .payload.name, active: .payload.definition.settings.shouldRun}'

Inspect a Specific Rule's Full Configuration

# Decode definition and extract rule details
az rest --method POST \
  --url "https://api.fabric.microsoft.com/v1/workspaces/${WS_ID}/reflexes/${REFLEX_ID}/getDefinition" \
  --resource "https://api.fabric.microsoft.com" \
  --headers "Content-Type=application/json" \
  --body '{}' \
  | jq '.definition.parts[] | select(.path=="ReflexEntities.json") | .payload' -r \
  | base64 -d \
  | jq '.[] | select(.payload.name == "Too hot for medicine") | .payload.definition.instance' -r \
  | jq '.steps[] | {step: .name, details: .rows}'

Querying Activation History

Activation history (when rules fired) is not available via the public REST API. It is accessible via the Activator MCP server using the get_activations_for_rule tool.

Prerequisites

Use the shared authentication guidance in COMMON-CLI.md § Authentication Recipes before connecting to the Activator MCP endpoint.

pip install mcp httpx azure-identity aiohttp

Workflow

List rules using the public API (getDefinition → decode → filter for Rule entities) to get the rule's uniqueIdentifier
Connect to the Activator MCP server and call get_activations_for_rule with the rule ID

MCP Server Connection

The Activator MCP endpoint is at:

https://api.fabric.microsoft.com/v1/mcp/workspaces/{workspaceId}/reflexes/{activatorId}

Use the shared Fabric API authentication guidance from COMMON-CORE.md § Authentication & Token Acquisition. MCP clients should rely on standard Azure identity flows and must not hardcode tokens.

Calling `get_activations_for_rule`

Connect using the MCP streamable_http_client, then call the tool:

from mcp import ClientSession
from mcp.client.streamable_http import streamable_http_client

# After connecting and initializing the session:
result = await session.call_tool(
    "get_activations_for_rule",
    {
        "getActivationsParams": {
            "workspaceId": "<workspace-id>",
            "artifactId": "<activator-id>",
            "ruleId": "<rule-uniqueIdentifier>",
        }
    },
)

The response contains totalCount and an activations array with details of each time the rule fired.

Available MCP Tools

Tool	Purpose
`list_rules`	List rules in an Activator (alternative to public API decode)
`get_activations_for_rule`	Get activation history for a specific rule

Agent Integration Notes

This skill uses the Fabric Items API (/reflexes) for listing and getDefinition for inspection
No additional data-plane protocols are needed for item/rule inspection — all use az rest with the Fabric API audience
getDefinition requires ReadWrite scopes even for read-only access — this is a known API requirement
Activation history requires the MCP server connection (not available via public REST API)
For creating or modifying Activator items and rules, use the authoring mode skill

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.

Security

What our scanner noticed· Low risk

Instructions that use the network

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/activator-cli · commit f8fac11

Licence

MIT License (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

Also distributed in

microsoft/skills-for-fabric

AutoGineer is not affiliated with or endorsed by Microsoft or Microsoft.

Download ZIP

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

From the author

AutoGineer summary

What it does

When to use it

Advantages

Usage examples

Install

Documentation by Microsoft

Fabric Activator (Reflex) — CLI Skill

Mode selection

Mode boundary rule

Terminal write — the step you must not skip

Source validation gate (authoring only)

Shared essentials (all modes)

Rules

MUST

PREFER

AVOID

Examples

Files

references/consumption.md

activator-cli consumption mode — Read-Only Activator Exploration via CLI

Table of Contents

Tool Stack

Connection

Listing Activator Items

List All Activators in a Workspace

Paginated Listing

Filter by Folder

Inspecting a Single Activator

Reading the Definition

Decode the Full Definition

Save Definition to File

Exploring Rules, Sources, and Actions

List All Entity Types

List Data Sources

List Rules

List Objects and Their Attributes

Inspect a Rule's Condition

List Actions (Fabric Item Actions)

Summary View

Inspecting Power BI Sources

Parse the Stored Query and Metric Definition

Consistency Checks

Must / Prefer / Avoid

MUST DO

PREFER

AVOID

Examples

List All Activators and Show Their Rules

Inspect a Specific Rule's Full Configuration

Querying Activation History

Prerequisites

Workflow

MCP Server Connection

Calling get_activations_for_rule

Available MCP Tools

Agent Integration Notes

Requirements and compatibility

Security

Attribution and licence

Related skills

Claude API

Transformers

Open Notebook

Vision Sft

LLM Evaluation

Lora Qlora Recipes

Download ZIP

Calling `get_activations_for_rule`