Workflow architecture for mid-sized companies: MCP server, Python and Azure

What is a workflow architecture with an MCP server, Python and Azure?

A workflow architecture with an MCP server, Python and Azure connects AI assistants to your business systems through a self-written, reviewed server, instead of letting the AI loose directly on ERP, CRM or document storage. The AI assistant asks, the MCP server decides on the basis of fixed tools what is allowed, and the business logic in Python fetches the data through the systems' interfaces. Azure supplies the runtime, sign-in, key management, network and audit log.

This is interesting for mid-sized companies because many businesses already work with Microsoft 365 and Entra ID. The sign-in your team uses every day then also becomes the sign-in to the AI tool. And because the rules are in code, they can be tested, versioned and reviewed by a second person. What MCP is in principle is explained in the guide What is an MCP server?.

What layers does the reference architecture consist of?

The reference architecture has four layers: AI client, MCP server, business logic and connected systems, embedded in identity, key management, network and audit log. Each layer has exactly one task, so that errors and permissions can be clearly assigned.

Layer 1: the AI client

Microsoft Copilot Studio can integrate custom MCP servers as tools. The connection uses Streamable HTTP, and OAuth 2.0 or an API key can be chosen for sign-in (Microsoft Learn). Claude and other assistants also connect via a server address. Because the server follows the MCP standard, it stays the same when you switch assistants.

Layer 2: the MCP server in Python

We write the server with the official MCP SDK for Python. According to the project page, the SDK supports the standard transports stdio, Streamable HTTP and SSE; for operation on the network we use Streamable HTTP. The server knows only the tools that are in the code, with types and validation rules for every input.

Layer 3: business logic and workers

This is where what makes the company what it is sits: which fields a quote has, how customer numbers are structured, which totals are calculated. For the runtime, Azure offers two obvious routes, both documented by Microsoft for MCP servers:

• Azure Container Apps: A server built with an official MCP SDK is run as a container with HTTP ingress. Container Apps brings HTTPS with automatic TLS termination, automatic scaling, optional built-in sign-in via Microsoft Entra ID and managed identities (Microsoft Learn).
• Azure Functions: Servers built with the official SDKs can be hosted without code changes as so-called custom handlers. Microsoft currently lists this as a public preview; stateless servers with Streamable HTTP are supported, and they must run on the Flex Consumption plan (Microsoft Learn).

Long-running or scheduled processes, such as a nightly reconciliation, run as separate workers alongside the MCP server and not in the tool call itself.

Layer 4: the systems

ERP, CRM and document storage are connected through their documented interfaces, not through direct database access. This keeps the systems' permission checks and business logic intact. Some vendors have their own rules for AI access; SAP, for example, has regulated it in its API Policy since April 2026 (see MCP server for SAP). For Microsoft 365 as the system behind it, there is a separate guide: MCP server for Microsoft 365.

Which Azure services take on which task?

For every cross-cutting task there is a documented Azure service, so that only tools and business logic remain in your own code. The table shows what Microsoft describes for each service.

As of 28 October 2026, each read on Microsoft Learn.

Region: We plan in the Azure region Germany West Central (Frankfurt). Not every service and variant is available in every region; the Flex Consumption plan, for example, currently does not support all regions according to Microsoft. That is why we check availability per service before building. The region of the MCP server also says nothing about where the AI assistant computes. If a US provider is in the path, we cannot assure that data never leaves Europe.

Why code rather than low-code for this architecture?

For the layer between AI and business systems, one thing above all speaks for code: security boundaries can be written down there in a verifiable way, instead of being spread across click-through interfaces. Specifically:

• TestabilityEvery tool has automated tests, including for what it must reject. A test fails if someone loosens a validation rule.
• VersioningEvery change is in Git with date, author and rationale. What applied yesterday can be restored.
• Code reviewNo change goes live without a second person having read it. This is the simplest protection against mistakes with consequences.
• Fixed toolsThe server knows only the functions that are in the code. There is no way to assemble new calls at runtime.
• Limits in codeInput validation, field filters, upper limits and permission checks sit at the point where the computation happens, not in a configuration next to it.
• Same tools as the rest of ITPython, Git, CI/CD and Azure monitoring are standard. Your IT does not have to operate any additional specialist tool.

