Skip to main content
Glama
microsoft

Microsoft Fabric RTI MCP Server

Official
by microsoft

activator_create_trigger

Destructive

Create an alert that fires when a KQL query returns data. Configure polling frequency, recipients, and notification type.

Instructions

    Use this tool create an alert that will fire when the source generates data.

    :param workspace_id: The workspace ID (UUID)
    :param trigger_name: Name of the trigger
    :param kql_cluster_url: The KQL cluster URL
    :param kql_database: The KQL database name
    :param kql_query: The KQL query to monitor. The query MUST be appropriate for the schema of the underlying
        data, otherwise the alert will not function correctly
    :param alert_recipient: Email address of the alert recipient
    :param alert_message: Alert message for the trigger
    :param alert_headline: Alert headline for the trigger
    :param alert_type: Type of alert - "teams" or "email" (defaults to "teams")
    :param kql_polling_frequency_minutes: Polling frequency in minutes. Must be one of: 5, 15, 60, 180, 360, 720,
        1440 (defaults to 5)
    :param artifact_id: If specified, the trigger will be created in the specified Activator artifact.
        If left blank, a new Activator artifact will be created.
    :return: Created trigger details:
        * url: URL back to the trigger in Fabric UI for further management
        * id: Artifact ID if a new one was created
        * displayName: Name of newly created trigger

    Critical:
    * This API call will NOT tell the caller if a KQL query is used which does not match the source data schema,
    so any KQL query should be double-checked upfront.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
workspace_idYes
trigger_nameYes
kql_cluster_urlYes
kql_databaseYes
kql_queryYes
alert_recipientYes
alert_messageYes
alert_headlineYes
alert_typeNoteams
kql_polling_frequency_minutesNo
artifact_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior4/5

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

Annotations indicate destructiveHint=true, but the description does not address destructiveness. However, it adds critical behavioral notes: the API does not validate whether the KQL query matches the data schema, and it warns about double-checking queries. It also describes output (URL, ID, displayName).

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?

The description is well-structured as a docstring with parameter list and critical note. It is front-loaded with the purpose. While somewhat lengthy, every sentence provides value. Could be slightly more concise.

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?

Given the high parameter count (11) and lack of annotations, the description covers all parameters, includes return value details, and adds a critical caveat about query validation. This is sufficient for a correct invocation.

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

Parameters5/5

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

With 0% schema description coverage, the description fully compensates by explaining each of the 11 parameters, including types (UUID, email, integer), default values (alert_type, polling_frequency), and constraints (polling frequency must be one of 5,15,...). The KQL query parameter includes a critical warning about schema compatibility.

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?

The description clearly states the tool's purpose: 'create an alert that will fire when the source generates data.' It uses a specific verb ('create') and resource ('alert/trigger'), and distinguishes itself from siblings like 'activator_list_artifacts' which only lists artifacts.

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

Usage Guidelines3/5

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

The description implies when to use the tool (creating a trigger) but does not explicitly state when not to use it or provide alternatives. No guidance on prerequisites or comparisons with other tools, though the sibling list suggests it is the correct tool for creation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/microsoft/fabric-rti-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server