Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@power-automate-mcp show me recent runs of my flows"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for Microsoft Power Automate (cloud flows), driven entirely by the Azure CLI (az rest). It is the Power Automate sibling of microsoft-planner-mcp and uses the same azRest pattern.
az rest?The Azure CLI can mint tokens for both because you authorize as yourself acting on your own flows. Every call goes through az rest, which is CAE (conditional-access aware), so the only prerequisite is a logged-in Azure CLI:
az loginRelated MCP server: Flow Studio - Power Automate MCP Server
npm install
npm run build # tsc -> dist/index.jsEither add a project-scoped .mcp.json:
{
"mcpServers": {
"power-automate": {
"type": "stdio",
"command": "node",
"args": ["/path/to/power-automate-mcp/dist/index.js"],
"env": { "POWER_AUTOMATE_ENV": "<your-default-environment-id>" }
}
}
}…or globally with the CLI:
claude mcp add power-automate -s user -- node /path/to/power-automate-mcp/dist/index.jsPOWER_AUTOMATE_ENV is optional: set it to a default environment id so the flow tools can be called without repeating it. Discover ids with list-environments.
Environments
list-environments — all environments you can access (use name as the environment arg)
Flows
list-flows — flows in an environment (name, display name, state)
get-flow — full flow record (definition + connectionReferences)
get-flow-definition — just the workflow definition (triggers + actions)
create-flow — create a flow from a definition (+ optional connectionReferences)
update-flow — PATCH a flow's full properties
enable-flow / disable-flow — start / stop a flow's triggers
delete-flow — delete a flow
Triggers / on-demand runs
list-flow-triggers — a flow's triggers (name + type)
run-flow — trigger a flow on demand (manual or Recurrence, etc.)
Run history / diagnostics
list-runs — recent runs (status, start/end, error) — a health probe
get-run — one run's full record
list-run-actions — per-action results + inputs/outputs SAS links
Connections
list-connections — connector connections (ids to build connectionReferences)
The flow internal name is a GUID (from list-flows), not the display name.
create-flow / update-flow take the definition / properties as JSON strings (the Logic Apps workflow JSON is too freeform for a strict schema). A typical edit is: get-flow → tweak properties → update-flow.
connectionReferences must bind to existing connector connections — the API will not mint OAuth connections for you. Connector-less flows (recurrence + HTTP) need none.
Create a new cloud flow. definition is a Logic Apps workflow JSON (triggers + actions). connectionReferences must bind to EXISTING connector connections (the API will not mint OAuth connections for you -- see list-connections). Connector-less flows (recurrence + HTTP) need no references.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Initial state (default Started) | |
| displayName | Yes | Display name for the new flow | |
| environment | No | Environment id (defaults to POWER_AUTOMATE_ENV) | |
| definitionJson | Yes | Workflow definition as a JSON string (schema/triggers/actions) | |
| connectionReferencesJson | No | connectionReferences as a JSON string (omit for connector-less flows) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the API does not mint OAuth connections and that connection references must exist, but lacks information about error handling, idempotency, or authorization requirements.
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 concise sentences with front-loaded purpose. Every sentence provides essential guidance without redundancy.
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?
Covers core creation logic, connection requirements, and environment defaults. Lacks mention of return value (e.g., flow ID), but given no output schema, the description is mostly adequate for the 5-parameter tool.
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 coverage is 100% (all parameters described). The description adds value beyond schema by explaining that 'definitionJson' is a Logic Apps workflow JSON and that 'connectionReferencesJson' should be omitted for connector-less flows, enhancing semantic understanding.
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?
The description clearly states 'Create a new cloud flow,' which is a specific verb+resource pairing. It distinguishes from sibling tools like delete, update, and list flows.
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 when to use (creating flows) and when not to rely on auto-created connections, directing users to 'list-connections' for existing connections. Also covers connector-less flows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a flow permanently. This cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| flow | Yes | The flow internal name (a GUID) | |
| environment | No | Environment id (defaults to POWER_AUTOMATE_ENV) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds the key behavioral trait of permanence but omits other details like authorization or cascading effects.
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?
Two succinct sentences with no unnecessary information; every word adds value.
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?
For a simple delete operation, the description effectively communicates the main effect and irreversibility; could mention impact on runs or associated data but is still adequate.
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?
Both parameters are fully described in the input schema (100% coverage), so the description adds no additional meaning 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?
The description clearly states the action 'Delete a flow permanently' and emphasizes irreversibility, distinguishing it from sibling tools like disable or update.
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?
The description implies final removal via 'cannot be undone' but does not explicitly recommend when to use this tool versus alternatives like disable-flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disable (stop) a flow so its triggers stop firing. Sets state to Stopped.
| Name | Required | Description | Default |
|---|---|---|---|
| flow | Yes | The flow internal name (a GUID) | |
| environment | No | Environment id (defaults to POWER_AUTOMATE_ENV) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full transparency burden. It only states basic effects (stop triggers, set state to Stopped) but does not disclose reversibility, impact on ongoing runs, or required permissions.
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?
Single sentence, front-loaded key action. Very concise with no wasted words, though could include slightly more context without becoming verbose.
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?
For a simple disable action, the description is adequate but misses edge cases (e.g., default environment, behavior if already stopped, error conditions). Output schema is absent but not critical for this tool.
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 coverage is 100% (both parameters have descriptions). The description adds no new information beyond the schema, so baseline of 3 applies.
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?
The description clearly states the verb 'disable (stop)' and the resource 'a flow', and explains the effect: triggers stop firing and state becomes Stopped. This distinguishes it from sibling tools like enable-flow.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., enable-flow, delete-flow). No prerequisites, permissions, or scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable (start) a flow so its triggers fire. Sets state to Started.
| Name | Required | Description | Default |
|---|---|---|---|
| flow | Yes | The flow internal name (a GUID) | |
| environment | No | Environment id (defaults to POWER_AUTOMATE_ENV) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It discloses that the tool sets state to 'Started' and enables triggers, but does not mention idempotency, permissions, side effects, or behavior when the flow is already enabled. This is adequate but not comprehensive.
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?
The description is extremely concise, consisting of two short sentences that convey the essential information with no redundancy or extraneous text. Every word contributes meaning.
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?
For a simple enable action with no output schema, the description adequately covers the primary behavior. It lacks details about error conditions, prerequisites (e.g., flow must exist), or state transitions when the flow is already enabled, but these are minor omissions given the tool's simplicity.
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?
The input schema already provides descriptions for both parameters (100% coverage). The tool description adds no additional semantic information about the parameters beyond what the schema offers, so the baseline score of 3 is appropriate.
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?
The description clearly states the verb ('Enable (start)') and the resource ('a flow'), and explains the effect ('so its triggers fire. Sets state to Started'). This differentiates it from the sibling 'disable-flow' tool, which has an opposite purpose.
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?
The description implies usage when wanting to start a flow, but does not explicitly state when to use this tool versus alternatives like 'disable-flow' or 'run-flow'. No when-not-to-use criteria or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full record for one flow, including its workflow definition (triggers + actions) and connectionReferences. Use this before update-flow.
| Name | Required | Description | Default |
|---|---|---|---|
| flow | Yes | The flow internal name (a GUID, from list-flows) | |
| environment | No | Environment id (defaults to POWER_AUTOMATE_ENV) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that it returns the full record including definition and connectionReferences, indicating a read-only safety profile. No contradictions.
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?
Two succinct sentences: first states purpose and key returned fields, second gives usage guidance. No unnecessary words.
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 no output schema, the description adequately describes what is returned and provides context for use (pre-update). Could mention error cases or permission requirements, but sufficient for a simple read tool.
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 coverage is 100% with clear parameter descriptions. The tool description does not add additional meaning beyond what the schema already provides for parameters, so baseline 3 is appropriate.
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?
The description clearly states it gets the full record for one flow, including its workflow definition and connectionReferences, and explicitly says to use it before update-flow, distinguishing it from siblings like get-flow-definition.
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?
The description gives explicit guidance: 'Use this before update-flow'. It does not list exclusions or alternatives, but the context of siblings implies when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get just the workflow definition (triggers + actions JSON) for one flow, for inspecting/editing logic without the surrounding metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| flow | Yes | The flow internal name (a GUID, from list-flows) | |
| environment | No | Environment id (defaults to POWER_AUTOMATE_ENV) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description covers that output is triggers+actions JSON without metadata, but lacks details on error handling, authentication, or format.
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?
Single sentence, 20 words, front-loaded with purpose, no extraneous information.
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?
For a simple retrieval tool with 2 parameters and no output schema, the description sufficiently explains the return value, though could mention error cases.
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 provides 100% coverage with clear descriptions for both parameters (flow GUID and environment ID). Description adds no additional parameter meaning.
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?
The description clearly states the tool retrieves the workflow definition (triggers + actions JSON) for inspecting/editing logic without metadata, distinguishing it from siblings like get-flow which returns full flow.
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?
Description indicates use for inspecting/editing logic without metadata, implying distinction from get-flow, but does not explicitly list alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full record for one run, including status and any top-level error.
| Name | Required | Description | Default |
|---|---|---|---|
| run | Yes | The run id (from list-runs) | |
| flow | Yes | The flow internal name (a GUID) | |
| environment | No | Environment id (defaults to POWER_AUTOMATE_ENV) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses returning 'full record' with status and top-level error, but does not explain what the full record includes, auth requirements, or any potential side effects. Minimal but adequate.
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?
The description is a single, clear sentence with no unnecessary words. It is appropriately sized and front-loaded.
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?
For a simple get operation with no output schema, the description mentions the key return elements (status, top-level error). It could be more detailed about the record structure, but it is mostly complete given the tool's simplicity.
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 coverage is 100%, and the description adds no additional meaning beyond the schema's parameter descriptions. The baseline of 3 is appropriate since the schema already documents the parameters sufficiently.
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?
The description clearly states 'Get the full record for one run, including status and any top-level error.' It uses a specific verb (Get) and resource (run record), and distinguishes from siblings like list-runs (which lists runs) and get-flow (which gets flow details).
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?
The description implies use when needing a single run's full record, but provides no explicit guidance on when to use this tool versus alternatives like list-runs or list-run-actions. No when-not-to-use or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the connector connections in an environment (id, connector, display name, status). Use these ids to build the connectionReferences for create-flow / update-flow -- e.g. the shared_office365 connection for mail/calendar Graph calls.
| Name | Required | Description | Default |
|---|---|---|---|
| environment | No | Environment id (defaults to POWER_AUTOMATE_ENV) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It implies a read-only list operation but does not mention any potential side effects, authentication requirements, rate limits, or pagination. The simple nature of listing connections mitigates some concerns, but more transparency would improve the score.
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?
The description is extremely concise: two sentences that front-load the core purpose and then provide a usage hint. Every sentence adds value without redundancy.
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 low complexity (one optional parameter, no output schema, no nested objects), the description covers the essential purpose and usage. The first sentence lists return fields, which partially compensates for the lack of an output schema. However, it could mention the return type or any pagination behavior for completeness.
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 coverage is 100% for the single optional parameter 'environment', which already has a description. The tool description does not add additional semantic information about the parameter beyond what is in the schema, so baseline 3 is appropriate.
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?
The description clearly states it lists connector connections and specifies the fields returned (id, connector, display name, status). While it doesn't explicitly distinguish from sibling list tools like list-flows, the resource is uniquely identified, making purpose clear.
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?
The description explicitly says to use the ids for create-flow / update-flow and provides a concrete example (shared_office365 connection). This gives clear guidance on when and why to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Power Platform environments you can access (id, display name, isDefault). Use the returned name as the environment for flow tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a read-only list operation and specifies the output fields, offering adequate transparency for a simple tool. It does not mention potential edge cases like empty results, but the core behavior is clear.
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?
The description is two sentences, each earning its place. The first sentence states purpose and output, the second provides a critical usage hint. No redundancy or unnecessary detail.
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 simplicity (no parameters, no output schema), the description fully covers what the agent needs: what it does, what it returns, and how to use the result with related tools.
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?
The input schema has zero parameters, and the description appropriately does not add parameter information. Following the baseline guideline for 0 parameters, the score is 4.
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?
The description clearly states the tool lists all accessible Power Platform environments, specifying the returned fields (id, display name, isDefault). It distinguishes from sibling tools that are all flow-related, making the purpose 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?
The description explains how to use the returned `name` as the `environment` for flow tools, providing clear post-usage guidance. While there are no alternative tools to compare, it lacks explicit pre-usage conditions but is still highly informative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List cloud flows in an environment (internal name, display name, state, trigger summary). State 'Started' = enabled, 'Stopped' = disabled.
| Name | Required | Description | Default |
|---|---|---|---|
| environment | No | Environment id (defaults to POWER_AUTOMATE_ENV) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds value by explaining state mappings, but it does not disclose behavioral traits such as whether the operation is read-only, if pagination exists, rate limits, or authentication requirements. For a list operation with zero annotations, more transparency is needed.
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?
The description is concise with two sentences that front-load the purpose and state mapping. Every sentence adds value, though it could be slightly more structured (e.g., bullet points).
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?
For a list tool with one optional parameter and no output schema, the description covers the key points: what is listed, which fields, and state interpretation. However, it lacks information on pagination or whether all flows are returned, and it does not reference related sibling tools like 'list-environments' to explain the environment 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?
The input schema has 100% description coverage with a single parameter (environment) already well-documented. The description does not add any further meaning beyond the schema, such as format or how to obtain the ID. Baseline 3 is appropriate.
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?
The description clearly states what the tool does: 'List cloud flows in an environment' and specifies the fields returned (internal name, display name, state, trigger summary). It also explains state meanings. However, it does not explicitly distinguish from siblings like 'get-flow' (which retrieves a single flow) or 'list-flow-triggers', so it falls short of a 5.
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?
No explicit guidance on when to use this tool versus alternatives. It mentions the environment parameter defaults but provides no exclusions or context for when not to use it. This leaves the agent without clear decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a flow's triggers (name + type). Use the trigger name with run-flow.
| Name | Required | Description | Default |
|---|---|---|---|
| flow | Yes | The flow internal name (a GUID) | |
| environment | No | Environment id (defaults to POWER_AUTOMATE_ENV) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. However, it only states what the tool does, not how it behaves (e.g., idempotency, pagination, ordering, side effects). Critical details like authentication, rate limits, or whether it returns all triggers are missing.
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?
The description is extremely concise with two short sentences. The first sentence states the primary action, and the second provides follow-up guidance. No unnecessary words or repetition; every sentence earns its place.
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 that this is a simple listing tool with only two parameters and no output schema, the description is fairly complete. It conveys the purpose and a usage hint. However, it could be more complete by briefly noting the output structure or default behavior, but it is sufficient for a straightforward tool.
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?
The input schema has 100% coverage, so the description does not need to add much. It adds no extra meaning beyond the schema—e.g., it doesn't explain that 'flow' is a GUID or how to find it. Baseline 3 is appropriate as the schema does the heavy lifting.
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?
The description clearly states 'List a flow's triggers (name + type)', specifying the verb (list), the resource (flow's triggers), and what is returned (name + type). It is specific and unambiguous, effectively distinguishing from sibling tools which cover other operations on flows.
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?
The description includes a direct usage hint: 'Use the trigger name with run-flow.' This tells the agent what to do with the output. While it doesn't explicitly contrast with sibling tools, the context of sibling tools and the nature of the tool makes it clear when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the per-action results of a run (status + inputsLink/outputsLink SAS URLs). This is the main way to debug a failed run: find the failed action and inspect its inputs/outputs via the SAS links.
| Name | Required | Description | Default |
|---|---|---|---|
| run | Yes | The run id | |
| flow | Yes | The flow internal name (a GUID) | |
| environment | No | Environment id (defaults to POWER_AUTOMATE_ENV) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose more traits. It only mentions return content but lacks information about side effects, permissions, or limits.
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?
Two concise sentences, front-loaded with purpose, no fluff.
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 complexity and lack of output schema, the description should provide more details about the response format or limitations. It is minimally complete.
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 coverage is 100%, and the description adds no additional parameter-level meaning beyond the schema. It does provide context for the tool's purpose.
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?
The description clearly states 'List the per-action results of a run' and explains the use case for debugging. It distinguishes from sibling tools like list-runs.
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?
The description provides clear context for when to use (debugging a failed run) but does not explicitly mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent runs of a flow (status, start/end time, error). Use this as a health probe -- a latest Failed run or a stale newest startTime means the flow has silently died.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | Max runs to return (default 20) | |
| flow | Yes | The flow internal name (a GUID) | |
| environment | No | Environment id (defaults to POWER_AUTOMATE_ENV) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns recent runs with key fields and implies ordering by startTime. It could be more explicit about sorting and pagination, but it is adequate for the intended health-probe usage.
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?
Two sentences with no filler. The first sentence states the core functionality, and the second provides a concrete use case. Every word serves a purpose.
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 simplicity of the tool, the description covers purpose, usage, and provides a health-probe scenario. It omits details about output structure or error handling, but the lack of an output schema means some burden remains. Still, it is reasonably complete for the task.
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 coverage is 100%, so all parameters have descriptions. The description adds no additional parameter-level meaning beyond the schema, which is the baseline for high coverage. No extra context for 'top', 'flow', or 'environment'.
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?
The description clearly states the verb 'list' and the resource 'recent runs of a flow', specifying the fields (status, start/end time, error). It distinguishes itself from sibling tools like 'get-run' (single run) and 'list-flows' (lists flows).
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?
The description explicitly positions the tool as a health probe with a specific scenario (latest Failed run or stale newest startTime indicates a dead flow). While it does not explicitly list alternatives, the use case is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger a flow on demand. The trigger name is usually 'manual' (button/instant flows) or 'Recurrence' (scheduled flows) -- use list-flow-triggers if unsure.
| Name | Required | Description | Default |
|---|---|---|---|
| flow | Yes | The flow internal name (a GUID) | |
| environment | No | Environment id (defaults to POWER_AUTOMATE_ENV) | |
| triggerName | No | Trigger to fire (default 'manual') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must disclose behavior. It only says 'trigger a flow on demand' without detailing side effects, permissions, rate limits, or what happens on failure. Minimal behavioral info beyond the action itself.
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?
Two concise sentences. First states purpose, second provides parameter guidance. No unnecessary words or repetition. Front-loaded and efficient.
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?
Covers purpose and parameter hints adequately for a tool with 3 params and no output schema. However, lacks expected return value (e.g., run ID or status) and error handling notes, leaving the agent slightly uncertain.
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 covers 100% of parameters with descriptions. Description adds value by explaining typical triggerName values and recommending list-flow-triggers for clarity, enhancing understanding beyond schema alone.
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?
The description clearly states the tool triggers a flow on demand, using a specific verb and resource. It mentions trigger names but does not explicitly differentiate from sibling tools like enable-flow or disable-flow, though context implies it.
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?
Provides direct guidance on when to use (trigger a flow manually) and includes specific advice on trigger name values ('manual' for button/instant, 'Recurrence' for scheduled). Suggests list-flow-triggers as a fallback, helping agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a flow by PATCHing its properties. Provide the FULL desired properties object (displayName, state, connectionReferences, definition) as JSON -- a typical edit is get-flow, tweak properties, send them back here.
| Name | Required | Description | Default |
|---|---|---|---|
| flow | Yes | The flow internal name (a GUID) | |
| environment | No | Environment id (defaults to POWER_AUTOMATE_ENV) | |
| propertiesJson | Yes | The flow's `properties` object as a JSON string |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals that the operation is a PATCH (implying mutation) and requires the complete properties object. It adds transparency by describing the exact workflow (get then update), but lacks details on error handling or effects on omitted fields.
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?
Two sentences, no redundancy. The first sentence states the action clearly, and the second provides a concrete usage example. Every word is meaningful.
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?
The description covers the main use case and parameter context, but lacks information about the return value (no output schema) and error scenarios. For a mutation tool, mentioning what the tool returns or potential errors would improve completeness.
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%, so baseline is 3. The description adds value by listing typical fields within propertiesJson (displayName, state, connectionReferences, definition) that are not in the schema description, aiding the agent in constructing the JSON.
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?
The description clearly states it updates a flow via PATCH, using specific verb and resource. It distinguishes from siblings like create-flow, delete-flow, and enable/disable by implying modification of existing properties. The example pattern of get-flow then tweak reinforces its purpose.
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?
The description explains when to use this tool via the typical edit pattern and emphasizes providing the FULL properties object. However, it doesn't explicitly advise against using it for enabling/disabling flows, which have dedicated sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0create-flowdelete-flowdisable-flowenable-flowget-flowget-flow-definitionget-runlist-connectionslist-environmentslist-flow-triggerslist-flowslist-run-actionslist-runsrun-flowupdate-flowScored across 15 tools
Each tool targets a distinct operation: CRUD on flows, enable/disable, listing flows/runs/connections/environments, and triggering. No overlap; get-flow and get-flow-definition serve different granularity needs.
All tools follow a consistent verb_noun pattern with hyphens (e.g., create-flow, list-connections, run-flow). No mixed conventions or irregular names.
15 tools is well-scoped for a Power Automate server, covering flow lifecycle, run inspection, environment/connection queries, and on-demand triggering without unnecessary duplication.
Covers full CRUD, enable/disable, flow run management, and environment/connection listing. Missing only connection creation (by design) and potentially flow sharing or permissions, but core flow operations are complete.
Debug, build, and manage Power Automate cloud flows with AI agents
Discover, preview, estimate, run, and retrieve reusable AI workflows.
Build and manage Cloudgate workflow-APIs: controllers, actions, workflow graphs, and databases.
Give your AI agents the tools to build, manage, and run automation workflows.
