Building MCP servers on Azure

The syllabus asks you to "design and build MCP servers and clients, including Azure
Functions, Azure Logic Apps, and Azure API Management". Three hosts, and the choice
is usually made by what you already have rather than by what the tool does.

Choosing the host

Azure Functions. Code you write, event-driven, scales to zero. This is the
default when the tool is logic — something you are implementing rather than
something you are connecting to.

Azure Logic Apps. Connector-led integration. The default when the tool is
plumbing between SaaS systems — read from one thing, write to another, with
authentication someone else has already solved.

Azure API Management. For an existing API estate that needs governing rather
than rewriting. APIM sits in front of what already exists and adds authentication,
throttling and policy. If a scenario describes a company with a mature API landscape
that does not want to rebuild it, this is the shape of the answer.

The useful question is not "which is best" but "what already exists". Functions when
you are writing something new, Logic Apps when you are wiring things together, APIM
when you are putting a governed front door on something that is already there.

Things the server has to get right

Tool descriptions are prompt surface. This surprises people. The model chooses
which tool to call by reading the descriptions, so a vague or overlapping
description is not a documentation problem — it is a wrong-tool-call waiting to
happen, and it will present as a model failure when it happens.

Authorise every call on its merits. The server must not assume the client
already checked, because the client is a model reading untrusted content. Schemas
are the pre-execution defence: they constrain what can even be asked for.

Background mode for long-running work. The answer to "this operation takes
twenty minutes" — the request returns, the work continues, the result is collected
later.

Private endpoints where it must not be internet-reachable. Foundry documents
separate public and private endpoint requirements for MCP servers.

Authentication, and where entitlement is won or lost

Foundry authenticates to an MCP server using a project connection, and the
identity that connection carries determines whether the user's entitlement survives
the hop.

This is the single most consequential decision on the card. A project connection
configured with a service credential against a system that has per-user permissions
means every user of that agent inherits the service's access — and it will work
flawlessly in testing, because the testers have broad access anyway.

Toolboxes

Worth restating here because it is the operational half of MCP: a toolbox groups
tools for reuse across agents, is versioned, and centralises credential
management.

Six agents each with their own integration to the same system means six credentials
to rotate and six places to get it wrong. One toolbox means one.

The trap

MCP is a tool protocol, not a security boundary.

Putting a capability behind an MCP server does not authorise it. It gives the
capability a standard interface and a governed place to live, which is genuinely
valuable — but the server still has to check every call, because the thing calling
it is a model that may have read something hostile three tool calls ago.

An answer that treats "we exposed it via MCP" as the security control has confused
an integration pattern with an authorisation model.