Was ist MCP und wozu braucht es Ihre ChatGPT App

1. Warum braucht man überhaupt ein eigenes Protokoll

In diesem Modul klären wir endlich, was MCP (Model Context Protocol) ist und wie es in den Stack der ChatGPT App passt. Beginnen wir damit, die Rolle von MCP in der Architektur zu fixieren, es mit dem „typischen REST“ zu vergleichen und die zentralen Entitäten des Protokolls zu verstehen: tools, resources und prompts.

Stellen Sie sich vor, Sie schreiben einen gewöhnlichen Web‑Service. Nach guter alter Tradition stellen Sie ein REST-API bereit: Sie haben /api/gifts, /api/users, /api/orders, jeweils mit eigenem Ein‑ und Ausgabeformat, eigenen Fehlercodes und eigener Autorisierung. Das ist vertraut, aber es gibt einen Haken: Jedem Client müssen Sie erklären, was und wie Sie implementiert haben. Dokumentation, OpenAPI, Beispiele, SDKs – all das ist nötig, weil Sie das API‑Format selbst definiert haben.

Mit der ChatGPT App wird es komplexer. Ihr Client ist nicht nur das Frontend, sondern auch das Modell selbst. Es muss:

• erfahren, welche Operationen überhaupt verfügbar sind;
• verstehen, welche Argumente jede Operation benötigt;
• diese Operationen im Verlauf des Dialogs aufrufen – teils mehrfach, teils mit unterschiedlichen Parametern;
• die strukturierte Antwort interpretieren und entscheiden, was dem Benutzer angezeigt wird und was nur als Kontext für die nächste Antwort dient.

Wenn jede Entwicklerin/jeder Entwickler ihr/sein eigenes API‑Format erfindet, landet das Modell in der Integrationshölle: Für jede App wäre ein kundenspezifischer Client, viel „Boilerplate“ und fragile Logik nötig. Das Problem löst die Idee eines Protokolls.

MCP (Model Context Protocol) ist eine offene Spezifikation eines Standardverfahrens, wie ein LLM‑Client (ChatGPT, IDE‑Plugin, Agent etc.) mit Ihrem Server für Tools und Daten kommuniziert. Es definiert eine gemeinsame Sprache, in der der Server seine Tools, Ressourcen und Prompts deklariert und der Client sie aufruft und die Ergebnisse empfängt.

Anschaulich ist MCP der USB‑C‑Port der AI‑Welt: Wenn Sie einen „USB‑Stick“ bauen (Service, Datenbank, CRM, Suchmaschine), brauchen Sie einen standardisierten Anschluss. Dann kann sich jeder „Laptop“ (ChatGPT, anderer Agent, IDE) ohne Spezialkabel verbinden.

2. Blick von oben: Wo MCP in der Architektur der ChatGPT App sitzt

Um das Bild zu festigen, erinnern wir uns an die bereits bekannte Architektur – jetzt mit einer expliziten MCP-Schicht.

Das bisherige mentale Modell haben Sie schon gesehen: Der Benutzer spricht mit ChatGPT, innerhalb des Dialogs wird ein Widget gerendert (Apps SDK), und irgendwo außerhalb lebt Ihr Backend. Jetzt fügen wir MCP hinzu und legen alles in Schichten.

Hier ist ein vereinfachtes Schema:

Benutzer
   ↓ (natürliche Sprache)
ChatGPT (Modell + UI)
   ↓ (Tool-Calls über MCP)
MCP-Client innerhalb von ChatGPT
   ↓ (JSON‑RPC, MCP)
Ihr MCP-Server (Backend)
   ↓
Ihre DB / externe APIs / Queues

Mit „MCP-Client innerhalb von ChatGPT“ ist der interne Teil der Plattform gemeint, der mit Ihrem MCP-Server über das Protokoll spricht: Discovery durchführt, Tools aufruft und Ressourcen liest.

Aus Sicht des Apps SDK besteht eine minimale ChatGPT App aus drei Komponenten. Erstens: ein MCP-Server, der Tools deklariert und strukturierte Daten liefert. Zweitens: ein UI‑Bundle (Widget), das innerhalb von ChatGPT gerendert wird und diese Daten über window.openai liest. Drittens: das Modell selbst, das entscheidet, wann welches Tool aufgerufen wird und wie dem Benutzer geantwortet wird.

