chore: publish from main

plugins/flowstudio-power-automate/skills/flowstudio-power-automate-build/SKILL.md

@@ -392,7 +392,7 @@ if runs:
     print(result)   # {"resubmitted": true, "triggerName": "..."}
 ```
 
-### HTTP-triggered flows — custom test payload
+### HTTP, Button, and PowerApps flows — custom test payload
 
 Only use `trigger_live_flow` when you need to send a **different** payload
 than the original run. For verifying a fix, `resubmit_live_flow_run` is
@@ -407,7 +407,8 @@ print("Expected body:", manual.get("inputs", {}).get("schema"))
 result = mcp("trigger_live_flow",
     environmentName=ENV, flowName=FLOW_ID,
     body={"name": "Test", "value": 1})
-print(f"Status: {result['responseStatus']}")
+print(f"Status: {result['responseStatus']}, via: {result['invocation']}")
+print(result.get("warning"))   # set when a required input was missing: the run still ran, with null
 ```
 
 ### Brand-new non-HTTP flows (Recurrence, connector triggers, etc.)
@@ -469,7 +470,7 @@ payload.
 | Flow deployed but state is "Stopped" | Flow won't run on schedule | Call `set_live_flow_state` with `state: "Started"` — do **not** use `update_live_flow` for state changes |
 | Teams "Chat with Flow bot" recipient as object | 400 `GraphUserDetailNotFound` | Use plain string with trailing semicolon (see below) |
 | Copilot/Skills flow not in a solution | Copilot Studio may not discover it as an agent tool | After deploy, call `add_live_flow_to_solution` with the target `solutionId` |
-| Button/Skills trigger used for MCP testing | MCP cannot directly fire the production trigger | Test the same actions through a temporary HTTP twin, then swap the trigger back |
+| Button/Skills trigger used for MCP testing | Runs even when a required input is missing (null) | Pass inputs in `trigger_live_flow` `body`; on `warning`, cancel and retry with the full body |
 | Connector action missing `metadata.operationMetadataId` | Designer/run-only UI can behave inconsistently | Preserve existing IDs; add stable GUIDs for new connector actions |
 | Placeholder Excel `scriptId` | Dynamic validation fails at save time | Resolve the real Office Script ID before deploying |
 | SharePoint `PatchItem` omits required fields | Save can fail even if the field is not changing | Echo unchanged required fields such as `item/Title` |

plugins/flowstudio-power-automate/skills/flowstudio-power-automate-build/references/trigger-types.md

@@ -121,9 +121,9 @@ input names and types.
 
 After deploying a production Skills-triggered flow, call
 `add_live_flow_to_solution` with the target `solutionId`; Copilot Studio agent
-tool discovery expects the flow to be solution-aware. For MCP-driven testing,
+tool discovery expects the flow to be solution-aware. To test it from MCP, call
-use a temporary HTTP twin with the same actions and payload shape, then restore
+`trigger_live_flow` with the inputs in `body` — Skills triggers run through the
-the Skills trigger after the actions are verified.
+connector runtime the same way Button and PowerApps triggers do.
 
 ---
 

plugins/flowstudio-power-automate/skills/flowstudio-power-automate-debug/SKILL.md

@@ -411,13 +411,14 @@ print(new_runs[0]["status"])   # Succeeded = done
 | **Testing a fix** on any flow | `resubmit_live_flow_run` | Replays the exact trigger payload that caused the failure — best way to verify |
 | Recurrence / scheduled flow | `resubmit_live_flow_run` | Cannot be triggered on demand any other way |
 | SharePoint / connector trigger | `resubmit_live_flow_run` | Cannot be triggered without creating a real SP item |
-| HTTP trigger with **custom** test payload | `trigger_live_flow` | When you need to send different data than the original run |
+| HTTP, Button, or PowerApps trigger with **custom** test payload | `trigger_live_flow` | When you need to send different data than the original run |
-| Brand-new flow, never run | `trigger_live_flow` (HTTP only) | No prior run exists to resubmit |
+| Brand-new flow, never run | `trigger_live_flow` (HTTP, Button, PowerApps) | No prior run exists to resubmit |
 
