Your Logic Apps Were Already Agentic. You Just Didn't Know It.

I was going through my usual Monday morning routine — coffee, terminal, and the Logic Apps Aviators Newsletter — when the April 2026 drop stopped me cold.

"You can now expose any Logic Apps Standard workflow as an MCP server — directly from the Azure portal, in preview, using an in-portal wizard."

I had to read that twice.

Not because I didn't understand what it meant. Because I absolutely did — and it meant that the Service Bus-triggered, APIM-fronted, clean-architecture Logic App workflows I'd been building for the past two years were, by Microsoft's own admission, exactly what AI agents need.

Nandito na pala tayo. We were already here.

This post isn't a tutorial on how to wire up the MCP server toggle (I'll save that for a follow-up). This is the "step back and look at what you already built" post. Because if you've been doing integration work on Azure the right way, you didn't miss the agentic AI wave. You were already surfing it — you just didn't have the terminology.

First: What MCP Actually Is (The 60-Second Version)

Before the hype cycle buries the actual idea, here's the practitioner definition.

Model Context Protocol (MCP) is a standard that lets AI agents discover and call tools dynamically — without those tools being hardcoded into the agent's codebase. Think of it as a contract layer: the agent says "what can you do?", the MCP server responds with a list of callable tools and their schemas, and the agent decides which ones to invoke based on what the task requires.

The old world looked like this: your AI integration called a specific REST endpoint, with a specific payload shape, defined at build time. Every new capability meant a new hardcoded connection.

The new world looks like this:

The agent discovers tools at runtime. It doesn't need to know your endpoint URLs. It needs to know what the tool does — and a well-named Logic App workflow with a clean HTTP trigger schema is, structurally, a perfect MCP tool.

That's the punchline. Everything else in this post is unpacking why.

Why Logic Apps Were Born for This

Let's walk through what agents actually need from a tool — and map it to what Logic Apps Standard already gives you out of the box.

1. A massive pre-built tool library

An AI agent is only as useful as the actions it can take. MCP tools need to be discoverable, callable, and connected to real systems.

Logic Apps has 1,400+ managed connectors — Azure SQL, Salesforce, SAP, Service Bus, SharePoint, Outlook, Dynamics 365, and anything with an HTTP endpoint. You didn't write those connectors. Microsoft maintains them. Authentication, retry logic, throttling — it's all handled.

From an agent's perspective, every connector you've ever wired into a Logic App workflow is a pre-built capability sitting there waiting to be exposed as an MCP tool.

2. Stateful execution for long-running tasks

MCP tool calls from agents aren't always fast fire-and-forget operations. Sometimes an agent needs to kick off a process, wait for something to complete, and check back. Agents need durability.

Logic Apps Standard supports stateful workflows natively. Checkpointed state, built-in wait conditions, approval patterns, long-running saga orchestrations — all things you already know how to build. The durable execution model that made Logic Apps great for BizTalk migration work is the same model that makes it great for agent tasks that span minutes or hours.

3. Managed identity and RBAC — no secrets in agent prompts

One of the hairiest problems in agentic AI is credentials. How does your agent authenticate to downstream systems without secrets leaking through prompt context or tool call payloads?

Logic Apps has been solving this since Managed Identity support landed. Your workflow authenticates to Azure SQL, Key Vault, Service Bus, and other Azure services using UAMI or SAMI — no connection strings, no API keys in config. The agent calls the Logic App. The Logic App authenticates to everything else. The security boundary is clean.

4. Built-in reliability patterns

Agents are non-deterministic by nature. The tools they call need to be extremely deterministic. You don't want your agent to retry a payment workflow three times because the tool call timed out and the agent got confused.

Logic Apps already gives you retry policies, dead-letter handling via Service Bus, compensation patterns, and error branches. Every reliability pattern you've built into your integration workflows translates directly into a more trustworthy MCP tool.

The mental model I keep coming back to: Logic Apps is the deterministic half of an agentic system. The agent reasons and decides. Logic Apps executes reliably. That division of responsibility is exactly how you want it.

What "MCP Server GA at Build 2026" Actually Changes