Wichtig ist Folgendes: In den vorherigen Modulen haben Sie viel auf der Ebene des Apps SDK und des Widgets gearbeitet, also im oberen Teil des Schemas. Jetzt steigen wir auf die Ebene des MCP-Servers hinab – das ist Ihre offizielle „Sprache“ für die Kommunikation mit ChatGPT und allen anderen Clients, die Ihre App nutzen wollen.

3. MCP gegenüber „typischem REST“: worin liegt der Unterschied

Im Schema oben haben wir festgehalten, wo MCP in der Architektur der ChatGPT App sitzt. Nun vergleichen wir sorgfältig die Ansätze „eigenes REST“ und MCP, damit klar wird, warum im Kontext von ChatGPT Apps Letzteres fast immer gewinnt.

Beim REST-Ansatz entwerfen Sie Endpunkte, Anfrage‑ und Antwortformate so, wie es Ihnen passt. Damit ein Client mit Ihnen arbeiten kann, muss er URLs, Methoden, Schemata und Fehlercodes kennen. Manchmal hilft OpenAPI, manchmal schicken Sie einfach eine Beispielanfrage im README. Das Modell versteht davon nichts: Es braucht eine Codeschicht, die „Finde ein Geschenk für Mama zum 50.“ in eine konkrete HTTP‑Anfrage verwandelt und die JSON‑Antwort zurück in Daten, die für den Dialog taugen.

Bei MCP ist alles anders. Das Protokoll legt fest:

• wie der Client die Liste Ihrer Tools ermitteln kann;
• wie Argumente und Ergebnisse per JSON Schema beschrieben werden;
• wie Ressourcen und Prompts beschrieben werden;
• wie ein Tool‑Aufruf und dessen Antwort aussehen.

Dadurch können ChatGPT und andere MCP-Clients automatisch:

• discovery ausführen – herausfinden, welche tools/resources/prompts es bei Ihnen gibt;
• ein internes Parametrisierungsschema für jedes Tool aufbauen;
• Tools ohne kundenspezifische Hardcode‑Logik des Clients aufrufen;
• Metadaten cachen und sie bei Suche und Ranking von Anwendungen verwenden.

Das lässt sich in einer kleinen Tabelle zusammenfassen.

Emotional formuliert: REST ist „jeder für sich“, MCP ist „eine Vereinbarung aller Beteiligten, wie mit Modell und Daten kommuniziert wird“.

4. Zentrale Entitäten von MCP: tools, resources, prompts

Benennen wir nun die drei Hauptdarsteller von MCP: Tools, Ressourcen und Prompts.

Tools: Aktionen, an die Sie bereits gewöhnt sind

Mit Tools sind Sie schon in Modul 4 in Berührung gekommen: Dort haben wir ein Tool beschrieben, ihm Namen, Beschreibung und eine JSON‑Schema der Argumente gegeben, und anschließend hat das Modell es über callTool aufgerufen. Auf MCP-Ebene ist ein Tool eine Server‑Operation mit klarem Vertrag:

• Name und Beschreibung (für das Modell sowie für UX/Discovery);
• JSON Schema für die Argumente;
• JSON Schema oder eine Beschreibung der Struktur des Ergebnisses;
• zusätzliche Metadaten (z. B. Bindung an eine bestimmte UI‑Komponente im Apps SDK).

Ein MCP-Server muss mindestens in der Lage sein, auf „Anfrage nach der Tool‑Liste“ zu antworten und „Tool‑Aufrufe“ zu verarbeiten und dabei ein strukturiertes Ergebnis zurückzugeben.

In unserer Übungsanwendung, dem Geschenk‑Assistenten, gibt es beispielsweise das Tool suggest_gifts, das Alter, Beziehung, Budget und ein paar Vorlieben annimmt und eine Liste empfohlener Geschenke zurückgibt.

Ein hypothetischer TypeScript‑Sketch eines solchen Tools im Code des MCP-Servers könnte etwa so aussehen (Pseudocode/Stub):

