Aller au contenu principal

Connecter les agents aux outils avec les services MCP

Un service MCP est un élément sécurisable de Unity Catalog qui fournit un outil hébergé par Databricks ou enregistre un serveur MCP externe et régit la manière dont les agents l'utilisent. Vous le désignez par son nom à trois niveaux, catalog.schema.mcp_service, et l'invoquez via Unity Gateway, le plan de contrôle pour réguler le trafic d'IA.

L'enregistrement d'un serveur MCP en tant qu'élément sécurisable du Unity Catalog signifie que vous le gérez avec les mêmes primitives qui protègent vos autres assets du Unity Catalog. Celles-ci incluent les autorisations pour contrôler qui peut l'invoquer, la sélection d'outils pour limiter les outils qu'elle expose, les politiques de service pour autoriser ou refuser les appels d'outils individuels, et la journalisation d'audit et d'utilisation pour suivre chaque invocation.

remarque

Les services MCP sont l’un des nombreux moyens de connecter des agents à des MCP et outils externes, et constituent la méthode recommandée lorsque le service publie un serveur MCP. Pour obtenir la liste complète des options, y compris OAuth géré, le proxy de connexions Unity Catalog et l’appel direct aux API REST, consultez cet aperçu.

Il existe deux façons d'utiliser les services MCP :

Approche

Quand utiliser

Utilisez un service MCP fourni par Databricks.

Vous souhaitez utiliser un outil Workspace intégré ou un outil SaaS (outil/solution/technologie/plateforme) courant tel que Slack, GitHub ou Google Drive sans aucune configuration. Aucun serveur à héberger et aucune connexion à créer.

Enregistrer votre propre serveur MCP externe

Vous disposez d'un serveur MCP auto-hébergé ou tiers à gouverner en tant qu'élément sécurisable d'Unity Catalog.

Approche

Quand utiliser

Utilisez un service MCP fourni par Databricks.

Vous souhaitez utiliser un outil Workspace intégré ou un outil SaaS (outil/solution/technologie/plateforme) courant tel que Slack, GitHub ou Google Drive sans aucune configuration. Aucun serveur à héberger et aucune connexion à créer.

Enregistrer votre propre serveur MCP externe

Vous disposez d'un serveur MCP auto-hébergé ou tiers à gouverner en tant qu'élément sécurisable d'Unity Catalog.

Exigences

Comment ça marche

Un agent appelle un service MCP via son URL Unity Gateway, et chaque appel transite par le même chemin gouverné :

Un agent configuré avec une URL de service MCP appelle le service via Unity Gateway. La passerelle autorise l'appel auprès du service MCP dans Unity Catalog, qui applique l'autorisation EXECUTE, la sélection d'outils et les politiques de service, puis relaie la requête via une connexion HTTP Unity Catalog avec des identifiants gérés vers le serveur MCP externe, tel que GitHub ou Slack. Les enregistrements d'utilisation, d'audit et de trace sont stockés dans les tables système.

  1. Appel : l’agent envoie une requête MCP à l’URL Unity Gateway du service, authentifiée avec l’identité Databricks de l’appelant.
  2. Autoriser et gouverner : la passerelle vérifie que l'appelant dispose de EXECUTE sur le service MCP dans Unity Catalog. Le service expose uniquement les outils que vous avez sélectionnés et évalue toute politique de service attachée, qui peut autoriser, refuser ou exiger une approbation pour l'appel.
  3. Exécuter l’outil : pour un service fourni par Databricks, Databricks exécute l’outil en utilisant l’identité de l’appelant ou des identifiants gérés. Pour un serveur externe enregistré, Databricks transfère la requête via sa connexion HTTP et gère les identifiants du serveur.
  4. **Journalisez l'utilisation, auditez et tracez** : chaque invocation est enregistrée dans les tables système, vous permettant ainsi de surveiller l'utilisation et d'auditer l'activité au fil du temps.

Services MCP fournis par Databricks

Databricks fournit des services MCP prêts à l'emploi pour les outils de workspace et les applications SaaS courantes. Pour connaître les services disponibles, la configuration et les limitations, consultez les services MCP fournis par Databricks.

Découvrez les outils d’un service et lisez ses résultats

Chaque service MCP expose un ensemble d’outils différent ; découvrez-les donc au moment de l’exécution plutôt que de coder les noms en dur. Appelez tools/list (ou DatabricksMCPClient.list_tools()) pour obtenir le nom, la description et le schéma d’entrée de chaque outil. Voir Utiliser des serveurs MCP dans des agents personnalisés.

Lire le résultat d’un appel d’outil à partir du champ result. Sa forme dépend du fait que l’outil définisse ou non une sortie structurée :

  • Sortie typée. Un outil peut annoncer un outputSchema et renvoyer un objet JSON typé dans structuredContent. Lorsque structuredContent est présent, utilisez-le directement. Il ne nécessite aucune analyse. Certains outils Databricks, tels que les outils Genie, fonctionnent de cette manière.
  • Sortie texte. En l’absence de structuredContent, lisez plutôt les blocs de texte. Le premier bloc contient un document JSON, donc analysez result.content[0].text en tant que JSON.
  • Aucun des deux. MCP ne nécessite pas de schéma de sortie. Lorsqu’un outil n’en définit aucun, examinez une réponse d’exemple pour connaître ses champs de sortie.

