Plug-ins pour Microsoft 365 Copilot

Les plug-ins permettent aux agents déclaratifs dans Microsoft 365 Copilot d’interagir avec les serveurs MCP (Model Context Protocol) ou les API REST qui ont une description OpenAPI. À l’aide d’un plug-in, les utilisateurs peuvent demander à un agent déclaratif non seulement d’interroger un serveur MCP ou une API REST pour obtenir des informations, mais également de créer, mettre à jour et supprimer des données et des objets. Tout ce que le serveur MCP ou l’API REST peut faire est accessible via des invites en langage naturel.

Importante

Les plug-ins ne sont pris en charge qu’en tant qu’actions dans des agents déclaratifs. Ils ne sont pas activés dans Microsoft 365 Copilot.

Un plug-in fournit un manifeste de plug-in que Copilot utilise pour apprendre les fonctionnalités du serveur MCP ou de l’API du plug-in. Copilot peut alors décider si un plug-in installé et activé est adapté pour répondre à une invite donnée. Pour en savoir plus sur le fichier manifeste requis par un module, consultez Schéma du manifeste du plug-in pour Microsoft 365 Copilot.

Comment Copilot découvre les outils du serveur MCP

Pour les plug-ins basés sur un serveur MCP, Copilot résout les outils du serveur de manière dynamique au moment de l’exécution par défaut, directement à partir du serveur MCP. La découverte d’outils dynamique permet aux utilisateurs d’obtenir les outils les plus récents exposés par le serveur MCP sans attendre que l’agent soit reconditionné et republié. Lors de la génération de l’agent, un développeur peut éventuellement épingler un ensemble fixe d’outils dans le manifeste du plug-in à la place. Les plug-ins de l’API REST utilisent toujours les outils définis dans le manifeste du plug-in. Pour plus d’informations, consultez Créer des plug-ins à partir d’un serveur MCP pour Microsoft 365 Copilot et Découverte d’outils dynamiques pour les plug-ins MCP dans Microsoft 365 Copilot.

Exemple de plug-in

Envisagez un serveur MCP de budgets qui permet d’interroger et de créer des budgets, de facturer des dépenses ou d’ajouter des fonds aux budgets existants. L’invite « Combien reste-t-il dans le budget de voyage de Contoso » pouvait déclencher un plug-in de budget, appelant l’outil get-budgets .

POST /mcp
Content-Type: application/json

{
  "method": "tools/call",
  "params": {
    "name": "get-budgets",
    "arguments": {
      "budgetName": "contoso travel"
    }
  }
}

Copilot utilise la réponse du résultat de l’outil pour générer sa réponse : « Le budget de voyage de Contoso dispose actuellement de 5 000 $ de fonds disponibles. Si vous avez besoin d’allouer des fonds à des catégories spécifiques ou de suivre les dépenses, je peux également vous aider. Faites-moi savoir comment je peux vous aider !

L’invite « Facturer 500 $ au budget de voyage Contoso pour le billet d’avion de Megan » peut être traduite par l’appel de l’outil MCP suivant.

POST /mcp
Content-Type: application/json

{
  "method": "tools/call",
  "params": {
    "name": "charge-budget",
    "arguments": {
      "budgetName": "contoso travel",
      "amount": 500,
      "description": "Megan's airline ticket"
    }
  }
}

Copilot répond à l’utilisateur en utilisant les informations renvoyées : « Les frais de 500 USD pour le billet d’avion de Megan sont traités avec succès. Le budget de voyage de Contoso dispose désormais de 4 500 $ de fonds disponibles. Si vous devez effectuer d’autres transactions ou si vous avez besoin d’une aide supplémentaire pour votre budget, faites-le moi savoir !

Fonctionnement des plug-ins

