Turn Logic Apps workflows into MCP tools

Learning objective

Expose Azure Logic Apps workflows and connectors as MCP tools.

Core idea

An enterprise connector action becomes useful to an agent when it has a discoverable tool contract and a controlled execution path. Azure Logic Apps can expose workflows through a remote Model Context Protocol (MCP) server. The workflow performs the integration; the MCP interface describes what the agent can request.

Native MCP server creation from Standard workflows is a preview feature. Its documented hosting options are Workflow Service Plan and App Service Environment v3. Do not assume that every Logic Apps hosting option or a Consumption workflow qualifies. The API Center workflow-backed creation path is also documented as preview.

For an architect, the central decision is what business operation to expose. A useful tool describes a bounded capability, such as retrieving an invoice status. Publishing every connector operation gives the agent a much larger action surface than that business task requires. See 2.3.1 for typed tool contracts and 2.3.3 for the transport model.

How it works

Choose a qualifying workflow

The native Standard path accepts workflows that start with the Request trigger named When an HTTP request is received and end with a Response action. The logic app resource must be running, and the workflow must be enabled. This is a request-response tool contract, not an instruction to expose any existing background automation unchanged.

The MCP servers interface offers Use existing workflows and a path to create workflows from connector actions. Use existing workflows when they already implement the operation with the required trigger and response. Use generated workflows when you need to turn selected connector actions into tools. Each selected action creates a workflow that acts as a tool; the connector itself is not a single universal tool.

Keep the tool’s public meaning narrower than the implementation. A workflow might combine lookup, normalization, and response construction, while exposing only one business request. Prefer a separate mutation tool when changing external state requires a different authorization or approval policy. Tool compatibility and side-effect approval are covered in 2.3.9.

Choose API Center for connector discovery

The preview API Center path starts at the API center resource under Discovery › MCP › Azure Logic Apps › Register. It creates and registers a workflow-backed server that consumers can discover through the API Center portal. Choose this path when centralized discovery is part of the connector offering, rather than only exposing existing qualifying workflows from the logic app.

This path supports Standard logic apps on any hosting option, but the logic app and API center must share a subscription. It accepts one connector per MCP server and one action per tool, and excludes built-in service-provider-based and custom connectors. Those limits differ from the native workflow path; do not combine their hosting and connector assumptions.

Describe the operation and its inputs

Add a description to the Request trigger and define Request Body JSON Schema. The schema’s description attributes explain individual inputs, while required identifies mandatory parameters. Descriptions help tool selection; the schema defines the expected request shape. Neither substitutes for business validation inside the workflow.

For example, describe an invoice identifier as the identifier issued by the accounting system, rather than a free-form invoice description. State whether an attachment parameter expects a base64-encoded string. Ambiguous descriptions create apparently valid calls that refer to the wrong object or encode content incorrectly.

For action-backed tools, inspect Description, Default parameters, and Optional parameters. A default description comes from the connector’s API Swagger description, so review whether it expresses your business operation. Include optional inputs only when the agent needs to control them; every exposed choice adds another value that requires validation.

The documented parameter sources are Model and User. Model supplies values dynamically from the conversation at runtime. User supplies development-time static values that stay the same across interactions. Here, “User” does not mean asking the person in the chat to approve each invocation. The label identifies the source of the configured value.

Use static values for a fixed integration target, such as a designated notification destination, when that fits the operation. Let the model supply task-specific values such as an invoice identifier. A static target reduces agent discretion, but it does not establish that a caller is allowed to act on every identifier supplied to the workflow.

Secure the MCP entry point

The native MCP setup supports Key-based and OAuth authentication. For keys, Generate MCP API key asks for a Duration and a Primary key or Secondary key. Save the generated key securely because the interface does not let you retrieve it afterward. Treat possession of that credential as an access decision, not as confirmation of a particular email or update.

The OAuth path uses a Microsoft Entra app registration and App Service authentication, also called Easy Auth. Its configuration includes Allowed token audiences, Allowed client applications, Allowed identities, and the tenant requirement. These settings express which token target, calling applications, users, and tenant are accepted.

Follow the MCP-specific Easy Auth guidance: its setup explicitly selects Allow unauthenticated access in App Service authentication settings, alongside the MCP server’s OAuth configuration. Do not replace that instruction with a generic App Service recipe or interpret it as permission to skip MCP authentication. Test the server’s selected authentication method with both accepted and rejected callers.

Keep the MCP caller and connector connection conceptually separate. Authenticating an MCP request does not, by itself, prove which downstream records the workflow should access. Review the connection and business checks used by the selected action. The public tool should enforce the operation you intend, even if the integration credential can perform more work.

Observe execution rather than discovery alone

Successful tool discovery proves that the client can obtain a tool definition. It does not prove that the connector connection works, the arguments map correctly, or the Response action returns a useful result. Test a representative invocation and inspect workflow run history. Logic Apps also provides integration with Application Insights or Log Analytics for diagnostics and traceability.

Include negative cases: a missing required input, an unknown business identifier, an unauthorized caller, and a downstream failure. Keep response validation separate from transport success; see 2.3.10. Bound connector retries before adding another retry loop around the MCP call; see 2.3.8.

Key distinctions and trade-offs

Workflow versus connector: The workflow is the exposed tool implementation. A connector supplies actions the workflow executes. Select actions deliberately instead of treating the connector catalog as an agent permission list.

Model versus User input: Model values vary with the conversation. User values in this setup are static development-time configuration. Neither label denotes per-call human approval.

Native server versus gateway: Logic Apps hosts the workflow-backed MCP server. API Management can expose and govern that existing server; see 2.3.7. Adding a gateway does not remove the workflow’s preview status or validate its business behavior.

Architecture / decision scenario

An accounts team wants an assistant to retrieve invoice status and send a notification to a fixed finance mailbox. It has a qualifying Standard workflow for invoice lookup and needs a separate action-backed notification workflow.

The architect selects the lookup workflow and generates the notification tool from the chosen connector action. The invoice identifier is required in Request Body JSON Schema. The notification destination uses User static configuration, while the message content uses Model input. The two tools receive distinct descriptions so the assistant can distinguish reading a status from sending a message. If centralized connector discovery is required, the team considers API Center registration instead, checking the shared subscription and its one-connector, one-action limits.

The team configures OAuth with the intended audience, client applications, identities, and tenant, and tests rejected callers as well as authorized ones. It separately enforces per-invoice access inside the integration and requires approval for the notification. Run history confirms that an invocation reaches the correct action and Response. Preview acceptance is a deployment decision; the architecture does not silently relabel native MCP exposure as generally available.

Common exam traps

• Assuming the native Standard workflow path applies to Consumption or every hosting option.
• Assuming the API Center path accepts several connectors or custom connectors.
• Exposing a workflow without the required Request trigger and Response action.
• Reading User parameter sourcing as runtime approval by the chat user.
• Treating OAuth admission as proof of downstream record authorization.
• Equating successful discovery with successful connector execution.

What to remember

Expose selected business operations through qualifying Standard request-response workflows. Define clear inputs, distinguish dynamic model values from static configured values, and test authentication and execution independently. Native Logic Apps MCP creation is preview; connector access and side-effect approval remain separate decisions.

Knowledge check

References

• Microsoft, Create remote MCP servers from Standard workflows.
• Microsoft, Create MCP servers driven by workflows.
• Microsoft, Connect and govern existing MCP server.