Serveur MCP distant auto-hébergé sur Azure Functions (préversion publique)

Azure Functions offre deux façons d’héberger des serveurs MCP distants :

Serveurs MCP créés avec l’extension Functions MCP
Serveurs MCP créés avec les kits SDK MCP officiels

Avec la première approche, vous pouvez utiliser le modèle de programmation Azure Functions avec des déclencheurs et des liaisons pour générer le serveur MCP. Vous pouvez ensuite héberger le serveur à distance en le déployant sur une application de fonction.

Si vous disposez déjà d’un serveur MCP créé avec les kits SDK MCP officiels et que vous souhaitez simplement l’héberger à distance, la deuxième approche convient probablement à vos besoins. Vous n’avez pas besoin d’apporter de modifications de code au serveur pour l’héberger sur Azure Functions. Au lieu de cela, vous pouvez ajouter les artefacts Functions requis et le serveur est prêt à être déployé. Par conséquent, ces serveurs sont appelés serveurs MCP auto-hébergés.

Diagramme montrant l’hébergement d’applications de fonction et d’applications de gestionnaire personnalisées.

Cet article fournit une vue d’ensemble des serveurs MCP auto-hébergés et des liens vers des articles et des exemples pertinents.

Gestionnaires personnalisés

Les serveurs MCP auto-hébergés sont déployés sur la plateforme Azure Functions en tant que gestionnaires personnalisés. Les gestionnaires personnalisés sont des serveurs web légers qui reçoivent des événements de l’hôte Functions. Ils fournissent un moyen d'exécuter sur la plateforme Functions des applications construites avec des frameworks différents du modèle de programmation Functions ou dans des langages non pris en charge de manière native. Pour plus d’informations, consultez Gestionnaires personnalisés Azure Functions.

Lorsque vous déployez un serveur basé sur le SDK MCP sur Azure Functions, vous devez inclure un host.json dans votre projet. La host.json minimale ressemble à ceci :

{
   "version": "2.0",
    "configurationProfile": "mcp-custom-handler",
    "customHandler": {
        "description": {
            "defaultExecutablePath": "python",
            "arguments": ["Path to main script file, e.g. hello_world.py"] 
        },
        "port": "<MCP server port>"
    }
}

{
   "version": "2.0",
    "configurationProfile": "mcp-custom-handler",
    "customHandler": {
        "description": {
            "defaultExecutablePath": "npm",
            "arguments": ["run", "start"] 
        },
        "port": "<MCP server port>"
    }
}

{
   "version": "2.0",
    "configurationProfile": "mcp-custom-handler",
    "customHandler": {
        "description": {
            "defaultExecutablePath": "dotnet",
            "arguments": ["Path to the compiled DLL, e.g. HelloWorld.dll"] 
        },
        "port": "<MCP server port>"
    }
}

Note

Étant donné que la charge utile déployée sur Azure Functions est le contenu du répertoire, le chemin d’accès bin/output à la DLL compilée est relatif à ce répertoire, et non à la racine du projet.

Exemple non encore disponible.

L’utilisation d’une valeur configuration Profile de mcp-custom-handler configure automatiquement ces paramètres d’hôte Functions, requis pour exécuter votre serveur MCP dans Azure Functions :

http.enableProxying à true
http.routes à [{ "route": "{*route}" }]
extensions.http.routePrefix à ""

Cet exemple montre un fichier host.json avec des propriétés supplémentaires de gestionnaire personnalisées définies comme équivalentes à celles du profil mcp-custom-handler.

{
    "version": "2.0",
    "extensions": {
        "http": {
            "routePrefix": ""
        }
    },
    "customHandler": {
        "description": {
            "defaultExecutablePath": "",
            "arguments": [""]
        },
        "http": {
            "enableProxying": true, 
            "defaultAuthorizationLevel": "anonymous", 
            "routes": [ 
                {
                    "route": "{*route}",
                    // Default authorization level is `defaultAuthorizationLevel`
                },
                {
                    "route": "admin/{*route}",
                    "authorizationLevel": "admin"
                }
            ]
        }
    }
}

Ce tableau explique les propriétés de customHandler.http, ainsi que les valeurs par défaut :

Propriété	Ce qu'il fait	Valeur par défaut
`enableProxying`	Contrôle la façon dont l’hôte Azure Functions gère les requêtes HTTP aux gestionnaires personnalisés. Lorsqu’`enableProxying` est défini sur `true`, l’hôte Functions agit en tant que proxy inverse et transfère l’intégralité de la requête HTTP (y compris les en-têtes, le corps, les paramètres de requête) directement au gestionnaire personnalisé. Ce paramètre donne au gestionnaire personnalisé un accès complet aux détails de la requête HTTP d’origine. Lorsque `enableProxying` est `false`, l’hôte Functions traite d’abord la requête et la transforme au format de requête/réponse des Azure Functions avant de la transmettre au gestionnaire personnalisé.	`false`
`defaultAuthorizationLevel`	Contrôle l’exigence d’authentification pour accéder aux points de terminaison de gestionnaire personnalisés. Par exemple, `function` nécessite une clé API spécifique à une fonction pour accéder. Pour plus d’informations, consultez les niveaux d’autorisation.	`function`
`route`	Spécifie le modèle de chemin d’URL auquel le gestionnaire personnalisé répond. `{*route}`correspond à n’importe quel chemin d’URL (par `/`exemple, , `/mcp`ou `/api/tools/anything/nested/path`) et transfère la requête au gestionnaire personnalisé.	`{*route}`

Authentification du serveur intégrée

L’authentification et l’autorisation basées sur OAuth fournies par la plateforme App Service implémentent les exigences de la spécification d’autorisation MCP, telles que l’émission d’un défi 401 et l’exposition du document PRM (Protected Resource Metadata). Lorsque vous activez l’authentification intégrée, les clients qui tentent d’accéder au serveur sont redirigés vers des fournisseurs d’identité tels que Microsoft Entra ID pour l’authentification avant de se connecter.

Pour plus d’informations, consultez Configurer l’autorisation de serveur intégrée (préversion) et l’hébergement de serveurs MCP sur Azure Functions.

Intégrations de l’agent Azure AI Foundry

Les agents dans Azure AI Foundry peuvent être configurés pour utiliser des outils dans des serveurs MCP hébergés dans Azure Functions.

Inscrire votre serveur dans le Centre des API Azure

Lorsque vous inscrivez votre serveur MCP dans azure API Center, vous créez un catalogue d’outils organisationnels privé. Cette approche est recommandée pour partager des serveurs MCP au sein de votre organisation avec une gouvernance et une détectabilité cohérentes. Pour plus d’informations, consultez Inscrire des serveurs MCP hébergés dans Azure Functions dans azure API Center.

Prise en charge de la préversion publique

La possibilité d’héberger vos propres serveurs MCP basés sur le SDK dans Functions est actuellement en préversion et prend en charge ces fonctionnalités :

Serveurs sans état qui utilisent le transport streamable-http. Si vous avez besoin que votre serveur soit stateful, envisagez d’utiliser l’extension Functions MCP.
Les serveurs implémentés avec les kits SDK Python, TypeScript, C# ou Java MCP.
Lorsque vous exécutez le projet localement, vous devez utiliser Azure Functions Core Tools (func start commande). Vous ne pouvez pas utiliser F5 actuellement pour démarrer l’exécution avec le débogueur.
Les serveurs doivent être hébergés en tant qu'applications du plan Flex Consumption.

Samples

Pas encore disponible.

Gestionnaires personnalisés Azure Functions

Commentaires

Cette page vous a-t-elle été utile ?

Last updated on 2025-11-19