Lokales Debugging: Logs, MCP‑Inspektion und Dev Mode

1. Warum eine eigene Vorlesung zum lokalen Debugging?

In den vorherigen Modulen haben wir bereits verstanden, wie der Apps‑SDK‑Stack und MCP aufgebaut sind. Jetzt klären wir, warum es überhaupt eine eigene Vorlesung zum lokalen Debugging braucht.

Viele gehen so vor: „Na gut, ich öffne einfach ChatGPT, schreibe ‚benutze meine App‘, und dann schaue ich, was es sagt. Wenn es nicht funktioniert — schreibe ich den Code aufs Geratewohl um.“ Das ist ungefähr so, als würde man ein Backend reparieren, indem man nur auf die HTML‑Seite im Browser schaut und nie die Server‑Logs öffnet.

Mit ChatGPT Apps ist der Schritt zur Magie besonders kurz: Es gibt GPT, es entscheidet selbst, ob es ein Tool aufruft oder nicht, und hat seine eigene Fehlerlogik. Wenn Sie nicht sehen, was unter der Haube passiert, wird Debugging zum Schamanentanz.

Unser Ziel: das Ganze in einen normalen Engineering‑Prozess verwandeln:

• Sie wissen, wo Sie Next/MCP‑Logs finden;
• Sie können den MCP‑Server manuell über den Inspector ansprechen;
• Sie verstehen, was genau der Dev Mode prüft und wie Sie sicherstellen, dass ChatGPT Ihren Server überhaupt erreichen kann.

Und das Wichtigste: Sie hören auf, über das „GPT‑Ratespiel“ zu debuggen, und prüfen zuerst die unteren Ebenen des Stacks — Server und Protokoll — und erst danach UI und Modellverhalten.

2. Mentales Modell: drei Debug‑Ebenen

Damit wir nicht im Chaos versinken, einigen wir uns darauf, Debugging in drei Ebenen zu denken. Das ist unser kleiner „Schichtkuchen“:

Auf der zweiten Ebene interessiert uns, was der MCP‑Server selbst tut (Tools, DB, API), und auf der dritten — bereits die „Leitungen“ und das Format der MCP‑Nachrichten (JSON‑RPC, Schemas etc.).

Diese Dreiteilung ist die Grundlage für den Plan dieser Vorlesung und des Debug‑Kurses.

Zur Veranschaulichung ein Blick auf den Anfragefluss:

sequenceDiagram
    participant User as Benutzer
    participant ChatGPT as ChatGPT (Dev Mode)
    participant Tunnel as Tunnel (ngrok/CF)
    participant Next as Next.js + MCP

    User->>ChatGPT: "Finde ein Geschenk bis zu $50"
    ChatGPT->>Next: tools/call search_gifts (über Tunnel)
    Next->>Next: MCP-Tool aufrufen, in DB/API zugreifen
    Next-->>ChatGPT: JSON-RPC result + ToolOutput
    ChatGPT-->>User: Antwort + Widget-Render

Es kann an jeder Stelle kaputtgehen: Tunnel, Endpoint, MCP‑Logik, JSON‑Schema, React‑Widget. Ihre Aufgabe beim Debugging ist es, zu verstehen, in welcher Ebene der Fehler liegt, statt gleich alles auf Verdacht umzuschreiben.

3. Next.js‑ und MCP‑Logs: die Grundlage

Beginnen wir mit dem Langweiligsten und zugleich Nützlichsten — den Logs.

Wo die Logs in der lokalen Entwicklung leben

Im Standardtemplate des Apps SDK auf Next.js ist der MCP‑Server in der Regel in eine API‑Route verpackt (/api/mcp oder ähnlich). Sie starten npm run dev, und in einem Terminal haben Sie:

• den Next.js‑Dev‑Server;
• den Handler für den MCP‑Endpoint, der JSON‑RPC‑Requests tools/list, tools/call usw. annimmt;
• die Ausgabe des ganzen Spaßes über console.log/console.error.

Wenn Sie MCP in einen separaten Prozess ausgelagert haben, gibt es ein zweites Terminal, aber die Idee bleibt gleich: Alles Wichtige ist in der Konsole sichtbar.

Wichtig zu unterscheiden:

• Build-/Startfehler — next dev startet nicht, TypeScript stürzt ab, falscher Import usw.;
• Laufzeitfehler — alles ist gestartet, aber eine konkrete Anfrage an /api/mcp lässt ein Tool abstürzen.