// Pseudocode, kein finales SDK-API
const suggestGiftsTool = defineTool({
  name: "suggest_gifts",
  description: "Findet Geschenkideen anhand der Parameter des Empfängers",
  inputSchema: z.object({
    age: z.number(),
    relation: z.enum(["friend", "partner", "parent"]),
    budgetUsd: z.number(),
  }),
  handler: async (input) => {
    // TODO: Ihre Geschäftslogik
    return { items: [] };
  },
});

Echte Signaturen werden wir in den nächsten Vorlesungen betrachten; hier ist die Idee wichtig: Ein Tool ist nicht einfach ein REST-Endpunkt, sondern ein Protokollbaustein mit deklariertem Schema.

Ressourcen (resources): Daten, die per ID/URI adressiert werden können

Ressourcen (resources) in MCP sind ein Weg, verfügbare Daten zu beschreiben: Dateien, Verzeichnisse, DB‑Einträge, Wiki‑Seiten, sogar Ergebnisse von Suchindizes. Ein Client kann:

• eine Liste von Ressourcen erhalten;
• eine konkrete Ressource per ID/URI lesen;
• manchmal – eine Suche darüber ausführen.

Im Unterschied zu Tools, die „etwas tun“, „speichern“ Resources üblicherweise „etwas“. In der Gift‑App könnten Sie beispielsweise den Produktkatalog als Ressource gift_catalog modellieren, den das Modell anspricht, um verfügbare Kategorien, Filter, Preisspannen usw. zu erfahren.

Im Code kann das konzeptionell so aussehen:

const giftCatalogResource = defineResource({
  uri: "catalog://gifts",
  description: "Geschenk‑Katalog, der für Empfehlungen verfügbar ist",
  read: async () => {
    // Wir geben die Struktur des Katalogs zurück
    return { categories: [], priceRanges: [] };
  },
});

Wir tauchen noch nicht in das Format der MCP-Nachrichten ein, behalten aber im Hinterkopf: Ressourcen sind adressierbare Entitäten, auf die der MCP-Server verweisen und die der Client lesen kann, um sie als Teil des Kontexts zu verwenden.

Prompts: vorbereitete Eingabevorlagen

Prompts im Kontext von MCP sind Vorlagen für Anfragen oder Instruktionen, die der Server dem Client bereitstellen kann. Beispielsweise können Sie den Prompt gift_followup deklarieren, der beschreibt, wie das Modell beim Benutzer Details zum Geschenkempfänger nachfragt, bevor es ein Tool aufruft.

Ein typisches Beispiel im Sinne des Protokolls: Der Server liefert Name, Zweck und ggf. Parameter eines Prompts. Der Client kann die Liste der Prompts abfragen, den passenden auswählen und in eine Anfrage an das Modell einfügen.

Wozu braucht das die ChatGPT App? Erstens bietet es eine einheitliche Möglichkeit, komplexe Prompts zwischen Clients wiederzuverwenden. Zweitens macht MCP solche Prompts explizit und „vertragsgebunden“, statt sie an zufälligen Stellen im Code zu verstecken.

Capabilities: Erklärung dessen, was Sie überhaupt unterstützen

Schließlich gibt es noch das vierte Element – capabilities. Das ist eine reine Deklaration: Der Server sagt, welche Entitäten er unterstützt (Tools, Resources, Prompts, Notifications etc.) und welche Methoden genau implementiert sind. Für den Client ist das eine Möglichkeit, nicht zu raten, was geht, sondern sein Verhalten sauber an die Fähigkeiten des Servers anzupassen.

In der Praxis führt ChatGPT beim Verbindungsaufbau zu Ihrem MCP-Server zunächst ein „Handshake“ durch, erhält eine Liste der Capabilities und fragt dann: „Okay, zeig mir deine Tools und Ressourcen.“

5. Wie MCP in Ihre aktuelle App passt

Das klingt etwas abstrakt, aber tatsächlich sind Sie MCP bereits über das Apps SDK begegnet. Es lohnt sich zu klären, wie das mit dem zusammengeht, was Sie im Apps SDK bereits gebaut haben. Verknüpfen wir die gerade eingeführten Entitäten mit dem aktuellen Aufbau Ihres App‑Templates.

Erinnern wir uns an die Kette, die Sie im Template bereits umgesetzt haben:

