Kritik an der Abstraktionsgrenze und Service-Integrationsansatz des MCP

Eine Reddit-Diskussion auf r/ClaudeAI untersucht, wo MCP seine Abstraktionsgrenze zieht, und argumentiert, dass es dabei einen Fehler macht, der über typische Implementierungskritiken wie Sicherheit, Token-Aufblähung oder Transportprobleme hinausgeht.

Kernargument zur Service-Integration

Der Beitrag identifiziert drei separate Anliegen, wenn ein Agent mit einem Dienst arbeiten muss: API-Zugang, effiziente Werkzeuge, die ihn umschließen, und Domänenwissen darüber, wie man ihn gut nutzt. Laut der Quelle bündelt MCP alle drei in einer Ebene, was zu einer begrenzten Teilmenge dessen führt, was die zugrundeliegende API tatsächlich leisten kann.

Lattice als konkretes Beispiel

Die Diskussion verwendet Lattice als spezifisches Beispiel. Deren Web-Client wird von einer vollständigen GraphQL-API angetrieben, die alles abdeckt, was ein Mitarbeiter tun möchte. Ihre öffentliche API deckt jedoch nur HR-Administrations-Workflows ab. Der Beitrag argumentiert, dass MCP Dienste dazu anregt, eine weitere begrenzte Schnittstelle zu bauen, anstatt einfach die APIs zu öffnen, die sie bereits haben.

Vorgeschlagener alternativer Ansatz

Der Autor schlägt einen besseren Weg vor: Dienste sollten ihre primären APIs allgemein zugänglich machen, wobei er anmerkt, dass das Authentifizierungsproblem bereits durch OAuth 2.0 mit PKCE gelöst ist. Domänenwissen sollte als Agenten-Fähigkeiten verteilt werden, anstatt in MCP-Werkzeugdefinitionen eingebaut zu sein.

Der vollständige Beitrag ist verfügbar unter tomyandell.dev/blog/my-problem-with-mcp, und die Reddit-Diskussion lädt andere ein, ihre Gedanken dazu zu teilen, ob diese Kritik an der Abstraktionsgrenze zutreffend ist.