Cancel a currently running Power Automate flow run via the live PA API. Use after get_live_flow_runs to obtain the run name. Only runs with status "Running" can be cancelled.
| Name | Required | Description | Default |
|---|---|---|---|
| runName | Yes | Run identifier (name field from get_live_flow_runs). | |
| flowName | Yes | Name (ID) of the flow. | |
| environmentName | Yes | Name of the Power Platform environment. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true, so the mutation risk is known. The description adds value by disclosing the running-status requirement and the prerequisite call, which are not visible in the annotations or schema. It does not contradict any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the operation, followed by the required sequence and constraint. Every sentence earns its place and there is no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple parameter set (all documented), the acknowledged destructive hint, and the absence of an output schema, the description covers what an agent needs to call it correctly: the precondition, the parameter source, and the target state. No significant missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a clear description (e.g., runName is identified as the name field from get_live_flow_runs). The description reinforces the relationship to get_live_flow_runs but adds no new parameter-level semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action (cancel) on a clearly defined resource (currently running Power Automate flow run) via the live PA API. It is distinct from sibling tools like resubmit_live_flow_run or set_live_flow_state because the target and operation are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent to call get_live_flow_runs first to obtain the run name, and states the only valid precondition: status 'Running'. This gives clear when-to-use guidance and a when-not-to-use condition (non-Running runs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The consistent live/store prefixes and clear resource nouns make most tools distinguishable, and deprecated tools explicitly flag replacements. However, the duplicated live-vs-cache surfaces and multiple run/error-history tools can still require careful reading to choose correctly.
All tools follow a consistent snake_case verb_noun pattern with stable qualifiers like live, store, flow, and run. Even meta-tools like list_skills and tool_search fit the same convention, and the few longer names such as add_live_flow_to_solution remain predictable.
34 tools is well above the 25+ threshold for 'too many,' and the set is inflated by live/store duplication plus four deprecated tools scheduled for removal. Several tools could be consolidated or dropped without losing capability.
The server covers the main flow lifecycle well: list/get/create/update, state changes, running, resubmission, run diagnostics, environments, connections, and solution migration. Notable gaps include no delete flow, no remove-from-solution operation, and read-only connection management, which agents can partially work around.
