DEV Community

Cover image for Part 21: Build 4a — Azure: tools with Logic Apps, Functions and API Management
Shakar Bisetty
Shakar Bisetty

Posted on

Part 21: Build 4a — Azure: tools with Logic Apps, Functions and API Management

#azure #ai #mcp #agents

Part 21 · One Agent, Five Platforms

Microsoft shops already have most of the pieces: Logic Apps for workflows, Functions for code, and API Management in front of their APIs. So this part asks one question: how do the same nine tools look on Azure?

Like the MuleSoft, Boomi and SAP builds (Parts 11, 14 and 17), this build is documentation-only. Everything below comes from Microsoft Learn as I read it on 9 November 2026, linked in the text. I haven't run the invoice agent on Azure yet. This part covers only the tools. The agent in Foundry Agent Service, identity, the Teams approval and the scores come in Part 22.

The nine tools on Azure: three hosts behind one API Management gateway

The short answer

Azure gives you three ways to host an MCP tool, and one gateway to put in front of them:

  1. Logic Apps (Standard) can act as a remote MCP server. Each workflow becomes a tool.
  2. Azure Functions has an MCP tool trigger. Each function becomes a tool.
  3. API Management can expose a REST API as an MCP server. Each API operation becomes a tool.

API Management can also sit in front of the first two. That's the shape I'd use: three hosts, one gateway.

Route 1: Logic Apps as an MCP server

The Logic Apps MCP server page describes how a Standard logic app becomes a remote MCP server. It's in preview.

  • A workflow qualifies if it starts with the Request trigger and ends with a Response action.
  • The trigger's description becomes the tool's description. The request body's JSON schema, with its required list, tells the agent what to send.
  • It needs a Workflow Service Plan or App Service Environment v3.
  • Authentication defaults to OAuth 2.0 through a Microsoft Entra app registration and Easy Auth. Generated access keys are the alternative.
  • Streamable HTTP works without extra setup. SSE needs virtual network integration and a host setting.

There's a second, simpler preview: you can build an MCP server from one connector's actions in Azure API Center. It's limited to one connector per server and one action per tool. That's fine for sending an email, but not for a process API.

Logic Apps is strong where a tool is really a small workflow that uses connectors, such as sending a notification or starting an approval.

Route 2: Azure Functions with the MCP tool trigger

Microsoft announced general availability of the Functions MCP extension, including the tool trigger, in November 2025. One of the older reference pages still carries a preview notice, so check the current status before you build.

The tool trigger page is clear on schemas:

  • Each tool has a name, a description and typed properties: string, number, integer, boolean or object, optionally as arrays.
  • Properties are optional by default. The docs say to mark a property as required only if the tool can't work without it. Earlier previews made every property required.

That second point matters for the contract from Part 7. Every required field there has to be marked isRequired on Azure, or the agent can leave it out.

The MCP extension page covers the endpoint. Streamable HTTP is served at /runtime/webhooks/mcp, and SSE is deprecated. In Azure, callers need a system key called mcp_extension unless you change the authorisation level. The page also mentions built-in MCP server authorisation as an identity-based option.

Functions is strong where a tool is logic: a rule, a calculation, a comparison.

Route 3: API Management as the MCP front door

The API Management MCP overview gives two options:

  • Expose a REST API as an MCP server. You pick the operations, and each one becomes a tool.
  • Expose an existing MCP server, such as one on Logic Apps or Functions, through API Management.

Either way, policies apply to every tool: rate limits and quotas, JWT validation with Microsoft Entra ID, IP filtering and caching. The REST-to-MCP page shows a rate-limit-by-key example and warns about two limits:

  • API Management supports MCP tools only, not resources or prompts.
  • Policies on an MCP server mustn't read the response body. Doing so buffers the response and can break the streaming MCP depends on.

This is also where the AI gateway lives. The AI gateway overview lists token limits (llm-token-limit), semantic caching, content safety, token metrics, MCP servers and A2A agent APIs on the same gateway. Part 22 uses the model side. For tools, the point is simpler: one place to authenticate, rate-limit and log every tool call.

Mapping the nine tools

From the contract in Part 7, split by what each tool really is:

  • API Management, REST to MCP (five tools): get_invoice, get_purchase_order, get_goods_receipt and get_supplier_history are plain reads over process APIs. post_invoice_adjustment is also a process API, with the four checks from Part 19 behind it.
  • Functions (two tools): check_duplicate_invoice and run_three_way_match are rules, and rules belong in code you can unit-test.
  • Logic Apps (two tools): request_approval and notify_supplier are small workflows that use connectors.

So the agent sees three MCP servers behind one gateway. The process-API rule from Part 3 still holds: no tool calls the ERP's own APIs directly.

One timing point. The Foundry Agent Service MCP page says non-streaming MCP tool calls time out after 100 seconds. So request_approval must start the approval and return straight away. It can't wait for a person to answer. That fits Part 6 anyway: the approval comes back as an approval_id, and the posting tool checks it.

Schemas, errors and identity

Schemas. The same Foundry page warns that schemas using anyOf or allOf, or parameters that accept more than one type, can cause "invalid tool schema" errors. Keep the Part 7 schemas flat. Combined with the Functions default, this is the most concrete schema advice I've found on any platform so far.

Named errors. The same open question as on every other platform. None of the pages I read says how a failed tool call is returned, or whether isError is set. The Functions examples return plain strings for failures. So the Part 8 errors, such as GR_MISSING and APPROVAL_MISSING, need to come from the process layer as structured results, whichever host runs the tool.

Identity. Logic Apps defaults to Entra OAuth. API Management can validate Entra tokens. Foundry's MCP connections support several authentication types, including the project's managed identity and an agent identity. Microsoft Entra Agent ID is now generally available, though some setup pages are still marked preview. Part 22 picks this up.

What this sets up for Part 22

Azure's tool story is the most flexible so far: workflows, code and APIs can all become MCP tools, with one gateway in front. The trade-off is choice. With three hosts, you have to decide where each tool lives. A split by "workflow, rule or API" keeps that decision simple.

Part 22 builds the agent in Foundry Agent Service, adds Entra identity, puts the approval in Teams, and gives Azure its provisional scores.

Logic Apps or Functions for agent tools?

This series describes a reference build on a fictional company. This part is based only on Microsoft Learn and Microsoft's announcements as of 9 November 2026; no hands-on build has been run yet. Preview features may change. Views are my own. Check current docs before you build.

Top comments (0)