Par exemple, system.ai.google_calendar expose des outils de lecture tels que calendar_event_list, dont le résultat JSON contient un tableau items d’événements (chacun avec id, summary, start, end, status, location et des liens). Les outils et les formes de résultats d’un service différent diffèrent totalement ; confirmez donc toujours avec tools/list et un appel d’exemple.

remarque

Les services intégrés gèrent leurs propres champs d’application OAuth. Un service peut n’exposer default qu’un sous-ensemble de ses outils en lecture seule lorsque sa stratégie de service intégrée bloque les écritures.

Enregistrer un serveur MCP externe

Pour tout serveur MCP externe non couvert par OAuth géré ou les services MCP fournis par Databricks, enregistrez-le en tant que service MCP afin de le régir comme un élément sécurisable Unity Catalog. Voir Enregistrer un serveur MCP externe.

Authentification et sécurité

Databricks utilise des proxys MCP gérés et des connexions HTTP Unity Catalog pour gérer en toute sécurité l'authentification auprès de serveurs MCP externes.

  • Authentification par principal partagé : Tous les utilisateurs partagent les mêmes identifiants lorsqu'ils accèdent au service externe. Ceci inclut le jeton Bearer, l'authentification OAuth Machine-to-Machine (M2M) et l'authentification OAuth User-to-Machine Shared. Utilisez ceci lorsque le service externe ne nécessite pas d’accès spécifique à l’utilisateur, ou lorsqu’un seul compte de service est suffisant.
  • Authentification par utilisateur (OAuth U2M par utilisateur) : Chaque utilisateur s’authentifie avec ses propres identifiants. Le service externe reçoit des requêtes au nom de l’utilisateur individuel, ce qui permet un contrôle d’accès, un audit et une responsabilité spécifiques à l’utilisateur. Utilisez cette option lors de l'accès à des Ressources spécifiques à l'utilisateur, telles que les repositories GitHub d'un utilisateur, les messages Slack ou le calendrier.

Databricks gère les flux OAuth et le refresh des jetons, de sorte que les utilisateurs finaux ne voient pas les jetons. Vous pouvez afficher et gérer vos connexions MCP externes parallèlement à vos Endpoint LLM depuis Unity Gateway. Pour des instructions de configuration détaillées pour chaque méthode d’authentification, consultez les connexions HTTP.

Activer l’accès par utilisateur (accès pour le compte de l’utilisateur)

Certains services lisent des données appartenant à un utilisateur spécifique, comme son calendrier ou son e-mail. Pour ces services, utilisez OAuth par utilisateur afin que chaque appel soit exécuté en tant qu’utilisateur l’ayant effectué, et non en tant qu’identité partagée. Ceci s’applique aux services system.ai.* intégrés tels que system.ai.google_calendar, system.ai.gmail et system.ai.microsoft_365, ainsi qu’aux services externes que vous enregistrez avec une authentification par utilisateur.

Pour configurer un accès « au nom de » à partir d’un agent :

  1. Assurez-vous que l’utilisateur appelant peut invoquer le service. L’appel de tout service MCP nécessite deux éléments :

    • EXECUTE sur le service.
    • USE CATALOG et USE SCHEMA sur son catalogue parent et son schéma. EXECUTE seul ne suffit pas, car Unity Catalog vérifie également la chaîne parente (voir Accorder l’accès aux collaborateurs).

    La manière dont vous les accordez dépend du service :

    • Services system.ai.* intégrés : les utilisateurs du compte détiennent déjà ces privilèges sur system et system.ai par default ; vous n’avez donc généralement rien à accorder.
    • Services personnalisés dans votre propre catalogue et schéma : accordez à l’utilisateur ou au groupe appelant les autorisations appropriées (et pas seulement au service principal Databricks de l’application) depuis l’onglet Autorisations de chaque élément sécurisable dans l’explorateur de catalogues, ou via l’API REST. Le DDL SQL n’est pas disponible pour les services MCP.

    Pour accorder des droits avec l’API REST, substituez votre propre <catalog>.<schema>.<service>:

    Bash
    databricks api patch "/api/2.1/unity-catalog/permissions/mcp_service/<catalog>.<schema>.<service>" \
    --json '{ "changes": [ { "principal": "data-team", "add": ["EXECUTE"] } ] }'
    databricks api patch "/api/2.1/unity-catalog/permissions/catalog/<catalog>" \
    --json '{ "changes": [ { "principal": "data-team", "add": ["USE_CATALOG"] } ] }'
    databricks api patch "/api/2.1/unity-catalog/permissions/schema/<catalog>.<schema>" \
    --json '{ "changes": [ { "principal": "data-team", "add": ["USE_SCHEMA"] } ] }'
  2. Ajoutez le périmètre d’API utilisateur ai-gateway à votre application afin que le jeton utilisateur transféré puisse atteindre le service. Déclarez user_api_scopes: [ai-gateway] sur la ressource de l’application et appelez le service avec le client par utilisateur (get_user_workspace_client()). Consultez Authentification auprès des services MCP et Créer un agent et le déployer sur Databricks Apps.

  3. Chaque utilisateur donne son consentement une seule fois. La première fois qu’un utilisateur appelle le service, il doit effectuer une connexion OAuth unique. Votre application reçoit un Link de connexion à présenter à l’utilisateur, ou l’utilisateur peut ouvrir le service dans Catalog Explorer et cliquer sur Connexion .

