power-automate-mcp-server

add_flow_owner

Destructive

Add an owner to a Microsoft Power Automate flow by granting CanEdit or CanView role to a user or group using their Azure AD object ID.

Instructions

Grant a principal a role on a flow (PUT .../permissions/{principalId}) [DISABLED: set ENABLE_WRITE_OPS=true]. Parameters: flow (required), principalId (required — AAD object id), roleName (CanEdit|CanView), environment (optional). Uses Microsoft's unofficial api.flow.microsoft.com endpoint, which Microsoft labels unsupported; behavior may change.

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": "<flow>",
      "principalId": "<principalId>",
      "roleName": "<roleName>"
    },
    "name": "add_flow_owner"
  }
}

Input Schema

Name	Required	Description
`flow`	Yes	Flow GUID name (from list_flows).
`roleName`	Yes	Role to grant.
`environment`	No	Environment id (from list_environments). Omit to use the user's default environment.
`principalId`	Yes	Azure AD object id of the user/group to grant.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.4Aug 6, 2026

TDQS

A4/5.0

Behavior4/5

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

Beyond the destructiveHint annotation, the description warns that the Microsoft endpoint is unofficial and unsupported, adding important risk context. It also discloses the PUT method and the disabled-by-default status, which are behavioral traits not captured by annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence is concise and information-dense, but the subsequent parameter enumeration duplicates the input schema. It is not overly verbose, but not every sentence adds unique value for an agent that already sees the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with full schema coverage, the description provides essential operational context: the unofficial endpoint, the disabled flag, and the required parameters. It does not explain return values, but no output schema exists and the focus is on invocation, which is adequately covered.

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?

The input schema already covers all four parameters with descriptions and enums, so the baseline is 3. The description mostly repeats the schema's parameter list without adding new semantic detail, such as format constraints or examples beyond what the schema provides.

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?

The description begins with 'Grant a principal a role on a flow', a specific verb and resource that clearly distinguishes this from sibling tools like list_flow_owners and remove_flow_owner. The HTTP method and parameter list further reinforce the intended action.

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?

It clearly states that the tool grants a role to a principal on a flow and lists required parameters. It also provides the prerequisite about ENABLE_WRITE_OPS. However, it does not explicitly mention alternatives or when not to use it, so it stops short of full exclusion guidance.

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

Deploy Server