The drawbacks belong here too. Code has to be maintained: dependencies get security updates, the MCP SDK keeps evolving, vendors' interfaces change. Whoever runs the code needs Python skills in-house or a service provider with a maintenance contract. And for a small change, a commit with review is more effort than a click in an interface.

When is a low-code tool enough? If a process works without AI, that is, has fixed triggers and fixed steps, touches few systems and moves no sensitive data, a low-code or integration tool is often the faster route. This applies to notifications, simple data transfers or forms, for example. As soon as a language model selects tools itself and accesses HR, customer or financial data, we recommend keeping the limits in code.

What does an MCP tool look like in Python?

An MCP tool in Python is a typed function with a description that the official SDK offers as a tool. The following example reads the status of a customer order, read-only and with validation of the order number. We tested it on 28 October 2026 with the package mcp in version 2.3.0. In version 2 the server class is called MCPServer; in version 1 it was called FastMCP (migration guide).

import os
from typing import Annotated

import httpx
from pydantic import BaseModel, Field

from mcp.server import MCPServer
from mcp.types import ToolAnnotations

mcp = MCPServer("auftragsstatus")


class Auftragsstatus(BaseModel):
    gefunden: bool
    status: str | None = None
    liefertermin: str | None = None
    offene_positionen: int | None = None


ERP_URL = os.environ.get("ERP_API_URL", "https://erp.example.internal/api")


@mcp.tool(annotations=ToolAnnotations(read_only_hint=True))
async def auftragsstatus(
    auftragsnummer: Annotated[str, Field(pattern=r"^A-\d{6}$", description="Auftragsnummer, z. B. A-104233")],
) -> Auftragsstatus:
    """Liefert Status, Liefertermin und offene Positionen eines Kundenauftrags."""
    async with httpx.AsyncClient(timeout=10) as client:
        antwort = await client.get(
            f"{ERP_URL}/auftraege/{auftragsnummer}",
            headers={"Authorization": f"Bearer {os.environ['ERP_API_TOKEN']}"},
        )
    if antwort.status_code == 404:
        return Auftragsstatus(gefunden=False)
    if antwort.status_code != 200:
        # Keine Fremd-Fehlertexte an das Modell durchreichen
        raise RuntimeError("Abfrage im ERP fehlgeschlagen")
    daten = antwort.json()
    # Nur die Felder, die der Anwendungsfall braucht
    return Auftragsstatus(
        gefunden=True,
        status=daten["status"],
        liefertermin=daten["liefertermin"],
        offene_positionen=daten["offene_positionen"],
    )


if __name__ == "__main__":
    mcp.run(transport="streamable-http", host="0.0.0.0", port=8000, stateless_http=True)

What the example shows:

• Input validation: The order number must follow the pattern A- plus six digits. The SDK derives the input schema from this and rejects everything else before the code even queries the ERP.
• Read-only: The tool makes only a GET request and is marked with the hint readOnlyHint. What matters is that the server has no tool that writes. The hint alone protects nothing.
• Fixed output: Four fields come back, even if the ERP returns more. What is not in the return model does not reach the model.
• No third-party text on errors: Error messages from the ERP are not passed through, because third-party text in the error path can be an entry point for prompt injection.
• Stateless: The server runs with Streamable HTTP and without session state. This matches the requirement for Azure Functions and also scales more easily in Container Apps.

What the example deliberately leaves out belongs in a production server: user sign-in via Entra ID, fetching the ERP token from Key Vault instead of an environment variable, logging of every call and rate limiting. How we implement this for clients is described in the guide Having an MCP server developed.

Where are the security boundaries in this architecture?

The security boundaries lie in the sign-in before the MCP server, in the tool design of the server and in the network behind it, each in such a way that one layer catches the mistakes of the others.

• Rights of the individual user: Where the system allows it, the server works with the rights of the signed-in person rather than a shared account. This keeps it traceable who queried what.
• Separate reading and writing: Tools that read and tools that write in separate servers with separate identities. Write actions with an approval step by a human.
• No long-lived keys in code: Credentials live in Key Vault, and the server fetches them via its managed identity.
• No public route to the systems: ERP and storage are reachable only from the VNet, Key Vault via a Private Endpoint.
• Limit: Upper limits per tool for time periods and result sizes, rate limiting per user, timeouts for every system call.
• Log: Every call with user, tool, parameters, status and duration, personal values redacted.