1. Das Widget ruft über window.openai oder bereitgestellte Hooks callTool mit dem Tool‑Namen und den Argumenten auf.
2. Das Apps SDK innerhalb von ChatGPT wandelt dies in einen Aufruf des Serverteils der App um.
3. Der Server führt das Tool aus und gibt ein ToolOutput zurück, das structuredContent, content und _meta enthält.
4. Das Widget erhält das ToolOutput und rendert das UI.

Das Geheimnis: Die Schritte 2–3 sind als Dialog über MCP implementiert. Ihr Next.js‑Template enthält einen Endpunkt (meist app/mcp/route.ts oder ähnlich), der genau der MCP-Server ist. Er:

• registriert Ihre Tools;
• beschreibt sie mittels JSON Schema;
• implementiert die Handler;
• antwortet ChatGPT auf MCP-Anfragen list tools und call tool.

Das heißt: Selbst jetzt, mit dem Template, arbeiten Sie bereits mit MCP, nur „automatisch“ – der Großteil der Protokollmagie ist im SDK versteckt.

Modul 6 ist dazu da, MCP nicht länger als „magische Black Box“ zu sehen, sondern es bewusst zu gestalten:

• Tools hinzufügen und versionieren;
• Resources und Prompts nutzen, nicht nur Tools;
• MCP-Logs lesen und verstehen;
• bei Bedarf eigene MCP-Server außerhalb des Next.js‑Templates betreiben (z. B. einen Python‑Service für eine ML‑Modellarbeit oder einen separaten Service für den Zugriff auf eine Unternehmensdatenbank).

6. MCP aus unterschiedlichen Blickwinkeln: Product vs. Entwickler

Es ist hilfreich, getrennt zu formulieren, was MCP einem Product‑Manager und was es einem Entwickler bringt.

MCP für den Product‑Manager

Aus Produktsicht ist MCP eine Möglichkeit, Ihren Service zu einem „Steckmodul“ für einen ganzen Zoo von Clients zu machen: ChatGPT, andere LLM‑Clients, IDE‑Plugins, eigene Agenten. Einmal die Fähigkeiten des Servers als Satz aus tools/resources/prompts beschrieben, ermöglichen Sie jedem Client:

• Ihren Service automatisch zu entdecken;
• zu verstehen, welche Aufgaben er löst;
• notwendige Operationen sicher aufzurufen.

Bei der ChatGPT App erhöht das zudem die Wahrscheinlichkeit, dass Ihre Anwendung ausgewählt wird: Das Modell nutzt Metadaten über Ihre Tools, um zu entscheiden, wann es Ihre App vorschlägt und wie es sie dem Benutzer richtig präsentiert.

Kurz gesagt: MCP macht Ihren Service zu einem standardisierten „Baustein“ des Ökosystems statt zu einer kundenspezifischen Integration für ein oder zwei Clients.

MCP für Entwickler

Aus Entwicklersicht ist MCP ein Vertrag und ein Protokoll. Es beantwortet Fragen wie:

• In welchem Format muss ich ein Tool deklarieren?
• Wie beschreibe ich Argumente und liefere Ergebnisse zurück?
• Wie erfährt der Client, dass ich Ressourcen und Prompts unterstütze?
• Welcher JSON fließt überhaupt über das Netz?

Mit einem solchen Protokoll wird es einfacher:

• Server in verschiedenen Sprachen zu schreiben (es gibt offizielle SDKs für TypeScript und Python);
• die Anwendung mit dem MCP Inspector oder ähnlichen Tools zu debuggen;
• Verantwortlichkeiten zwischen Teams aufzuteilen: Ein Team baut den MCP-Server mit Daten und Tools, ein anderes das Widget im Apps SDK, ein drittes kann eigene Agenten auf demselben MCP-Server aufsetzen.

7. Kleine praktische Perspektive: unser erster MCP-Server

In dieser Vorlesung gehen wir absichtlich nicht in die Details des Nachrichtenformats und der Serverimplementierung – das ist Stoff der nächsten Themen. Damit Sie aber wissen, wohin die Reise geht, ist es nützlich, die grobe Struktur eines minimalen MCP-Servers in TypeScript zu sehen.