Un diagramme de séquence montrant le flux de données du plug-in

  1. L’utilisateur demande à l’agent : « Combien reste-t-il dans le budget de rénovation du hall du Fourth Coffee ? »

  2. Pour un plug-in MCP qui utilise la découverte dynamique d’outils, l’agent récupère les définitions d’outils actuelles à partir du serveur MCP du plug-in au moment de l’exécution et valide tous les outils nouveaux ou modifiés avant de les utiliser. Pour un plug-in avec un jeu d’outils épinglé ou pour un plug-in d’API REST, l’agent utilise les outils définis dans le manifeste du plug-in à la place.

  3. L’agent identifie un plug-in lié au budget à partir de ses plug-ins disponibles qui dispose d’un outil ou d’une API GetBudget serveur MCP pour obtenir les détails du budget. Il mappe des parties de la question de l’utilisateur aux paramètres de la fonction : budgetName="".

  4. L’agent demande à l’utilisateur de l’autoriser à envoyer Fourth Coffee lobby renovation au plugin.

  5. L’utilisateur choisit d’autoriser le partage des données avec le plug-in une fois, ou choisit de toujours autoriser le partage des données pour cette fonction.

  6. Si le serveur MCP ou l’API du plug-in nécessite une authentification, le plug-in demande un jeton ou une clé API au magasin de jetons.

  7. Le magasin de jetons renvoie un jeton ou une clé. Si nécessaire, l’agent amène l’agent à inviter l’utilisateur à se connecter.

  8. L’agent envoie une demande au serveur MCP ou à l’API du plug-in, qui est hébergé en dehors de Microsoft 365.

  9. Le serveur MCP ou l’API retourne une réponse.

    {
  "name": "Fourth Coffee lobby renovation",
  "availableFunds": 5000.00
}

  10. L’agent génère une réponse basée sur la réponse du serveur MCP ou de l’API.

  11. L’agent envoie la réponse suivante : « Les fonds disponibles dans le budget de rénovation du hall du Fourth Coffee sont de 5 000 $. »

Actions de confirmation

Copilot demande à l’utilisateur avant d’envoyer des données pour la première fois à un module.

Capture d’écran de la boîte de dialogue de confirmation d’un module.

Une fois que l’utilisateur a confirmé la connexion, les outils et API du serveur MCP qui récupèrent uniquement les données ne nécessitent pas de confirmation, contrairement aux outils et API qui modifient les données. Les développeurs de plug-ins peuvent remplacer ces valeurs par défaut. Pour plus d’informations, consultez Invites de confirmation pour MCP et les plug-ins d’API pour Microsoft 365 Copilot.

Personnalisation de la présentation de la réponse

Copilot génère des réponses conversationnelles en utilisant les données du serveur MCP ou les réponses de l’API. Les plugins peuvent personnaliser la façon dont ces données sont présentées et le mécanisme dépend du type de plugin.

  • Les plug-ins MCP peuvent fournir des réponses riches et interactives en utilisant des applications MCP : widgets d’interface utilisateur que le serveur MCP retourne avec le résultat de l’outil au moment de l’exécution. Étant donné que le widget est fourni avec la réponse de l’outil plutôt que défini dans le manifeste, les applications MCP fonctionnent, que le plug-in utilise un ensemble d’outils épinglés ou une découverte d’outil dynamique.

  • Les plugins d’API peuvent fournir des modèles de carte adaptative dans le manifeste du plugin pour afficher les données de manière structurée. Étant donné que les modèles sont définis par rapport aux opérations déclarées dans le manifeste, cette approche s’applique aux plug-ins d’API et aux plug-ins MCP qui utilisent un ensemble d’outils épinglés.

Pour les citations liées à la source sur n’importe quel type de plug-in, Copilot utilise la sémantique de réponse et peut déduire automatiquement les métadonnées de citation à partir de l’outil ou de la réponse API. L’inférence automatique est particulièrement utile pour les plug-ins MCP qui utilisent la découverte d’outils dynamique, où les outils sont résolus au moment de l’exécution et où il n’y a aucune définition d’outil de manifeste à configurer. Pour plus d’informations, voir Afficher les citations avec la sémantique des réponses.

Capture d’écran d’une réponse de carte adaptative à partir d’un plug-in d’API

Gestion des URL dans les réponses d’action

