Skip to main content
Glama
Sign In
power-automate-mcp

power-automate-mcp

by OwnOptic
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

explain_run

Read-only

Diagnose failed Power Automate flow runs by resolving the actual error from failed actions and pairing them with upstream action outputs so you can identify the root cause fast.

Instructions

Diagnose a run: which action failed, with what error, on what inputs.

This is the tool the portal makes you click twelve times to replicate, and the one a generic HTTP wrapper cannot give you, for two reasons:

  1. The error is not on the action record. Failed actions come back with error: null; the message sits in a SAS-signed blob referenced by outputsLink.uri. This tool follows that link for every failed action.

  2. A failure is rarely explained by the failing action alone. The cause is usually in what an EARLIER action produced. So the response pairs the failed action with the outputs of the actions that succeeded before it.

Returns: status overall run status failed_actions [{name, error, inputs}] - resolved error text, not null succeeded [{name, outputs}] - upstream context, in execution order hint where to look first

If failed_actions is empty and status is Failed, the failure was in the trigger, not the body - check the trigger's condition and inputs.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "flow_id": "<flow_id>",
      "run_id": "<run_id>"
    },
    "name": "explain_run"
  }
}

Input Schema

NameRequiredDescriptionDefault
run_idYes
flow_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare readOnlyHint, so the description carries the real behavioral burden and does so well: it discloses that errors are resolved from a SAS-signed blob via outputsLink.uri, and that the response includes upstream succeeded actions in execution order. The documented edge case about trigger-level failures is exactly the kind of non-obvious behavior an agent cannot infer elsewhere.

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 one-line purpose is front-loaded, the two numbered reasons are tight and evidence-bearing, and the return-value block is scannable. The "portal makes you click twelve times" framing is colorful but justifies why the tool exists, so it earns most of its space.

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?

There is no output schema, and the description fully compensates by enumerating status, failed_actions, succeeded, and hint with their shapes. Combined with the error-resolution mechanism and the trigger-vs-body failure rule, an agent has everything needed to call and interpret this tool.

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

Parameters3/5

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

Schema description coverage is 0% for both parameters, so the description must compensate and largely does not — flow_id and run_id are never mentioned, nor is their scope or relationship (run_id belonging to flow_id). The names are largely self-explanatory, which keeps this at a minimum-viable 3 rather than lower.

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?

States a specific verb and resource — "Diagnose a run" — and immediately narrows to "which action failed, with what error, on what inputs." That is clearly distinct from siblings like list_runs, compare_runs, and analyze_flow_health, which operate at different scopes.

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

Usage Guidelines4/5

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

Gives strong when-to-use context by contrasting itself with a generic HTTP wrapper and naming the exact scenario (post-failure diagnosis). It also supplies an explicit edge-case rule: if failed_actions is empty but status is Failed, look at the trigger. It never names a sibling tool as the alternative, so it falls short of a 5.

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

Deploy Server

Other Tools