power-automate-mcp

Overview Schema Source Related Servers Discussions Admin

compare_runs

Read-only

Diff a failed Power Automate run against a baseline to find diverged actions, status changes, and output differences causing the failure.

Instructions

Diff a failed run against a working one to find what changed.

Use this when explain_run gives you an error that is technically clear but does not tell you WHY this run differed - intermittent failures, "it worked yesterday", data-dependent bugs. The portal makes you open two runs in two tabs and eyeball them side by side.

baseline_run_id is optional. Left empty, the tool finds the most recent Succeeded run of the same flow and uses that.

Returns: diverged_at first action whose status differs - start here status_changes [{action, baseline, failed}] every action that behaved differently output_changes [{action, baseline, failed}] actions that succeeded in BOTH runs but produced different outputs. This is usually the real cause. only_in_failed / only_in_baseline actions that ran in one and not the other, which means a condition or branch evaluated differently

If output_changes is empty and status_changes shows the same action failing both times, the failure is deterministic and the fix is in the definition, not the data.

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>",
      "failed_run_id": "<failed_run_id>"
    },
    "name": "compare_runs"
  }
}

Input Schema

Name	Required	Description	Default
`flow_id`	Yes
`failed_run_id`	Yes
`baseline_run_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.1.0Nov 6, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations declare readOnlyHint=true and the description is fully consistent with a read-only diff, adding real behavior context: the optional baseline resolves to the most recent Succeeded run of the same flow. However, the substantial 'Returns:' block describes output structure rather than behavioral traits, and with annotations already covering the safety profile the net behavioral addition is moderate rather than exceptional.

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?

Front-loaded with the one-line purpose, then usage, then a clearly labeled field-by-field Returns block, closing with an interpretation rule. The portal anecdote ('two tabs and eyeball them side by side') is motivational color that could be cut, but the rest of the prose earns 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?

No output schema exists, so the detailed breakdown of diverged_at, status_changes, output_changes, and only_in_failed/only_in_baseline is exactly what the description owes. Combined with the default-baseline behavior and the deterministic-vs-data-dependent diagnostic rule, an agent has everything needed to call and read this tool correctly.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must carry the parameter burden. It fully explains the non-obvious one ('baseline_run_id is optional. Left empty, the tool finds the most recent Succeeded run of the same flow'), including the default resolution rule and same-flow scoping; flow_id and failed_run_id are left to inference from their names, which is a minor residual gap.

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 ('Diff a failed run against a working one to find what changed') and immediately differentiates itself from the sibling explain_run by explaining the gap it fills. An agent can tell this apart from explain_run, list_runs, or analyze_flow_health without opening any schema.

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

Usage Guidelines5/5

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

Explicitly names the alternative (explain_run) and the exact condition that should route the agent here: intermittent failures, 'it worked yesterday', data-dependent bugs. It also supplies a decision heuristic at the end for interpreting the result ('if output_changes is empty ... the fix is in the definition, not the data'), which is guidance beyond mere when-to-use.

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

Deploy Server