Next.js zeigt im Dev‑Modus Laufzeitfehler zudem mit einem hübschen Overlay und schreibt den Stack Trace in die Konsole.

Was man im MCP‑Server loggen sollte

Auch wenn MCP JSON‑RPC nutzt, müssen Sie fürs Debugging nicht den kompletten JSON ausgeben. Deutlich hilfreicher sind strukturierte, aber kurze Logs.

Gute Praxis für MCP‑Logs ist, mindestens zu loggen: timestamp, request_id/traceId, Tool‑Name, Parameter (anonymisiert), Status (ok/error) und Ausführungszeit.

Ein einfaches logger.ts für GiftGenius kann so aussehen:

// src/lib/logger.ts
export function logToolEvent(
  phase: "start" | "end" | "error",
  data: Record<string, unknown>
) {
  const ts = new Date().toISOString();
  console.log(JSON.stringify({ ts, phase, ...data }));
}

Und im Tool‑Handler:

// src/mcp/tools/searchGifts.ts
import { logToolEvent } from "@/lib/logger";

export async function searchGiftsTool(args: { q: string }) {
  const traceId = crypto.randomUUID();

  logToolEvent("start", { tool: "search_gifts", traceId, args });

  try {
    // ... echte Geschenksuche ...
    const results = []; // Platzhalter

    logToolEvent("end", { tool: "search_gifts", traceId, count: results.length });

    return results;
  } catch (err) {
    logToolEvent("error", { tool: "search_gifts", traceId, error: String(err) });
    throw err;
  }
}

Es gibt zwei wichtige Feinheiten.

Erstens sollten Sie in Logs keine vollständigen E‑Mails, Telefonnummern, Kartennummern oder Tokens speichern. Das ist nicht nur unschön, sondern widerspricht auch grundlegenden Sicherheitspraktiken von MCP.

Zweitens ist traceId Ihr bester Freund. Wenn Sie Next.js‑ und MCP‑Logs gemeinsam betrachten, lassen sich Ereignisse leicht verknüpfen: die konkrete tools/call‑Anfrage, der entsprechende React‑Render und der Netzwerklog des Widgets.

Aus Logs erkennen, wo es gekracht hat

Sie haben ein Terminal, darin fliegen JSON‑Zeilen von logToolEvent. Typischer Ablauf:

• phase: "start" mit tool: "search_gifts" ist eingetroffen;
• phase: "end" fehlt, dafür gibt es phase: "error" und einen Stack Trace;
• daraus ist ersichtlich, dass das Tool Ihre Logik erreicht hat, aber irgendwo intern etwas kaputtging — z. B. ein Request an eine externe API, Parsing, DB‑Zugriff.

Wenn Sie für diesen Tool‑Namen überhaupt keine Logs sehen, ist die Anfrage nicht einmal beim Tool angekommen. Dann gehen Sie im Stack nach oben: Tunnel, Endpoint /mcp, JSON‑Request tools/call.

4. MCP Inspector: Debugging von MCP vor ChatGPT

Wenn Logs Ihre Augen sind, ist der MCP Inspector (oder MCPJam Inspector) das Mikroskop.

Mehr über den MCP Inspector und warum er wichtig ist

Im MCP‑Modul haben wir den Inspector bereits angebunden, um den „Hello, MCP“‑Server zu prüfen. Hier nutzen wir ihn als zentrales Debugging‑Werkzeug: Zuerst vergewissern wir uns, dass MCP für sich allein lebt, und erst dann gehen wir an Dev Mode und UI.

Der Inspector ist eine separate Anwendung (meist Web‑UI plus CLI), die als MCP‑Client fungiert. Er verbindet sich mit Ihrem Server über HTTP/SSE oder stdin/stdout, führt tools/list, tools/call aus und zeigt rohe JSON‑Nachrichten, Handshake, die Tool‑Liste, Ressourcen usw.

Die Hauptidee: ChatGPT aus der Gleichung herausnehmen. Wenn Ihr Tool nicht funktioniert, wollen Sie zuerst wissen, ob der Server lebt, Protokoll und Schema korrekt sind — bevor Sie GPT beschuldigen.

Mini‑Ablauf mit dem Inspector

Ein typisches lokales Debugging‑Szenario sieht so aus:

1. Sie starten npm run dev, damit Next.js + MCP‑Endpoint hochfahren.
2. Sie starten den MCP Inspector, zum Beispiel:

npx @modelcontextprotocol/inspector

(der konkrete Befehl hängt vom verwendeten Tool ab).

