Azure Functions MCP-server: private tools met Entra

Een Azure Functions MCP server maakt een interne API als agenttool beschikbaar, bijvoorbeeld voor het opvragen van een orderstatus, voorraad of contractstatus. Maar een generieke API-doorlaat geeft een agent vaak meer bereik dan de taak nodig heeft. Dat wordt snel een identity-, governance- en observabilityprobleem.

Deze tutorial is een neutrale demo. get_order_status is een fictieve read-only tool en er is geen Azure-tenant, klant-API of productiebeveiliging uitgevoerd. De waarde zit in de controlepunten, niet in een claim dat één configuratie elk risico wegneemt.

Waarom begin je met één tool?

Omdat een tool een zelfstandig recht en een zelfstandige foutgrens is. “Geef de agent toegang tot de order-API” is te breed. “Lees de status van één toegestaan order-ID” is te beoordelen, te loggen en te testen.

Gebruik dit mentale model:

Microsofts handleiding voor een eigen MCP-server beschrijft Azure Functions als host en Azure API Center als optionele organisatiecatalogus. De catalogus is nuttig wanneer meerdere teams dezelfde goedgekeurde tool moeten vinden; hij is geen argument om de tool zelf brede rechten te geven.

Stap 1: beperk tool en downstreamcontract

Maak de eerste tool read-only. De fictieve tool hieronder kent alleen een synthetische order-ID en retourneert alleen een beperkte status. Hij mag geen betaling, mutatie of bulkzoekopdracht uitvoeren.

type OrderStatusInput = { orderId: string };

async function getOrderStatus(input: OrderStatusInput, caller: Caller) {
  assertOrderId(input.orderId);
  requireRole(caller, "orders.read");

  return ordersApi.readStatus({
    orderId: input.orderId,
    fields: ["status", "updatedAt"],
  });
}

Dit is patrooncode, geen uitgerolde Azure Functions-code. Valideer invoer server-side; vertrouw niet op een systeem- of toolbeschrijving als beveiligingslaag. Voeg een schrijvende tool pas toe wanneer er een expliciete eigenaar, audittrail, idempotencygrens en menselijke approval is.

Stap 2: kies veilige Function-instellingen

De Azure Functions MCP-bindingdocumentatie ondersteunt tool-, resource- en prompttriggers. De documentatie noemt ook dat PowerShell-apps niet worden ondersteund. Gebruik voor nieuwe clients waar mogelijk Streamable HTTP; SSE is in nieuwere protocolversies verouderd.

Een klein host.json-voorbeeld laat twee veilige defaults zien:

{
  "version": "2.0",
  "extensions": {
    "mcp": {
      "serverName": "orders-tool-demo",
      "serverVersion": "0.1.0",
      "encryptClientState": true,
      "system": { "webhookAuthorizationLevel": "System" }
    }
  }
}

System is de standaard voor deze webhook: op een gehoste Function endpoint is dan een systeemkey vereist. Bewaar zo'n key in een geheimbeheeroplossing, roteer hem bij blootstelling en zet hem nooit in Git of een gedeeld mcp.json-bestand. Zet webhookAuthorizationLevel niet op Anonymous voor productie alleen om een koppeling sneller te laten werken.

Stap 3: kies identity vóór je een tool koppelt

Voor Foundry beschrijft Microsoft drie verschillende patronen:

• Key-based: een Function key als transportcredential. Praktisch voor een beperkte koppeling, maar behandel de key als een geheim.
• Microsoft Entra: een agent identity of project managed identity roept de Function aan. De audience in Foundry moet overeenkomen met de toegestane audience in de Function-authenticatie.
• OAuth identity passthrough (OBO): gebruik dit alleen wanneer de downstreamactie aantoonbaar namens de ingelogde gebruiker moet gebeuren; regel scopes en consent expliciet.

Een ontwerpnotitie, geen plaksjabloon, kan er zo uitzien:

tool: get_order_status
transport: streamable-http
caller_identity: foundry-project-managed-identity
entra_audience: api://orders-tool-demo
downstream_permission: orders.read
human_approval: required_for_write_tools
logging: request-id, caller-object-id, tool-name, result-code

Geef de Function of managed identity alleen de downstreamrechten die deze tool nodig heeft. Gebruik niet dezelfde brede identity voor lezen, schrijven en beheer. Log request-ID, caller-object-ID, toolnaam, autorisatiebesluit en resultaatcode, maar niet automatisch hele toolargumenten of gevoelige antwoorden.

Stap 4: registreer de tool voor governance, niet voor magie

Azure API Center kan een private catalogus voor MCP-servers bieden. Registreer er pas een server wanneer deze een duidelijke eigenaar, versie en documentatie heeft. De API Center-documentatie beschrijft inventory, discovery en toegangbeheer; tenant- en portalrechten blijven van toepassing.

Hanteer vóór registratie deze checklist:

1. Toolnaam en beschrijving maken duidelijk wat de tool wel en niet doet.
2. Endpoint, transport en authenticatietype zijn vastgelegd; secrets ontbreken uit metadata.
3. De catalogusversie verwijst naar één deployment met bekende eigenaar.
4. Alleen goedgekeurde groepen krijgen catalogustoegang.
5. De agentconfiguratie schakelt alleen de nodige tool in, niet automatisch alle tools op de server.

API Center vervangt geen Entra-audiencecontrole, Function endpointbeveiliging of autorisatie in de downstream-API. Het helpt wel voorkomen dat elke teamkopie een onbekende MCP-URL en losse secrets krijgt.

Stap 5: test de grens vóór de functionaliteit

Een werkende happy flow is onvoldoende. Test juist de paden die moeten stoppen:

Maak een expliciete approvalgrens voor iedere toekomstige write-tool. “De agent vond het logisch” is geen approval. Leg vast wie mag goedkeuren, welk object wordt gewijzigd, hoe lang de goedkeuring geldig is en hoe je dubbele verzoeken blokkeert.

Wanneer kies je een ander ontwerp?

Gebruik geen MCP-tool wanneer een gewone backendintegratie zonder modelbeslissing veiliger en eenvoudiger is. Kies een queue of workflow-engine voor langlopende acties, retries en compensaties. Kies een API gateway of aanvullende netwerkgrens wanneer de Function alleen via private netwerken bereikbaar mag zijn. Preview- en private-networkdetails vragen vóór productie altijd een nieuwe toets tegen actuele Microsoft-documentatie en de eigen tenantinstellingen.

Voor het transport- en sessievraagstuk kun je MCP-servers zonder sessies lezen. Voor bredere betrouwbaarheid en releasegates is AI-agenten in productie relevant. Voor ontwerp en implementatie binnen Microsoft en Azure kun je een Azure AI engineer inschakelen.

Samenvatting

Een Azure Functions MCP server wordt beheersbaar door klein te beginnen: één tool, beperkte Entra-identity, minimale downstreamrechten, logging en een approvalgrens. API Center kan daarna de ontdekking en governance ordenen. Test identiteit en afwijzingen net zo zorgvuldig als de happy flow; pas dan is uitbreiden een bewuste architectuurkeuze.