Microsoft Power Automate vs Windmill API + MCP

Microsoft Power Automate

Cloud flows in a solution are rows an agent can read and write through the Dataverse Web API under Entra ID OAuth and security roles, with published limits and a 99.9 per cent SLA. Flows under My flows can't be managed in code, a flow's body is one hand-built JSON string, and setup needs a tenant administrator.

Windmill API + MCP

Token scopes down to a single script path, with expiry. The default MCP URL puts the token in ?token= unless a superadmin turns that off.

Microsoft Power Automate

1. Filter workflows on category eq 5 for cloud flows, and add $select, because clientdata holds the whole definition
2. Flows created through the API start with statecode 0 (off). The docs say to turn the flow on before use
3. Put the flow in a solution first. Flows that sit only under My flows are outside the supported API
4. On 429 wait the Retry-After seconds. Reads of flowruns count against the daily Power Platform request allowance
5. Treat an HTTP trigger URL with sig= as a secret, and prefer the tenant or named-user trigger modes with a bearer token for https://service.flow.microsoft.com/

Windmill API + MCP

1. Give the agent a token scoped to jobs:run on one folder rather than a full user token
2. Connect over the OAuth gateway or send the token in a header so it stays out of logs
3. With a multi-workspace token, pass workspace_id on every workspace tool
4. Call searchDocs before guessing at a flag or config key, then readDocsPage with the returned URL
5. Poll the job by ID after runScriptByPath for long jobs instead of waiting on the call