remarque

Vous ne pouvez pas accorder cet accès EXECUTE via un bundle. Une ressource Declarative Automation Bundles uc_securable ne prend en charge que les éléments sécurisables VOLUME, TABLE, FUNCTION et CONNECTION, et non les services MCP ; vous devez donc accorder EXECUTE séparément, via l’interface utilisateur ou l’API REST ci-dessus. Attention : databricks bundle validate ne signale pas l’autorisation manquante ; l’agent peut donc se déployer correctement, puis échouer uniquement lors du premier appel au service.

Mise en réseau

Les agents ne se connectent jamais directement au serveur MCP. Unity Gateway résout la connexion Unity Catalog du service, joint les identifiants gérés et effectue la requête sortante. Comme les services MCP s’exécutent sur des connexions HTTP Unity Catalog, cette requête est acheminée via le plan de compute serverless de votre Workspace comme toute autre connexion HTTP, et les mêmes contrôles réseau s’appliquent.

Autoriser un serveur MCP dans une politique réseau

Si votre workspace utilise le contrôle de sortie serverless avec un accès restreint , ajoutez le nom de domaine entièrement qualifié (FQDN) du serveur MCP à la liste Domaines autorisés de la politique. Voir Gérer les politiques réseau pour le contrôle de sortie serverless.

Ceci s’applique aux services system.ai.* fournis par Databricks ainsi qu’aux serveurs que vous enregistrez vous-même. Chaque service fourni par Databricks atteint sa propre destination ; autorisez donc les destinations pour les services que vous utilisez.

Gardez les points suivants à l’esprit lors de la configuration de la politique :

  • Recherchez la destination sur la connexion, puis confirmez avec les logs. Le FQDN est généralement l’hôte de l’URL du serveur MCP sur la connexion Unity Catalog du service, mais un service peut atteindre un hôte supplémentaire. Les connexions sortantes refusées sont enregistrées dans la table système system.access.outbound_network, le moyen le plus rapide de trouver tout hôte que vous devez encore ajouter. Voir la référence de la table système des événements d’accès réseau.
  • Les destinations bloquées s’appliquent toujours. Un hôte figurant dans les destinations bloquées de la politique est refusé, même avec un Accès complet . Voir Bloquer les destinations Internet.
  • Le mode simulation ne couvre le trafic MCP que sous « Tous les produits ». La sélection de l'option de simulation Databricks SQL ou AI model serving ne place pas le trafic du service MCP en mode simulation. Voir Application des politiques.

Lorsqu'une politique refuse un appel, la requête échoue avec une erreur d'autorisation qui nomme l'hôte bloqué, tel que Access to <fqdn> is denied because of serverless network policy.

Accéder à un serveur MCP de manière privée

Comme le trafic MCP est acheminé via votre plan de compute serverless, vous sécurisez le chemin sortant de la même manière que toute autre connexion HTTP.

Si vous hébergez le serveur au sein de votre propre réseau cloud, accédez-y de manière privée via Private Link au lieu de l’exposer à Internet, ou ajoutez les adresses IP sortantes serverless de Databricks à la liste d’autorisation de son pare-feu. Voir Sécuriser votre connectivité réseau vers des services externes.

Les domaines ajoutés en tant qu’entrées Private Link sont implicitement autorisés dans les politiques réseau ; ainsi, un serveur MCP routé de manière privée n’a pas besoin d’une entrée supplémentaire dans les Domaines autorisés .

Limitations

Les limitations suivantes s'appliquent aux services MCP :

  • Le DDL SQL pour les services MCP (par exemple, CREATE MCP SERVICE) n'est pas disponible. Créez et gérez les services MCP avec l'interface utilisateur ou l'API REST.

  • Vous pouvez uniquement enregistrer des serveurs MCP externes en tant que votre propre service MCP. L’enregistrement de sources d’entités Genie, Apps ou Unity Catalog en tant que service MCP n’est pas pris en charge actuellement.

  • Databricks fournit également des services MCP intégrés pour le workspace et les outils SaaS.

  • La sélection d'outils prend en charge les modèles de préfixe (get_*) et de correspondance exacte. Les modèles d'exclusion (par exemple, !delete_*) ne sont pas pris en charge.

  • La recherche globale d'Unity Catalog ne fait pas apparaître les services MCP.

  • Les serveurs MCP externes ne sont disponibles que dans les régions où Model Serving est pris en charge, y compris pour une utilisation dans AI Playground, Genie Code et Chat in Genie. Consultez la disponibilité des fonctionnalités de Model Serving.

Étapes suivantes