-### Testing HTTP-Triggered Flows with custom payloads
+### Testing HTTP, Button, and PowerApps flows with custom payloads
 
-For flows with a `Request` (HTTP) trigger, use `trigger_live_flow` when you
+For flows with a `Request` trigger (HTTP request, manual Button, or PowerApps),
-need to send a **different** payload than the original run:
+use `trigger_live_flow` when you need to send a **different** payload than the
+original run. Pass trigger inputs as `body` for every kind:
 
 ```python
 # First inspect what the trigger expects — read directly from the flow definition
@@ -438,10 +439,27 @@ result = mcp("trigger_live_flow",
     flowName=FLOW_ID,
     body={"name": "Test User", "value": 42})
 print(f"Status: {result['responseStatus']}, Body: {result.get('responseBody')}")
+print(f"Kind: {result['triggerKind']}, via: {result['invocation']}, run: {result.get('runName')}")
+if result.get("warning"):
+    print(result["warning"])   # required trigger inputs you left out
 ```
 
 > `trigger_live_flow` handles AAD-authenticated triggers automatically.
-> Only works for flows with a `Request` (HTTP) trigger type.
+> Works for `Request` triggers only: HTTP request, Button, and PowerApps.
+> Scheduled and connector triggers cannot be run this way.
+>
+> Power Automate does not enforce a trigger's `required` inputs. If you leave
+> one out the run still starts, with that input null, and the result carries a
+> `warning` naming the missing keys. Cancel the run and call again with the
+> full body if that matters.
+>
+> `runName` is only returned for Button and PowerApps runs. For HTTP triggers
+> find the run with `get_live_flow_runs`.
+>
+> Over a browser-extension key, Button and PowerApps triggers run only with an
+> empty body. The tool says so and lists the ways round it: resubmit a past run,
+> default the inputs inside the flow with `coalesce(triggerBody()?['x'], 'value')`,
+> or use a standard API key.
 
 ---
 

plugins/flowstudio-power-automate/skills/flowstudio-power-automate-mcp/references/tool-reference.md

@@ -435,31 +435,47 @@ responseSchemaCount - Number of Response actions that define output schemas
 
 ### `get_live_flow_trigger_url`
 
-Deprecated. Prefer `trigger_live_flow` when you need to invoke an HTTP-triggered
+Deprecated. Prefer `trigger_live_flow` when you need to run a flow; it fetches the
-flow; it fetches the current callback URL internally.
+callback URL internally for HTTP triggers and uses the connector runtime for
+Button and PowerApps triggers, which have no callback URL.
 
 Returns the signed callback URL for HTTP-triggered flows. Response includes
 `flowKey`, `triggerName`, `triggerType`, `triggerKind`, `triggerMethod`, `triggerUrl`.
 
 ### `trigger_live_flow`
 
-Response keys: `flowKey`, `triggerName`, `triggerUrl`, `requiresAadAuth`, `authType`,
+Response keys: `flowKey`, `triggerName`, `triggerKind`, `invocation`, `triggerUrl`,
-`responseStatus`, `responseBody`.
+`requiresAadAuth`, `authType`, `responseStatus`, `responseBody`, `runName`, and
+`warning` when a required trigger input was not supplied.
 
-> **Only works for `Request` (HTTP) triggers.** Returns an error for Recurrence
+> **Works for `Request` triggers: HTTP request, Button, and PowerApps.** Returns an
-> and other trigger types: `"only HTTP Request triggers can be invoked via this tool"`.
+> error for Recurrence and connector triggers:
-> `Button`-kind triggers return `ListCallbackUrlOperationBlocked`.
+> `"only HTTP Request triggers can be invoked via this tool"`.
+>
+> HTTP triggers go through the signed callback URL (`invocation: callbackUrl`).
+> Button and PowerApps triggers have no callback URL; with a `body` they run
+> through the Power Platform connector runtime (`connectorFlowToken` or
+> `connectorApihubToken`), which is the only route that delivers the inputs.
+> With no body they use the cheaper direct run (`directRun`).
+>
+> `runName` is returned only for connector-runtime runs. Otherwise look the run
+> up with `get_live_flow_runs`.
+>
+> Power Automate does not enforce a trigger's `required` list. A missing input
+> still starts the run with a null value; `warning` names the missing keys and
+> the body shape to retry with.
+>
+> Browser-extension keys cannot reach the connector runtime, so Button and
+> PowerApps triggers run only with an empty body over that key type. The error
+> lists the alternatives (resubmit a past run, default the inputs inside the flow
+> with `coalesce()`, or use a standard key).
 >
 > `responseStatus` + `responseBody` contain the flow's Response action output.
 > AAD-authenticated triggers are handled automatically.
 >