Let's be concrete. Here's what the Build 2026 announcement delivers and what it doesn't.

What you get:

• A portal wizard to expose any Logic Apps Standard workflow as an MCP server

• Key-based authentication with configurable expiration

• Each workflow automatically becomes a named MCP tool, with schema derived from your HTTP Request trigger's JSON Schema definition

• This is now Generally Available — it's not an experiment

What you still need to do yourself:

The six-layer blueprint that Microsoft published in the Aviators Newsletter is the production reference architecture. The portal wizard gets you from zero to functional. Getting from functional to production-ready means:

1. Putting APIM in front as the governed MCP gateway — centralised auth, rate limiting, policy enforcement, content safety, and the API Center registry for discovery

2. Replacing key-based auth with Entra — OAuth2, UAMI, the full enterprise identity story

3. Wiring Service Bus and Event Grid between your agent and your Logic Apps for async patterns that don't time out under load

I'll cover that full production wiring in Part 2. For now, the important thing is: the portal wizard is a dev and POC tool. Don't ship key-based MCP endpoints to production.

One more callout: MCP server export is not available on the Consumption tier. If you're on Consumption, you're looking at a tier upgrade or a move to Standard. Plan accordingly.

The Mindset Shift: Before and After

Here's the thing that took me a few days to fully absorb.

Nothing about the Logic App itself changes. The workflow you built to pull records from Azure SQL and push them to Service Bus is the same workflow. The connectors are the same. The retry policies are the same. The managed identity auth is the same.

What changes is the entry point — and therefore the caller.

Before: another app called your Logic App via HTTP trigger on a fixed schedule or in response to a specific event.

After: an AI agent discovers your Logic App as a named tool, decides when to call it based on reasoning about what the current task requires, and invokes it through the MCP protocol.

Your integration work didn't become legacy. It became infrastructure.

The Honest Take: What This Doesn't Solve

I'm constitutionally incapable of writing a hype post without a "but wait" section. Here it is.

Tool naming matters more than ever. MCP exposes your workflow by name. If your Logic App is called LogicApp-Prod-v2-final-FINAL, the agent has no idea what it does. Invest in descriptive names. Invest in good HTTP trigger schemas with clear property names and descriptions. The agent uses those to decide whether to call your tool. Garbage in, garbage out.

The key-based auth story is immature. The portal wizard gives you key-based auth with expiration. That's fine for dev. In production you need Entra-backed OAuth2 in front of APIM. Don't skip this step because the wizard made the rest feel easy.

Agents are non-deterministic; your expectations need to match. You will not get the same sequence of tool calls every time for the same prompt. Design your Logic Apps to be idempotent. Use correlation IDs. Handle duplicate calls gracefully. This is not new advice for integration engineers — but it matters even more when the caller is an LLM.

This is a platform play, not a magic button. The biggest risk I see is teams exposing everything as MCP tools with no thought to the agent architecture around them. An agent that can call 200 Logic App tools with no governance layer is an incident waiting to happen. The six-layer architecture isn't optional decoration — it's load-bearing.

So What Do You Do This Week?

Here's the one concrete thing: pick the most boring, reliable Logic App workflow you have — the one that's been running flawlessly for eighteen months and does exactly one thing well — and expose it as an MCP server.

Not a critical one. Not a payment workflow. The data-sync one. The notification one. The one that queries a table and returns a JSON array.

Configure the portal wizard. Point Claude Desktop or GitHub Copilot agent mode at it using the MCP Inspector. Watch an AI agent discover it and call it. See what the tool schema looks like from the outside.

That five-minute experiment will teach you more about agentic integration design than reading ten more blog posts. Trust me, I wrote several of them.

What's Coming in Part 2

We've established that your existing Logic Apps are structurally ready for the agentic era. Next time we're wiring up the full production stack:

• APIM as the governed MCP gateway with Entra OAuth2

• API Center as the discovery registry for all your MCP tools

• The content safety and token governance policies you need before you let agents loose on enterprise workflows

• A real architecture walkthrough: AI Agent Service → APIM → Service Bus → Logic Apps → API Center → Entra

Hindi ka nahuli. Nandoon ka na. You didn't miss it. You were already there.