The new Power Automate MCP Server turns your flows into agent tools

Did you know that Power Automate can now publish your flows as an MCP server — turning each flow into a tool that any AI agent can discover and call?

This is one of the most important shifts in Power Automate since it stopped being called Microsoft Flow. Instead of an agent needing a hand-built connector for every automation, your flow becomes a standards-based tool that Copilot Studio, Azure AI, and any Model Context Protocol client can invoke directly.

What MCP actually gives you

The Model Context Protocol (MCP) is an open standard for how AI models talk to external tools and data. Think of it as a universal contract: an MCP server exposes a list of typed tools — each with a name, a description, and a JSON Schema for its inputs and outputs — and any MCP-compatible client can call those tools without bespoke integration work.

When you publish a Power Automate flow as an MCP server, the platform does the hard part for you:

• The flow’s inputs become the tool’s input schema.
• The flow’s response becomes the tool’s output schema.
• The name and description you write tell the agent when to use it.

You supply the plain-language description and the parameter names. Power Automate handles the schema serialization and hosts the MCP endpoint.

Why this matters more than another connector

Your automation logic becomes reusable by any agent

An approval flow, a “create a ticket” flow, a “look up an order” flow — each becomes a named capability in an agent’s toolbox. The same MCP server can be consumed by a Copilot Studio agent today and an Azure AI agent tomorrow, because they all speak the same protocol.

No custom integration code

Before MCP, wiring an agent to your automation meant custom connectors, HTTP actions, and glue code. Now the agent reads the tool manifest, sees the typed inputs, and calls the flow with structured arguments — getting structured results back.

The agent decides when to act

Because the tool has a clear name and description, the orchestrator can pick it at runtime based on the user’s intent. “Submit this purchase order for approval” maps to your approval flow; “check the status of order 4192” maps to your lookup flow — no hardcoded routing required.

A practical pattern

Say you already have a classic approval flow. To make it agent-callable:

1. Define clean inputs — for example poNumber, amount, vendor, requestorUPN. Clear names become clear tool parameters.
2. Return a structured response — such as decision, approver, and comments — so the agent gets something it can reason over.
3. Write a precise description — “Submit a purchase order for manager approval and return the decision.” This is what the orchestrator matches against.
4. Publish as an MCP server and copy the endpoint URL.
5. Register the endpoint in Copilot Studio (or your Azure AI agent) as an MCP tool.

Now the agent can run real automation — send the approval, wait for the decision, update the record — all through your existing, governed Power Automate logic.

What to watch for

• Descriptions are the routing logic. A tool called “Flow 1” with the description “does stuff” will get misrouted constantly. Treat the name and description as prompt engineering — they are how the agent decides to call your flow.
• Governance still applies. Flows published through MCP run on real connections inside your environment. Data loss prevention (DLP) policies, connection restrictions, and environment boundaries all still apply — plan for them before you publish.
• Keep a human in the loop for high-impact actions. If a flow does something irreversible — sending money, deleting records, emailing customers — build an approval gate into the flow. An agent should never be able to autonomously approve its own request; the approver must be a different identity from the requestor.
• Mind authentication. Make sure the agent invokes the flow under a governed identity with least privilege, not a broad or shared account.

The MCP server support is the moment your Power Automate library stops being a collection of isolated automations and becomes a shared toolbox that every AI agent in your organization can draw on. Start by exposing one well-understood flow, prove the round-trip, then expand — and let your existing automation investment do double duty as agent capabilities.