-> **Content-type note**: The body is sent as `application/octet-stream` (raw),
+> **Content type**: `body` is sent as `application/json`, so `triggerBody()` and
-> not `application/json`. Flows with a trigger schema that has `required` fields
+> the trigger schema see the object you passed. Verified 2026-08-27 on server 1.2.43
-> will reject the request with `InvalidRequestContent` (400) because PA validates
+> against Button, PowerAppV2, and Skills triggers with `required` schemas.
-> `Content-Type` before parsing against the schema. Flows without a schema, or
-> flows designed to accept raw input (e.g. Baker-pattern flows that parse the body
-> internally), will work fine. The flow receives the JSON as base64-encoded
-> `$content` with `$content-type: application/octet-stream`.
 
 ---
 
@@ -578,8 +594,10 @@ tool schemas cannot tell you.
   connectionReferences. Use `set_live_flow_state` to start/stop a flow.
 
 ### `trigger_live_flow`
-- **Only works for HTTP Request triggers.** Returns error for Recurrence, connector,
+- **Works for HTTP, Button, and PowerApps triggers.** Returns error for Recurrence,
-  and other trigger types.
+  connector, and other trigger types.
+- Pass trigger inputs as `body`. A `warning` in the result means a required input
+  was missing and the run started with it null.
 - AAD-authenticated triggers are handled automatically (impersonated Bearer token).
 
 ### `get_live_flow_runs`

skills/flowstudio-power-automate-build/SKILL.md

@@ -392,7 +392,7 @@ if runs:
     print(result)   # {"resubmitted": true, "triggerName": "..."}
 ```
 
-### HTTP-triggered flows — custom test payload
+### HTTP, Button, and PowerApps flows — custom test payload
 
 Only use `trigger_live_flow` when you need to send a **different** payload
 than the original run. For verifying a fix, `resubmit_live_flow_run` is
@@ -407,7 +407,8 @@ print("Expected body:", manual.get("inputs", {}).get("schema"))
 result = mcp("trigger_live_flow",
     environmentName=ENV, flowName=FLOW_ID,
     body={"name": "Test", "value": 1})
-print(f"Status: {result['responseStatus']}")
+print(f"Status: {result['responseStatus']}, via: {result['invocation']}")
+print(result.get("warning"))   # set when a required input was missing: the run still ran, with null
 ```
 
 ### Brand-new non-HTTP flows (Recurrence, connector triggers, etc.)
@@ -469,7 +470,7 @@ payload.
 | Flow deployed but state is "Stopped" | Flow won't run on schedule | Call `set_live_flow_state` with `state: "Started"` — do **not** use `update_live_flow` for state changes |
 | Teams "Chat with Flow bot" recipient as object | 400 `GraphUserDetailNotFound` | Use plain string with trailing semicolon (see below) |
 | Copilot/Skills flow not in a solution | Copilot Studio may not discover it as an agent tool | After deploy, call `add_live_flow_to_solution` with the target `solutionId` |
-| Button/Skills trigger used for MCP testing | MCP cannot directly fire the production trigger | Test the same actions through a temporary HTTP twin, then swap the trigger back |
+| Button/Skills trigger used for MCP testing | Runs even when a required input is missing (null) | Pass inputs in `trigger_live_flow` `body`; on `warning`, cancel and retry with the full body |
 | Connector action missing `metadata.operationMetadataId` | Designer/run-only UI can behave inconsistently | Preserve existing IDs; add stable GUIDs for new connector actions |
 | Placeholder Excel `scriptId` | Dynamic validation fails at save time | Resolve the real Office Script ID before deploying |
 | SharePoint `PatchItem` omits required fields | Save can fail even if the field is not changing | Echo unchanged required fields such as `item/Title` |