The privacy side, with data processing, processing location and deletion concept, is described in the guide MCP server, security and GDPR.

How do you operate the architecture: CI/CD, tests, monitoring, costs?

The architecture is operated like any other enterprise software: with automated delivery, tests before every release, monitoring in live operation and budget alerts.

CI/CD

The code lives in a Git repository, and every change goes through a pull request with review. After the merge, a pipeline builds the container image and delivers it. For Container Apps, Microsoft describes this with GitHub Actions: every push to the defined branch triggers the workflow, and Container Apps creates a new revision from it (Microsoft Learn). Because every delivery is its own revision and Container Apps can split traffic between revisions, a new version can first be tested with a share of the requests.

Tests

• Unit tests per tool: valid inputs, invalid inputs, empty results, errors from the target system.
• Negative tests: That a tool rejects what it must reject is tested just as much as the normal case.
• Contract tests against the interfaces: Against a test environment of the system, so that vendor changes are noticed before your team notices them.
• Test questions for the assistant: A fixed list of typical questions with expected answers, re-checked after every change of model or tool.

Monitoring

The server sends traces, metrics and logs via the Microsoft OpenTelemetry Distro to Application Insights. These feed alerts for error rates, runtimes and unusually many calls to a tool. The content of responses does not belong in the log, only metadata of the call.

Cost control

Costs arise on three levels: Azure resources, the language model of the AI client and, where applicable, quotas of the connected systems. For Azure we set budgets with warning thresholds in Cost Management. Important to know: a budget warns, it does not stop resources. On top of that come technical brakes in the code, namely rate limiting, result caps and caching for expensive queries. We discuss concrete orders of magnitude in the AI Check, depending on the number of users, systems and use cases.

How do you get started with this architecture?

Start with a read-only use case on one system and build identity, audit log and pipeline properly from the outset, because these parts later carry all further tools.

1. Choose a use case: a frequent, clearly answerable question, for example order status or open items.
2. Check the interface: Is there a documented API, what permissions does it need, are there vendor rules for AI access?
3. Set up the foundation: repository, pipeline, Entra ID app, Key Vault, Application Insights, network.
4. Build and test the tool: with negative tests and a list of test questions.
5. Pilot with a small group: Check answers against the system, analyse audit logs.
6. Extend: more tools, more systems, later write actions with approval.

We set the timeline after the AI Check.

Frequently asked questions

Why Python for the MCP server?

Python is widely used for data processing and interfaces in mid-sized companies, and there is an official MCP SDK for it. The SDK derives input schemas directly from type annotations, so validation rules are visible in the code.

Do I need Azure for an MCP server?

No. An MCP server runs wherever Python runs. Azure is a good fit if you already use Microsoft 365 and Entra ID, because sign-in, key management and audit log then come from a single source.

Azure Functions or Azure Container Apps?

Container Apps is the general route for an MCP server as a container. Azure Functions can also host SDK-based servers, according to Microsoft currently as a preview, stateless only with Streamable HTTP and on the Flex Consumption plan. We decide this per project based on network requirements and load profile.

Can Microsoft Copilot use the MCP server?

Yes. Copilot Studio integrates MCP servers via Streamable HTTP, and sign-in runs via OAuth 2.0 or an API key. Whether a connector may be used is regulated by your IT through the data policies of the Power Platform.

Does the data stay in Germany?

The MCP server and the business logic can run in the Azure region Germany West Central (Frankfurt). Where the AI assistant's language model computes depends on the provider and contract. If a US provider is in the path, we cannot assure that data never leaves Europe.

Isn't a low-code tool enough?

For fixed processes without an AI decision, often yes. For the layer in which a language model selects tools and accesses sensitive data, we rely on code, because limits can be tested, versioned and reviewed there.

Who maintains the code after the project?

Either your IT, if Python skills are in-house, or we do, under a support agreement. We settle this before the project starts, because dependencies, SDK and interfaces need regular updates.