Stop Writing Plumbing! Use the New Logic Apps MCP Server Wizard

As part of our continued investment in making Logic Apps a first‑class platform for providing AI agents with connectivity, we’ve introduced the new Logic Apps MCP server configuration experience—a guided, in‑portal workflow that lets you turn any existing Standard logic app into a fully functional MCP server. With just a few clicks, you can configure authentication, generate API keys, create or manage MCP servers, and convert workflows into discoverable MCP tools that agents can call securely and reliably. This experience consolidates everything you need: setup, tooling, and management into one intuitive surface so developers can focus on building meaningful agentic capabilities instead of wiring up protocol plumbing.

This new experience builds upon our previous investments with API Center and the Microsoft Foundry tools catalog that introduced the ability to dynamically build MCP servers through a publishing wizard experience that leveraged Azure Logic Apps connectors. The investments made with API Center and Microsoft Foundry enabled the underlying platform components that make Logic Apps workflows accessible over the MCP protocol as MCP tools. What we have subsequently invested in is the ability to enable any existing Logic Apps Standard instance as an MCP server.

Core Capabilities

From an existing Logic Apps Standard instance, you will now discover a new section in our table of contents called Agents. Within this section, you will find an entry point called MCP servers. If you click on this link, our configuration experience will load. This experience will provide you with the option to create an MCP server using existing workflows or by creating new workflows.

Create new workflows

Using this option, allows us to dynamically build MCP tools using the Logic Apps managed connectors, much like we provide in API Center and Microsoft Foundry.

You will start by providing:

• MCP Server Name
• MCP Server Description

 

Once this information has been provided, we can select a connector that we would like to use in our MCP server like the Salesforce connector.

With our connector selected, we can choose one or more actions. For each action that is selected, a corresponding workflow will be created that enables that connector to be called. For our use case, we will select Create record, Update record and Get Opportunity records from Salesforce.

To connect to Salesforce, we need a connection so we will create that now

If we scroll down, we will discover that we have some actions that require configuration including Create record and Update record. The reason for this is due to the design of the Salesforce connector and its support for may different Salesforce object types. Salesforce has many object types and delegating this decision to a model will result in a lot of unpredictable behavior. We can increase the consistency of our MCP server by making it more specific.

To improve our predictability, we will target a specific object type of Contacts. With this selected, we will also be able to choose which fields we want our model to populate. For any fields that we want to hardcode, we can specify a provided by value to be set to User.

It is also a good practice to update the Description of our action to ensure we have something meaningful so that our model can achieve higher accuracy when trying to call it.

 

To complete our process, click the Register button. Once this is clicked, the related workflows will be automatically get created for us. These underlying workflows will have Request trigger schemas provided and configuration that will wire-up these inputs into our action.

 

Once the registration process is complete, we will see a notification in the upper fight corner indicating that our tools (workflows) have been saved.

We will now see our MCP Server created with the corresponding workflow tools. From this experience, there are multiple functions that we can access from this screen including:

• Editing MCP Server Name and Description
• Adding/removing workflows for this MCP server
• Copy the MCP Server URL
• Delete MCP Server

o   The underlying workflows will remain, even if the MCP Server is deleted.

If we want to explore one of our workflow tools, we can click on the link and we will be navigated to the underlying workflow. If we want to make changes to this workflow, we are able to do so, including adding additional connectors (managed or built-in), business logic, custom code etc.

As we explore this workflow we will discover that we have a trigger schema that is included and we have our Salesforce action mapped. This was all completed by the wizard experience that we just went through. We can now secure and test our MCP server, as discussed later in this article.

 

Use existing workflows

You may already have workflows built that you want to expose as MCP tools. With this requirement in mind, we can support these use cases by selecting: Use existing workflows option.

Once again, we will provide an MCP server Name and Description. With these values provided, we can select one or more existing workflow(s) to be included in this MCP Server.

In order for a workflow to be eligible for selection it must satisfy the following conditions:

• HTTP Trigger
• HTTP Response Action

You have a lot of creative licensing for whatever actions you want to include between these actions. This can include calling APIs, custom code, built-in connectors and additional business logic.

Note: Using this approach also allows you to create a workflow with your own naming conventions in place and support for advanced scenarios.

I have built the following workflow which includes my trigger, ServiceNow action and a response. To optimize our model reliably calling my MCP Server, I have:

• Added a relevant description for my trigger. This will communicate to the model what this workflow (tool) is able to provide.
• Within my trigger, provided a JSON schema and included description fields that communicate to the model what these data properties provide.

 

Once we have provided a Name and Description, we can now select our workflow(s) and click Create button.

We now have two MCP servers that are hosted in this Logic App. Each MCP server will have a unique URL, but will share the same security scheme.

Authentication

There are two authentication schemes that are available for MCP servers:

• API Key-based
• OAuth

Note: It is important to know that these authentication schemes apply to the entire Logic App and not the individual MCP Servers/tools.

API key-based authentication

When we select Key-based from our method dropdown, we have the ability to generate keys by clicking on the Generate key button. From there, select a Duration and an Access Key, followed by clicking on the Generate button.

An API key will be presented for which you can copy this value.

Note: When you navigate away from this page, you will not be able to see this value again, so store it in a safe place. However, you can generate additional API keys. Prior API keys will continue to be valid until their expiration date is no longer valid or the access keys are regenerated.  Regenerating access keys will be available in a future release, but are available via an API call.

OAuth Authentication

Here we are going to take advantage of EasyAuth authentication for Azure Logic Apps. We will start by clicking on the Manage authentication link.

From there we will click on the Add identity provider button.

Select Microsoft as the identity provider, followed by clicking the Add button.

We will now need an App Registration, so in a separate tab navigate to App registrations in the Azure Portal.

 

Start by providing a Name and select the desired account types.

Click on Expose an API

Add a Scope and provide relevant data

Navigate to the Overview page and then copy the values for:

• Application (client) ID
• Directory (tenant) ID
• Application ID URI

Back in our Logic Apps, Add an identity provider and provide the following information from our App Registration:

• Application (client) ID
• Issuer URL https://login.microsoftonline.com/<Your_Tenant_ID>/v2.0
• Allowed token audiences (Application ID URI) api://<your_value>/

In the Additional checks section, enable the following:

• Allow requests from any application
• Allow requests from any identity
• Use default restrictions based on issuer

For the App Server authentication settings, enable unauthenticated access.

 

Note: These settings can be modified to address your organization’s specific needs.

 

Click Add to complete the configuration

 

Testing

You are now ready to test your MCP server from your favorite agent platform including VS Code, Copilot Studio, Microsoft Foundry or Azure Logic Apps. If you are using an API key, you will be asked to create an authentication header. In this case you will want to use: X-API-KEY and then provide your key value.

 

Known issue: We have seen some situations that when using OAuth, the Easy Auth settings need to be re-applied to address an authentication error from occurring. Issuing the following command from a Cloud shell should address the problem and allow you to authenticate using Easy Auth.

az webapp auth microsoft update --name "<LogicAppName>" --resource-group "<Your_ResourceGroup>" --client-id "<Your_Client_ID>" --issuer "https://login.microsoftonline.com/<tenant>/v2.0"

Video content

Want to see this content in video format? Check out the following video.