skills/flowstudio-power-automate-build/references/trigger-types.md

@@ -121,9 +121,9 @@ input names and types.
 
 After deploying a production Skills-triggered flow, call
 `add_live_flow_to_solution` with the target `solutionId`; Copilot Studio agent
-tool discovery expects the flow to be solution-aware. For MCP-driven testing,
+tool discovery expects the flow to be solution-aware. To test it from MCP, call
-use a temporary HTTP twin with the same actions and payload shape, then restore
+`trigger_live_flow` with the inputs in `body` — Skills triggers run through the
-the Skills trigger after the actions are verified.
+connector runtime the same way Button and PowerApps triggers do.
 
 ---
 

skills/flowstudio-power-automate-debug/SKILL.md

@@ -411,13 +411,14 @@ print(new_runs[0]["status"])   # Succeeded = done
 | **Testing a fix** on any flow | `resubmit_live_flow_run` | Replays the exact trigger payload that caused the failure — best way to verify |
 | Recurrence / scheduled flow | `resubmit_live_flow_run` | Cannot be triggered on demand any other way |
 | SharePoint / connector trigger | `resubmit_live_flow_run` | Cannot be triggered without creating a real SP item |
-| HTTP trigger with **custom** test payload | `trigger_live_flow` | When you need to send different data than the original run |
+| HTTP, Button, or PowerApps trigger with **custom** test payload | `trigger_live_flow` | When you need to send different data than the original run |
-| Brand-new flow, never run | `trigger_live_flow` (HTTP only) | No prior run exists to resubmit |
+| Brand-new flow, never run | `trigger_live_flow` (HTTP, Button, PowerApps) | No prior run exists to resubmit |
 
-### Testing HTTP-Triggered Flows with custom payloads
+### Testing HTTP, Button, and PowerApps flows with custom payloads
 
-For flows with a `Request` (HTTP) trigger, use `trigger_live_flow` when you
+For flows with a `Request` trigger (HTTP request, manual Button, or PowerApps),
-need to send a **different** payload than the original run:
+use `trigger_live_flow` when you need to send a **different** payload than the
+original run. Pass trigger inputs as `body` for every kind:
 
 ```python
 # First inspect what the trigger expects — read directly from the flow definition
@@ -438,10 +439,27 @@ result = mcp("trigger_live_flow",
     flowName=FLOW_ID,
     body={"name": "Test User", "value": 42})
 print(f"Status: {result['responseStatus']}, Body: {result.get('responseBody')}")
+print(f"Kind: {result['triggerKind']}, via: {result['invocation']}, run: {result.get('runName')}")
+if result.get("warning"):
+    print(result["warning"])   # required trigger inputs you left out
 ```
 
 > `trigger_live_flow` handles AAD-authenticated triggers automatically.
-> Only works for flows with a `Request` (HTTP) trigger type.
+> Works for `Request` triggers only: HTTP request, Button, and PowerApps.
+> Scheduled and connector triggers cannot be run this way.
+>
+> Power Automate does not enforce a trigger's `required` inputs. If you leave
+> one out the run still starts, with that input null, and the result carries a
+> `warning` naming the missing keys. Cancel the run and call again with the
+> full body if that matters.
+>
+> `runName` is only returned for Button and PowerApps runs. For HTTP triggers
+> find the run with `get_live_flow_runs`.
+>
+> Over a browser-extension key, Button and PowerApps triggers run only with an
+> empty body. The tool says so and lists the ways round it: resubmit a past run,
+> default the inputs inside the flow with `coalesce(triggerBody()?['x'], 'value')`,
+> or use a standard API key.
 
 ---
 

skills/flowstudio-power-automate-mcp/references/tool-reference.md