In der Praxis liefert die offizielle TypeScript‑Bibliothek von MCP Ihnen Primitive zum Erstellen eines Servers, zum Registrieren von tools/resources/prompts und zum Starten des Transports (in der Regel HTTP oder SSE).

Ein hypothetisches Pseudo‑Beispiel könnte so aussehen:

// Das ist ein konzeptionelles Beispiel, das SDK‑API besprechen wir später
import { createServer } from "@modelcontextprotocol/sdk";

const server = createServer({
  name: "gift-genius",
  version: "1.0.0",
});

// Wir registrieren ein Tool
server.tool("suggest_gifts", {
  description: "Wählt Geschenke anhand der Vorlieben des Empfängers aus",
  inputSchema: {/* ... */},
  handler: async (input) => {
    // Ihre Logik
    return { items: [] };
  },
});

// Transport starten (z. B. HTTP)
server.listen(3001);

Wichtig: Hier wird weder ChatGPT noch das Apps SDK noch Ihr konkretes Frontend erwähnt. Der MCP-Server ist eigenständig. Er beantwortet schlicht MCP-Anfragen. Die ChatGPT App ist nur ein Typ von Client, der einen solchen Server nutzen kann.

Im Rahmen des Kurses bleiben wir beim Next.js‑Template, in dem der MCP-Server als Teil des Projekts lebt – das ist aber nicht die einzige Möglichkeit.

8. MCP im Ökosystem: Apps SDK, Agents SDK und ACP

Damit Sie MCP nicht als „Feature nur für das Apps SDK“ wahrnehmen, lohnt sich der Blick aufs größere Bild.

Erstens stützt sich das Apps SDK direkt auf MCP als Standardbrücke zwischen ChatGPT und externen Services. Die offizielle Dokumentation betont: Das Apps SDK arbeitet mit beliebigen MCP-Servern. Das Protokoll selbst erlaubt es, Tools zu beschreiben, strukturierte Daten zurückzugeben und eine Komponente für das UI‑Rendering anzugeben.

Zweitens kann sich das Agents SDK, das Sie in einem separaten Modul betrachten werden, ebenfalls mit MCP-Servern verbinden. Das bedeutet: ein und derselbe MCP-Server mit Geschäftslogik kann verwendet werden

• innerhalb von ChatGPT als Teil Ihrer App;
• innerhalb eines autonomen Agenten, der z. B. im Hintergrund Ihres Produkts oder im Batch‑Modus läuft.

Drittens baut ACP (Agentic Commerce Protocol), das Sie für Käufe und Instant Checkout brauchen, logisch auf dem MCP-Ansatz auf: Das Modell und die Agenten rufen Commerce‑Tools auf, die ebenfalls über standardisierte Verträge beschrieben sind.

So wird MCP zum Fundament, auf dem UI (Apps SDK), Agentenszenarien (Agents SDK) und Commerce (ACP) aufsetzen. Wenn Sie sich in MCP sicher fühlen, werden alle anderen Bausteine klarer und vorhersagbarer.

Hinweis: Formal hängt ACP nicht von MCP als Spezifikation ab, aber in realen Implementierungen werden ACP‑Tools höchstwahrscheinlich vom Modell über MCP-Interfaces aufgerufen. Die beiden Ansätze passen sehr gut zusammen – lang werden wir also nicht mehr warten müssen.

9. Kleine „Kopf‑Übungen“ vor der Praxis

Bevor wir in der nächsten Vorlesung in das Format der MCP-Nachrichten eintauchen, sind ein paar gedankliche Übungen hilfreich. Sie helfen, vom „typischen REST“ auf „Protokoll + Vertrag“ umzuschalten.

Stellen Sie sich vor, nicht nur ChatGPT, sondern auch ein IDE‑Plugin für VS Code und ein interner Unternehmensassistent in Slack möchten sich an Ihre Gift‑App anbinden. Beschreiben Sie in einem Satz, was alle über Ihren Service wissen müssen. Die Antwort wird wahrscheinlich lauten: „Wir haben das Tool suggest_gifts mit folgenden Parametern und einen Geschenk‑Katalog, der über eine Ressource zugänglich ist.“ Genau das formalisert MCP.

Versuchen Sie außerdem, in zwei Sätzen zu formulieren:

• was MCP für den Product‑Teil Ihrer App ist (Tipp: standardisierte Art, Funktionalität für verschiedene Clients zu „verpacken“);
• was MCP für den Entwickler ist (Tipp: JSON‑RPC‑Protokoll mit klaren Primitiven tools/resources/prompts).

Wenn Ihnen das flüssig gelingt, sind Sie schon auf halbem Weg zum souveränen Umgang mit MCP.

Wenn man alles oben auf einen Satz verdichtet: MCP ist nicht nur eine weitere API‑Schicht, sondern der grundlegende Vertrag zwischen Ihrer Logik und LLM‑Clients. In den nächsten Vorlesungen schauen wir in das Protokoll hinein: Wir zerlegen das Format der MCP-Nachrichten, Handshake/Capabilities und lernen, den Traffic mit Inspektoren zu betrachten, damit all diese Prinzipien nicht abstrakt bleiben, sondern zu einem praktischen Werkzeug werden.

10. Typische Fehler und Irrtümer rund um MCP

Fehler Nr. 1: MCP für „noch eine API‑Schicht über meinem REST“ halten.
Mitunter ist die Versuchung groß: „Ich habe doch schon REST; ich setze einfach einen dünnen Adapter davor, der MCP-Aufrufe in REST übersetzt und umgekehrt – und gut ist.“ Formal geht das, aber oft „schleusen“ Sie damit Eigenheiten des alten APIs in MCP: seltsame Typen, unstrukturierte Antworten, fehlende explizite Schemata. Mit der Zeit wächst der Adapter, und der Gewinn durch MCP schwindet. Besser: MCP als Hauptvertrag sehen und altes REST – falls noch nötig – als interne Implementierungsdetail.

Fehler Nr. 2: glauben, MCP sei „nur für ChatGPT Apps“.
MCP ist ein offenes, allgemeines Protokoll für beliebige LLM‑Clients: ChatGPT, IDE‑Plugins, autonome Agenten. Wenn Sie Ihren MCP-Server nur für eine App planen, beschneiden Sie sich für die Zukunft. Viel sinnvoller ist es, von Beginn an zu denken: „Diesen Server können auch andere Clients verwenden“, und Tools und Ressourcen etwas universeller zu gestalten.

Fehler Nr. 3: JSON Schema ignorieren und Argumente „frei Schnauze“ beschreiben.
Auch wenn ein SDK Ihnen erlaubt, „beliebiges JSON“ zu übergeben: Beschreiben Sie die Schemata von Argumenten und Ergebnissen. Davon hängen direkt die Fähigkeit des Modells ab, Ihr Tool korrekt aufzurufen, die Qualität von Autovervollständigung und Discovery sowie der Debug‑Komfort in Inspektoren. Nicht oder schlecht beschriebene Argumente führen direkt zu mysteriösen Tool‑Call‑Fehlern.

Fehler Nr. 4: MCP als „magischen Transport“ sehen und nicht in Logs schauen.
Solange alles läuft, wirkt MCP wie etwas Unsichtbares, über das man nicht nachdenken muss. Das Problem: Sobald etwas bricht, rätseln Sie ohne Verständnis der MCP-Struktur zu lange: „Ist es das Apps SDK? Das Modell? Mein Backend?“ Die Gewohnheit, frühzeitig in MCP-Nachrichten und Logs zu schauen, spart Stunden sinnlosen Herumprobierens.

Fehler Nr. 5: versuchen, komplexe Workflows nur über REST zu modellieren und MCP-Primitive zu ignorieren.
Sobald mehrstufige Szenarien entstehen (Geschenk‑Suche → Präzisierungsfragen → Auswahl → Bestellung), ist die Versuchung groß, „einen einzigen großen REST-Endpunkt“ zu bauen. Im Kontext von ChatGPT Apps verschlechtert das oft die Steuerbarkeit: Das Modell versteht Zwischenstufen schlechter, und der MCP-Client verliert die Möglichkeit, Ressourcen und Prompts wiederzuverwenden. Besser ist, die Funktionalität in mehrere gut beschriebene tools/resources zu teilen und die Logik mit systemischen Prompts und sauberen Beschreibungen zu verbinden.