3. Im Inspector geben Sie die URL Ihres MCP‑Endpoints an, zum Beispiel http://localhost:3000/api/mcp (oder den HTTPS‑Tunnel, wenn Sie den gleich mit prüfen möchten).
4. Sie prüfen, ob der Handshake klappt: Der Server sollte seine unterstützten Capabilities, die Liste der Tools, Ressourcen usw. zurückmelden.
5. Sie rufen das interessierende Tool manuell auf: Sie wählen search_gifts, geben Argumente ein {"q": "für eine Frau bis 30"}, klicken „Call tool“ und schauen:
   • ob eine Antwort kam;
   • ob ein JSON‑RPC‑ oder MCP‑Fehler zurückkam;
   • was der Server in den Logs zu diesem Aufruf schreibt.

Wenn es im Inspector schon crasht, müssen Sie ChatGPT gar nicht öffnen: Fixen Sie den MCP‑Server.

Wenn im Inspector alles hervorragend ist, ChatGPT aber trotzdem meckert — liegt das Problem höher: Dev‑Mode‑URL, Autorisierung, Modellverhalten.

Beispiel „Tool absichtlich kaputtgemacht“

Nehmen wir unser search_gifts und machen es absichtlich kaputt:

export async function searchGiftsTool(args: { q: string }) {
  if (args.q === "kaputt") {
    throw new Error("Absichtlicher Fehler zur Debug‑Demonstration");
  }
  // ... normale Logik ...
  return [];
}

Weiter geht’s:

1. Im Inspector rufen Sie search_gifts mit dem Argument {"q": "kaputt"} auf.
2. In den Logs sehen Sie phase: "error" und den Stack Trace.
3. Sie vergewissern sich, dass der MCP‑Server den Fehler ehrlich zurückgibt.

Später, wenn Sie das im ChatGPT Dev Mode verbinden und das Modell bitten „Finde ein Geschenk mit dem Wort ‚kaputt‘“, versucht es, das Tool aufzurufen, und zeigt dem Nutzer eine Meldung wie „I encountered an error running the tool“. Klar erkennbar: Der Fehler entsteht nicht durch das Modell, sondern durch Ihre absichtliche Exception.

Diese Technik schult das Denken: Sie trennen klar die Business‑Fehler (wir werfen selbst eine Error) von den Protokollfehlern (JSON kaputt, falscher Tool‑Name usw.).

5. Widget‑Debugging: DevTools, State und „Debug‑Banner“

Wenn der MCP‑Server halbwegs verstanden ist, geht es ins Frontend — das Widget des Apps SDK.

Wo und wie man Widget‑Fehler sieht

Ihr Widget wird in ChatGPT in einer iframe‑Sandbox gerendert. Die gute Nachricht: Dieser iframe hat dieselben Browser‑DevTools.

Mini‑Prozedur:

1. Öffnen Sie ChatGPT im Browser (Chrome/Edge/Firefox).
2. Öffnen Sie die DevTools (typisch F12 oder Ctrl+Shift+I).
3. Im Reiter Console wählen Sie den Frame‑Kontext, in dem Ihr Widget lebt (oft die Domain web-sandbox.oaiusercontent.com).
4. Aktualisieren Sie den Chat/senden Sie eine Nachricht, damit GPT Ihre App anzeigt.

Wenn das Widget:

• gar nicht erscheint;
• grau/leer ist;
• eine rote Fehlermeldung in der Konsole zeigt

— ist das fast sicher ein Problem im React‑Code: nicht vorhandene Property, falscher Import, kaputter Hook usw.

Auch der Reiter Network ist nützlich. Dort sehen Sie:

• das Laden des JS‑Bundles Ihrer App (bei 404/500 — Problem auf Seite des Dev‑Servers/Tunnels);
• Requests, die Ihr Widget nach außen via window.fetch macht, und die Antworten 4xx/5xx.

Einfacher Debug‑Banner

Sehr praktisch ist es, dem Root‑Component des Widgets einen kleinen „Debug‑Banner“ hinzuzufügen, der im Dev Mode anzeigt, welches Environment und welche Build‑Version läuft.

Zum Beispiel:

// src/components/DebugBanner.tsx
export function DebugBanner() {
  if (process.env.NODE_ENV !== "development") return null;

  return (
    <div style={{ padding: 4, background: "#222", color: "#0f0", fontSize: 10 }}>
      ENV: dev | build: local | {new Date().toLocaleTimeString()}
    </div>
  );
}