@@ -435,31 +435,47 @@ responseSchemaCount - Number of Response actions that define output schemas
 
 ### `get_live_flow_trigger_url`
 
-Deprecated. Prefer `trigger_live_flow` when you need to invoke an HTTP-triggered
+Deprecated. Prefer `trigger_live_flow` when you need to run a flow; it fetches the
-flow; it fetches the current callback URL internally.
+callback URL internally for HTTP triggers and uses the connector runtime for
+Button and PowerApps triggers, which have no callback URL.
 
 Returns the signed callback URL for HTTP-triggered flows. Response includes
 `flowKey`, `triggerName`, `triggerType`, `triggerKind`, `triggerMethod`, `triggerUrl`.
 
 ### `trigger_live_flow`
 
-Response keys: `flowKey`, `triggerName`, `triggerUrl`, `requiresAadAuth`, `authType`,
+Response keys: `flowKey`, `triggerName`, `triggerKind`, `invocation`, `triggerUrl`,
-`responseStatus`, `responseBody`.
+`requiresAadAuth`, `authType`, `responseStatus`, `responseBody`, `runName`, and
+`warning` when a required trigger input was not supplied.
 
-> **Only works for `Request` (HTTP) triggers.** Returns an error for Recurrence
+> **Works for `Request` triggers: HTTP request, Button, and PowerApps.** Returns an
-> and other trigger types: `"only HTTP Request triggers can be invoked via this tool"`.
+> error for Recurrence and connector triggers:
-> `Button`-kind triggers return `ListCallbackUrlOperationBlocked`.
+> `"only HTTP Request triggers can be invoked via this tool"`.
+>
+> HTTP triggers go through the signed callback URL (`invocation: callbackUrl`).
+> Button and PowerApps triggers have no callback URL; with a `body` they run
+> through the Power Platform connector runtime (`connectorFlowToken` or
+> `connectorApihubToken`), which is the only route that delivers the inputs.
+> With no body they use the cheaper direct run (`directRun`).
+>
+> `runName` is returned only for connector-runtime runs. Otherwise look the run
+> up with `get_live_flow_runs`.
+>
+> Power Automate does not enforce a trigger's `required` list. A missing input
+> still starts the run with a null value; `warning` names the missing keys and
+> the body shape to retry with.
+>
+> Browser-extension keys cannot reach the connector runtime, so Button and
+> PowerApps triggers run only with an empty body over that key type. The error
+> lists the alternatives (resubmit a past run, default the inputs inside the flow
+> with `coalesce()`, or use a standard key).
 >
 > `responseStatus` + `responseBody` contain the flow's Response action output.
 > AAD-authenticated triggers are handled automatically.
 >
-> **Content-type note**: The body is sent as `application/octet-stream` (raw),
+> **Content type**: `body` is sent as `application/json`, so `triggerBody()` and
-> not `application/json`. Flows with a trigger schema that has `required` fields
+> the trigger schema see the object you passed. Verified 2026-08-27 on server 1.2.43
-> will reject the request with `InvalidRequestContent` (400) because PA validates
+> against Button, PowerAppV2, and Skills triggers with `required` schemas.
-> `Content-Type` before parsing against the schema. Flows without a schema, or
-> flows designed to accept raw input (e.g. Baker-pattern flows that parse the body
-> internally), will work fine. The flow receives the JSON as base64-encoded
-> `$content` with `$content-type: application/octet-stream`.
 
 ---
 
@@ -578,8 +594,10 @@ tool schemas cannot tell you.
   connectionReferences. Use `set_live_flow_state` to start/stop a flow.
 
 ### `trigger_live_flow`
-- **Only works for HTTP Request triggers.** Returns error for Recurrence, connector,
+- **Works for HTTP, Button, and PowerApps triggers.** Returns error for Recurrence,
-  and other trigger types.
+  connector, and other trigger types.
+- Pass trigger inputs as `body`. A `warning` in the result means a required input
+  was missing and the run started with it null.
 - AAD-authenticated triggers are handled automatically (impersonated Bearer token).
 
 ### `get_live_flow_runs`