OpenAI ajoute la prise en charge de MCP à l’Agents SDK

 (openai.github.io)
8 points par GN⁺ 2025-03-27 | 4 commentaires | Partager sur WhatsApp
  • MCP (Model Context Protocol) est une méthode standardisée permettant de fournir des outils et du contexte aux LLM
  • Comme un port USB-C, il sert d’interface standard pour connecter des modèles d’IA à diverses sources de données ou à divers outils
  • L’OpenAI Agents SDK prend en charge MCP, ce qui permet l’intégration avec divers serveurs MCP

Serveurs MCP

  • La spécification MCP définit actuellement deux types de serveurs selon le mécanisme de transport utilisé :
    1. Les serveurs stdio s’exécutent comme sous-processus de l’application et peuvent être considérés comme s’exécutant en « local ».
    2. Les serveurs HTTP over SSE s’exécutent à distance et se connectent via une URL.
  • Vous pouvez vous connecter à ces serveurs à l’aide des classes MCPServerStdio et MCPServerSse.
  • Par exemple, voici comment utiliser le serveur officiel MCP pour le système de fichiers : 
    async with MCPServerStdio(  
    params={  
        "command": "npx",  
        "args": ["-y", "@modelcontextprotocol/server-filesystem", samples_dir],  
    }  
) as server:  
    tools = await server.list_tools()

Mise en cache

  • Appeler list_tools() sur un serveur MCP à chaque exécution d’un agent peut entraîner de la latence, en particulier si le serveur est distant.
  • Pour mettre automatiquement en cache la liste des outils, vous pouvez passer cache_tools_list=True à MCPServerStdio et MCPServerSse. Cela ne doit être fait que si vous êtes certain que la liste des outils ne changera pas.
  • Pour invalider le cache, vous pouvez appeler invalidate_tools_cache() sur le serveur.

À lire aussi

4 commentaires

 
GN⁺ 2025-03-27
Avis sur Hacker News

  • Aujourd’hui, MCP a ajouté Streamable HTTP. C’est une avancée majeure, car cela évite d’avoir à maintenir en permanence une connexion à un serveur HTTP distant

    • Mais à la lecture de la spécification, introduire un paradigme de type LSP sur un serveur HTTP distant ajoute beaucoup de complexité
    • Traditionnellement, on envoyait simplement { "location": "New York" } en HTTP POST à /get_weather
    • J’ai proposé de réduire la complexité et de revenir à des serveurs HTTP traditionnels. Les sessions seraient négociées via l’en-tête Authorization et on utiliserait des endpoints classiques
    • Construire un serveur serait bien plus simple, et les frameworks web n’auraient pas besoin d’être mis à jour pour se conformer à la spécification

  • Il y a cette analogie qui consiste à voir MCP comme le port USB-C des applications d’IA

    • En tant qu’ingénieur logiciel, cette analogie ne m’aide pas

  • Je me demandais si OpenAI allait le soutenir officiellement, et maintenant j’ai ma réponse

    • MCP est devenu le standard de fait de l’industrie pour connecter les LLM à des outils externes

  • J’espérais un support d’OpenAPI. J’ai créé quelques serveurs MCP, mais j’ai l’impression que c’est une API moins flexible et moins bien documentée

    • J’ai du mal à voir en quoi MCP est meilleur qu’OpenAPI. Il y a un peu moins de code, mais beaucoup moins d’options
    • Avec le temps, Swagger finira par être intégré

  • J’ai du mal à comprendre la valeur de MCP. Au milieu du désordre des technologies d’IA modernes, ça ressemble à une distraction de plus

    • MCP est un protocole ouvert qui standardise la manière dont les applications fournissent du contexte aux LLM
    • Je me demande ce qu’il y a réellement à standardiser. Nous utilisons des convertisseurs texte-vers-texte qui fonctionnent sur des chaînes tokenisées arbitraires
    • Même des choses comme l’appel d’outils/fonctions ne sont que des heuristiques astucieuses construites au-dessus d’un simple texte

  • J’ai construit une architecture qui permet aux agents IA d’utiliser des « outils » en local. Elle fonctionne avec toutes sortes de LLM et de serveurs LLM

    • Elle sert de middleware et fonctionne en flux entre le serveur LLM et le client de chat
    • C’est un projet open source, mais le dépôt n’est plus mis à jour parce que personne ne semble intéressé par le code

  • Il manque des vidéos montrant concrètement comment utiliser MCP. Il manque aussi des cas d’usage vraiment concrets pour les programmeurs

  • Il y a cette analogie qui consiste à voir MCP comme le port USB-C des applications d’IA

    • Vu tout ce qu’on entend sur la souffrance qu’implique l’implémentation d’USB, il vaudrait mieux trouver une autre analogie

  • Cela semble viser HTTP+SSE, l’ancienne version de MCP, et non la nouvelle version Streaming HTTP

    • Il y a aussi le support d’OAuth 2.1, le batching JSON-RPC, etc.

  • Si vous voulez tester MCP simplement, j’ai créé <a href="https://skeet.build/mcp" rel="nofollow">skeet.build/mcp</a>

    • Je l’ai créé à cause de la complexité de la configuration MCP, du manque de support et de la difficulté à tout construire soi-même
    • Il est surtout utilisé pour des workflows comme ceux-ci
      • rédiger un résumé au démarrage d’une PR
      • résumer dans Slack ou en commentaire sur Linear/Jira
      • récupérer des issues depuis Sentry puis les corriger
      • créer une issue Linear lorsqu’un bug est détecté
      • récupérer une issue Linear et faire une première passe
      • récupérer des documents Notion et des PRD pour générer une référence d’API à partir de la base de code
      • exploiter un schéma Postgres ou MySQL pour un prototypage rapide de modèles
    • L’accent est mis sur la facilité d’utilisation, des workflows développeur pratiques et des serveurs MCP de haute qualité
 
samchon 2025-03-27

Je pense aussi que l’OpenAPI function calling n’est-il pas meilleur ? Rien que le fait de tout refaire avec le protocole MCP, c’est déjà du travail.
 
mangoblue 2025-03-28

N’est-ce pas plutôt la différence entre push et poll ? J’ai l’impression que, pour un tiers, il est plus pratique d’héberger la spécification MCP et de laisser l’agent venir la récupérer par poll, plutôt que de faire du function calling pour chaque modèle ou service.