Critique de la frontière d'abstraction et de l'approche d'intégration des services du MCP

Une discussion sur Reddit dans r/ClaudeAI examine où le MCP trace sa limite d'abstraction et soutient qu'il se trompe d'une manière qui va au-delà des critiques d'implémentation typiques comme la sécurité, l'inflation des jetons ou les problèmes de transport.

Argument central sur l'intégration des services

Le message identifie trois préoccupations distinctes lorsqu'un agent doit travailler avec un service : l'accès aux API, les outils efficaces qui l'encapsulent et les connaissances du domaine sur la manière de l'utiliser correctement. Selon la source, le MCP regroupe les trois en une seule couche, ce qui donne un sous-ensemble limité de ce que l'API sous-jacente peut réellement faire.

Lattice comme exemple concret

La discussion utilise Lattice comme exemple spécifique. Leur client web est alimenté par une API GraphQL complète qui couvre tout ce qu'un employé voudrait faire. Cependant, leur API publique ne couvre que les flux de travail d'administration des RH. Le message soutient que le MCP incite les services à construire une autre interface limitée plutôt que d'ouvrir simplement les API qu'ils ont déjà.

Approche alternative proposée

L'auteur suggère une meilleure voie : que les services rendent leurs API principales universellement accessibles, notant que le problème d'authentification est déjà résolu par OAuth 2.0 avec PKCE. Les connaissances du domaine devraient être distribuées sous forme de compétences d'agent plutôt que d'être intégrées dans les définitions d'outils du MCP.

Le message complet est disponible sur tomyandell.dev/blog/my-problem-with-mcp, et la discussion sur Reddit invite les autres à partager leurs réflexions sur la question de savoir si cette critique de la limite d'abstraction est correcte.