L’expérience de conversation Microsoft 365 Copilot peut afficher les URL retournées dans le cadre des réponses à l’action (qu’il s’agisse de plug-ins MCP, de plug-ins d’API, de connecteurs ou de flux) sous forme de liens cliquables. Le runtime Copilot contrôle ce comportement et ne l’évalue pas par rapport aux domaines déclarés par le plug-in (comme la section de la servers description OpenAPI d’un plug-in d’API).

Les règles de sécurité, de confiance et de stratégie de la plateforme régissent le comportement de rendu des URL pour les réponses d’action et peuvent changer au fil du temps. Ne vous fiez pas aux URL cliquables dans les réponses d’action pour les scénarios critiques pour la production.

Aidez l’orchestrateur Copilot à choisir votre plug-in

Microsoft 365 Copilot peut choisir de manière unique la compétence appropriée parmi les nombreuses compétences de son répertoire. Mais comment s’assurer que Copilot choisit votre plug-in pour fournir la bonne compétence ?

La réponse réside dans la façon dont vous décrivez votre plugin, ses compétences et les paramètres d’initiation des compétences. Spécifiez des descriptions concises et précises dans votre manifeste de plug-in pour vous assurer que l’orchestrateur Copilot sait quand et comment appeler votre plug-in.

La façon dont vous décrivez votre plug-in à l’orchestrateur dépend du type de plug-in que vous créez, comme décrit dans le tableau suivant.

Type de plug-in Décrit par En savoir plus
Plug-ins d’API Description d’OpenAPI Comment rendre un document OpenAPI efficace dans l’extension de Copilot
Actions Copilot Studio Noms et descriptions dans la carte de conversation Copilot Studio Orchestrer les rubriques et les actions Copilot avec l’IA générative
Plug-ins d’extension de message Manifeste d'application Instructions pour les plug-ins d’extension de message

Créer un plug-in d’agent déclaratif

Les développeurs peuvent utiliser deux outils pour générer des packages de plug-in d’API :

  • Microsoft 365 Agents Toolkit dans Visual Studio ou Visual Studio Code crée des packages de plug-ins basés sur un serveur MCP existant ou sur la description d’OpenAPI. Agents Toolkit dispose également de projets de démarrage avec un exemple d’API et le package de plugins correspondant.
  • Kiota est un outil en ligne de commande et une extension de Visual Studio Code qui génère des packages de plug-in basés sur une description OpenAPI existante.

Conseil

Work IQ Dev Tools (préversion) : vous pouvez également attacher et cocher des actions à partir de la ligne de commande et les faire une case activée. wiqd agent add action ajoute une action à un agent déclaratif et wiqd agent validate --mode deep confirme que la description OpenAPI d’une action est accessible et bien formée et qu’un manifeste de plug-in référencé déclare le bon schéma d’authentification. Une arborescence de commandes alpha wiqd plugin existe également, mais son interface est susceptible d’être modifiée. Pour plus d’informations, consultez la documentation sur les outils de développement Work IQ.

Limitations

Lorsqu’un agent déclaratif inclut jusqu’à cinq plug-ins définis dans le manifeste de l’agent déclaratif, l’agent injecte toujours les plug-ins dans l’invite. Lorsque l’agent inclut plus de cinq plug-ins, il utilise la correspondance sémantique. La correspondance sémantique est basée sur la description du plugin, et non sur l’une des fonctions ou outils individuels du plugin lui-même.

Un plugin peut inclure un nombre illimité de fonctions ou d’outils MCP. Toutes les fonctions ou outils d’un plug-in correspondant sont retournés, même si un seul est mis en correspondance. Pour un plug-in MCP qui utilise la découverte d’outils dynamique, les outils résolus à partir du serveur MCP au moment de l’exécution sont comptabilisés dans ce total. En raison des limites de fenêtre de jeton, la qualité des réponses peut se dégrader si plus de 10 fonctions ou outils sont inclus.

La fenêtre de jeton pour les entrées et les sorties d’un plug-in tronque le contenu volumineux. La limite fonctionnelle est susceptible d’être modifiée à mesure que les modèles s’améliorent et en fonction de toute surcharge du système. Optimisez les petites longueurs de jeton ou optez pour des options d’extensibilité qui permettent de diffuser en continu du contenu volumineux si nécessaire.

Contenu connexe

  • Last updated on