Und im Root‑Component des Widgets:

// src/app/widget/page.tsx
import { DebugBanner } from "@/components/DebugBanner";

export default function GiftGeniusWidget() {
  return (
    <div>
      <DebugBanner />
      {/* restliches UI für die Geschenk-Suche */}
    </div>
  );
}

Wenn Sie ChatGPT geöffnet, die App gestartet haben, den Banner aber nicht sehen — dann ist Ihr JS gar nicht im Browser angekommen: Entweder ein Build‑Fehler, ein Endpoint‑Problem, oder das Widget ist schlicht nicht im MCP‑Server registriert.

Lokaler State und Fehlerbehandlung

Ihr Widget sollte bereits verschiedene Zustände anzeigen können: Laden, Erfolg, Fehler. Falls nicht — höchste Zeit, das hinzuzufügen.

Mini‑Pattern:

const [status, setStatus] = useState<"idle"|"loading"|"error"|"success">("idle");

async function handleSearch(query: string) {
  try {
    setStatus("loading");
    // MCP-Tool über window.openai.callTool oder einen Apps-SDK-Hook aufrufen
    setStatus("success");
  } catch (e) {
    console.error("Search failed", e);
    setStatus("error");
  }
}

Im JSX:

{status === "error" && (
  <div style={{ color: "red" }}>Etwas ist schiefgelaufen, bitte versuchen Sie es erneut.</div>
)}

Fürs Debugging ist entscheidend, dass:

• Sie Exceptions nicht schlucken (sonst ist die Konsole leer und das UI „friert“ nur ein);
• Sie den Fehler im UI explizit anzeigen, sonst wirkt es auf den Nutzer, als wäre die App abgestürzt.

6. Dev Mode als Teil des Debuggings: was er tut und wie man ihn nicht zu Unrecht beschuldigt

Jetzt nehmen wir ChatGPT Dev Mode in die Betrachtung auf. Bisher ging es nur um Ihren Code. Manchmal funktioniert lokal alles, im Inspector ist alles top, aber ChatGPT antwortet trotzdem „Error talking to [AppName]“ oder bietet Ihre App gar nicht erst an.

Was der Dev Mode macht

Dev Mode ist ein Modus in ChatGPT, in dem Sie:

• eigene Apps erstellen und bearbeiten können;
• den Endpoint Ihres MCP‑Servers angeben (oft https://ihre-domain/mcp oder /api/mcp);
• Manifest und Metadaten schnell aktualisieren können, ohne im Store zu veröffentlichen.

Aus Debug‑Sicht ist der Dev Mode lediglich eine weitere Konfigurationsebene:

• wenn dort eine falsche URL steht;
• wenn Sie das /mcp am Ende vergessen haben;
• wenn der Tunnel eine neue Domain vergeben hat und Sie die Einstellungen nicht aktualisiert haben

— kann ChatGPT Ihren Server schlicht nicht erreichen.

Typisches Dev‑Mode‑Fehlerszenario

Klassiker:

1. Sie haben den Tunnel https://abcd.ngrok.io gestartet, ihn im Dev Mode angegeben, alles lief.
2. Am nächsten Tag starten Sie ngrok neu und erhalten https://efgh.ngrok.io.
3. Im Dev Mode steht weiterhin https://abcd.ngrok.io/mcp.
4. ChatGPT schreibt „Error talking to GiftGenius“.

Der MCP Inspector, auf http://localhost:3000/api/mcp gerichtet, zeigt gleichzeitig, dass alles okay ist. Das bedeutet: MCP lebt, aber ChatGPT schaut an die falsche Adresse.

Lösung: In die Dev‑Mode‑Einstellungen gehen, die URL aktualisieren und dabei das /mcp am Ende nicht vergessen.

Dev Mode vs. Store

In dieser Vorlesung sprechen wir nur über den Dev Mode — Ihre Sandbox. Hier ist es normal, die URL häufig zu wechseln, den Tunnel neu zu verbinden und das Toolschema zu ändern.

Wenn Sie später in den Store gehen, wird der Endpoint deutlich fester verdrahtet sein, und solche Manöver sind dann keine gute Idee mehr. Bis zum Store sind es aber noch einige Module — daher dürfen wir in Dev Mode erst einmal in Ruhe kaputtmachen und reparieren.

7. Mini‑Algorithmus fürs Debugging: Was tun, wenn „nichts funktioniert“

Jetzt bringen wir alles in einen praktischen Algorithmus. Im Grunde sind es dieselben drei Debug‑Ebenen vom Anfang, nur als Schrittfolge aufgeschrieben.

Angenommen, Sie öffnen ChatGPT, wählen GiftGenius, bitten: „Finde ein Geschenk bis zu 30$ für einen Nerd‑Freund“, und:

• GPT schreibt nichts über die App;
• oder schreibt „Error talking to GiftGenius“;
• oder das Widget öffnet sich leer/grau.

Wie nicht verzweifeln?

Schritt 1 (Ebene MCP/Server). MCP über Inspector und Logs prüfen

Zuerst ignorieren wir GPT und das UI. Uns interessiert nur der Server.

1. Stellen Sie sicher, dass npm run dev läuft und der Endpoint (/api/mcp) antwortet.
2. Verbinden Sie den MCP Inspector mit http://localhost:3000/api/mcp oder mit Ihrem Tunnel.
3. Prüfen Sie den Handshake — die Tool‑Liste sollte angezeigt werden.
4. Rufen Sie manuell dasselbe Tool auf, das GPT eigentlich aufrufen sollte (z. B. search_gifts) — mit ähnlichen Argumenten.

Wenn es hier bereits crasht — fixen Sie MCP: Schemas, Business‑Logik, Netzwerkanfragen. Nutzen Sie Logs und traceId, um zu verstehen, was genau bricht.

Schritt 2 (Ebene Protokoll/Dev Mode). Dev Mode und URL prüfen

Wenn im Inspector alles prima ist, ChatGPT Ihre App aber weiterhin nicht sieht oder Verbindungsprobleme meldet:

1. Öffnen Sie die Dev‑Mode‑Einstellungen Ihrer App.
2. Schauen Sie, welche URL dort für MCP eingetragen ist.
3. Vergleichen Sie sie mit dem, was Ihr Server/Tunnel tatsächlich bedient (und prüfen Sie, ob am Ende /mcp steht, falls Ihr Server das erwartet).

Häufig liegt das Problem genau hier.

Schritt 3 (Ebene UI). Widget über DevTools prüfen

Wenn ChatGPT die Tools erfolgreich aufruft (sichtbar in den MCP‑Logs), sich das Widget aber merkwürdig verhält:

1. Öffnen Sie die DevTools im Browser auf der ChatGPT‑Seite.
2. Im Reiter Console wählen Sie den iframe‑Kontext Ihres Widgets.
3. Schauen Sie auf JS‑Fehler.
4. Im Reiter Network vergewissern Sie sich:
   • Das JS‑Bundle des Widgets lädt ohne 404/500;
   • zusätzliche Requests (via fetch/window.openai.fetch) sinnvolle Antworten zurückgeben.

Parallel werfen Sie einen Blick auf Ihren DebugBanner: Wenn er nicht erscheint, ist das React‑Baum überhaupt nicht erreicht worden.

Schritt 4. Dev Mode nutzen, um Bugreports zu reproduzieren

Wenn Sie von Kolleginnen/Kollegen oder Nutzern einen Bugreport erhalten, versuchen Sie, den genauen Prompt zu sichern, bei dem es kaputtging. Im Dev Mode lässt sich das Szenario schnell reproduzieren:

1. npm run dev starten, Tunnel hochfahren.
2. Im Dev Mode die App auswählen.
3. Den problematischen Prompt einfügen.
4. Parallel:
   • in den Logs schauen, welche JSON‑Requests beim MCP ankommen;
   • im Inspector bei Bedarf denselben tools/call mit identischen Argumenten wiederholen.

So wird aus „manchmal geht etwas nicht“ ein reproduzierbares Szenario.

8. Kleine Code‑Akzente für bequemes Debugging

Zum Abschluss fügen wir unserer GiftGenius‑App noch ein paar nützliche Bausteine hinzu.

Umgebungskonfiguration und Log‑Level

Praktisch ist es, in der Serverkonfiguration den MCP‑Endpoint und das Log‑Level explizit festzuhalten:

// src/config.ts
export const config = {
  mcpEndpoint:
    process.env.NODE_ENV === "development"
      ? "http://localhost:3000/api/mcp" // der Tunnel deckt das ab
      : "https://api.giftgenius.com/api/mcp",
  logLevel: process.env.NODE_ENV === "development" ? "DEBUG" : "ERROR",
};

Und in logToolEvent können Sie logLevel berücksichtigen, um in Prod nicht zu spammen.

Strukturiertes Logging von MCP‑Fehlern

Fangen Sie bei der Tool‑Verarbeitung erwartete Fehler ab und geben Sie verständliche Meldungen zurück, anstatt alles mit throw abzuschießen:

export async function searchGiftsTool(args: { q: string }) {
  const traceId = crypto.randomUUID();
  logToolEvent("start", { tool: "search_gifts", traceId, args });

  try {
    // ... normaler Code ...
    return { content: [{ type: "text", text: "3 Geschenke gefunden" }] };
  } catch (err) {
    logToolEvent("error", { tool: "search_gifts", traceId, error: String(err) });

    return {
      content: [{ type: "text", text: "Fehler bei der Geschenksuche. Bitte versuchen Sie es später erneut." }],
      isError: true,
    };
  }
}

So sieht ChatGPT, dass das Ergebnis mit isError markiert ist, kann das Problem korrekt benennen, und Sie sehen in den Logs, was passiert ist.

9. Typische Fehler beim lokalen Debugging der ChatGPT App

Fehler Nr. 1: „über GPT“ debuggen statt über Server und Inspector.
Es ist verlockend, nur zu schauen, was das Modell antwortet, und zu raten, wo der Bug liegt. Aber das Modell ist die oberste Schicht. Wenn der MCP‑Server für sich (manuell, über den Inspector) nicht funktioniert — braucht man von GPT keine Wunder erwarten. Sorgen Sie erst für eine stabile MCP‑Funktion, dann binden Sie ChatGPT an.

Fehler Nr. 2: Logs gar nicht anschauen oder alles blind loggen.
Fehlende Logs bedeuten Blindflug: Sie wissen nicht, welches Tool aufgerufen wurde, mit welchen Argumenten und wie es ausging. Overlogging verwandelt die Konsole dagegen in eine „Matrix“ unzusammenhängender Zeilen. Besser sind kompakte, strukturierte Logs mit tool, args (anonymisiert), traceId, status und Laufzeit.

Fehler Nr. 3: Sensible Daten in Logs speichern.
Tokens, vollständige E‑Mails und Kartennummern zu loggen, ist sowohl sicherheitstechnisch als auch im Sinne der OpenAI‑Policy schlechte Praxis. In die Logs gehört nur, was fürs Debugging wirklich hilft; personenbezogene Daten werden maskiert oder gar nicht erst geloggt.

Fehler Nr. 4: Dem Dev Mode alle Sünden zuschieben.
Der Dev Mode ist oft Sündenbock: „OpenAI hat da wohl was kaputtgemacht.“ In der Realität liegt es sehr oft daran, dass Sie die URL nach dem Neustart des Tunnels nicht aktualisiert haben oder den falschen Pfad angegeben haben (/ statt /mcp). Bevor Sie den Support anschreiben, schauen Sie in die Dev‑Mode‑Einstellungen und gleichen Sie den Endpoint mit der tatsächlichen Serveradresse ab.

Fehler Nr. 5: DevTools und Widget‑Fehler ignorieren.
Ein leeres oder graues Widget bedeutet fast immer einen JavaScript‑Fehler auf dem Client. Wenn Sie nur MCP‑Logs anschauen, aber die DevTools in ChatGPT nicht öffnen, sehen Sie nur die halbe Wahrheit. Die Gewohnheit, automatisch F12 zu drücken und Console/Network zu prüfen, spart Lebenszeit.

Fehler Nr. 6: Bugs mit magischen Delays „reparieren“ wollen.
Manchmal möchte man ein setTimeout oder eine Thread.sleep‑artige Verzögerung einbauen, „damit alles Zeit hat zu laden“. In der Welt von MCP/Next/React ist das fast immer die falsche Behandlung: Das Problem liegt meist im Schema, im falschen Endpoint oder im Codefehler — nicht darin, dass „der Server nicht hinterherkommt“. Finden Sie besser die konkrete Bruchstelle (Inspector → Dev Mode → Widget), statt sie mit Delays zuzuschütten.

Fehler Nr. 7: Auf Vercel deployen, ohne lokal alles geprüft zu haben.
Der Wunsch „schnell in Prod“ ist verständlich, aber einen kaputten MCP auf Vercel zu heben ist der perfekte Weg, zwei Problemebenen zu erzeugen: lokal und Produktion. In diesem Modul bestehen wir bewusst darauf: erst MCP Jam/Inspector → alles ok, Dev Mode → Basisszenarien funktionieren, und erst dann deployen.