-
Notifications
You must be signed in to change notification settings - Fork 21.9k
[Logic Apps] Update doc to include multiple MCP servers #127851
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -23,6 +23,9 @@ ms.update-cycle: 180-days | |||||
|
|
||||||
| Typically, large language models (LLMs) work with AI agents that handle and fulfill requests by using prebuilt *tools* that agents call to complete tasks, like send an email, query a database, or trigger a workflow. In Azure Logic Apps, you can jumpstart building these tools by reconfiguring a Standard logic app as your own *remote* Model Context Protocol (MCP) server. This capability means that you can expose existing workflows as tools that LLMs, AI agents, and MCP clients can use to interact with enterprise resources and assets. In this context, *remote* means that the MCP server runs outside the environment where the interface for your AI agent interface. | ||||||
|
|
||||||
| You can now configure multiple MCP servers within a single Standard Logic App. | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We never capitalize "logic app".
Suggested change
|
||||||
| This new approach provides a more scalable, organized, and flexible way to expose workflows as tools to large language models (LLMs), AI agents, and MCP clients. Each MCP server acts as an independent grouping of workflows that can be discovered and called separately from your MCP client. | ||||||
|
Comment on lines
+26
to
+27
|
||||||
|
|
||||||
| MCP is an open standard that lets LLMs, AI agents, and MCP clients work with external systems and tools in a secure, discoverable, and structured way. This standard defines how to describe, run, and authenticate access to tools so agents can interact with real-world systems like databases, APIs, and business workflows. Consider an MCP server as a bridge between an LLM, AI agent, or MCP client and the tools they use. | ||||||
|
|
||||||
| For example, suppose you have a Standard logic app-based MCP server that runs in Azure. On your local computer, Visual Studio Code has an MCP client that you use to remotely connect to your MCP server. This scenario differs from local MCP servers that run on your computer. The following diagram shows relationships between the different components at work in this scenario: | ||||||
|
|
@@ -51,6 +54,7 @@ The following table describes the benefits that you get when you set up Standard | |||||
| | Access points | Azure Logic Apps supports different connectivity models for running your MCP server. You can run your server in the cloud, expose your server as a private endpoint, or connect to virtual networks and on-premises resources. | | ||||||
| | Security | When you expose your logic app as an MCP server, you set up a strong security posture so you can meet your enterprise security requirements. By default, MCP endpoints use [OAuth 2.0](/entra/identity-platform/v2-oauth2-auth-code-flow) for authentication and authorization. For more information, see [What is OAuth](https://www.microsoft.com/security/business/security-101/what-is-oauth)? <br><br>You can use *Easy Auth* to secure your MCP server and Standard workflows. Easy Auth is the current name for the native authentication and authorization features in Azure App Service, Azure Functions, and Azure Container Apps. For more information, see [Authentication and authorization in Azure App Service and Azure Functions](../app-service/overview-authentication-authorization.md). | | ||||||
| | Monitoring, governance, and compliance | Azure Logic Apps provides workflow run history and integration with Application Insights or Log Analytics so you get the data necessary to manage and monitor your MCP server tools and support diagnostics, troubleshooting, reporting, traceability, and auditing. | | ||||||
| | Scalability | Host multiple logical MCP servers within a single Logic App, each grouping related workflows. | | ||||||
|
|
||||||
| Standard logic app based MCP servers support the [Streamable HTTP and Server-Sent Events (SSE) transports for MCP](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports). | ||||||
|
|
||||||
|
|
@@ -280,19 +284,60 @@ Now set up Easy Auth authentication on the Standard logic app that you want to u | |||||
|
|
||||||
| Now, continue on to set up your logic app as an MCP server. | ||||||
|
|
||||||
| ## Set up logic app as MCP server | ||||||
| ## Set up MCP servers in a logic app | ||||||
|
|
||||||
| For this task, you need to edit the **host.json** file for your Standard logic app resource. | ||||||
|
|
||||||
| 1. In the [Azure portal](https://portal.azure.com), open your Standard logic app resource. | ||||||
|
|
||||||
| 1. On the resource sidebar, under **Development Tools**, select **Advanced Tools** **>** **Go**. If prompted, consent to leaving the Azure portal. | ||||||
| 1. For this task, you need to create the **mcpservers.json** file for your Standard logic app resource. This file holds your configuration for MCP servers. | ||||||
|
|
||||||
| 1. On the **Kudu** toolbar, from the **Debug console** menu, select **CMD**. | ||||||
|
|
||||||
| 1. From the directory table, go to the following folder: **site/wwwroot** | ||||||
|
|
||||||
| 1. Next to the **host.json** file, select the edit icon (pencil). | ||||||
|
|
||||||
| 1. If a **mcpservers.json** file doesn’t already exist, create a new one: | ||||||
| - Select the `New File` icon, and name it `mcpservers.json`. | ||||||
|
||||||
| - Select the `New File` icon, and name it `mcpservers.json`. | |
| - Select the **New File** icon, and name it `mcpservers.json`. |
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This info appears too early in the introduction because the reader is just learning about MCP servers and disrupts the reading flow with "feature" info. Also, related sentences should appear on the same numbered "line", not separate lines.
You changed the "single MCP" scenario to a "multi-MCP" scenario. What if the customer just wants one MCP? Do they follow the same directions but define only one MCP server? Or, do they follow different directions for a single MCP server? If the steps are different, you need to have both sets of steps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no the steps are the same, we now suggest using this approach rather than the older one