- Der Entwicklermodus ist eine Beta-Funktion, die für alle Tools einen vollständigen MCP-Client (Lesen/Schreiben) bereitstellt und sich an Entwickler richtet, die erweiterte Connector-Konfigurationen sicher testen möchten
- Bei der Nutzung ist auf Risiken wie Prompt-Injection und bösartige MCPs sowie auf destruktive Fehler bei Schreibaktionen zu achten; wichtig ist ein Verfahren zur Prüfung und Freigabe von Payloads vor Tool-Aufrufen
- Die Aktivierung erfolgt im Web unter Settings → Connectors → Advanced → Developer mode; dort lassen sich Remote-MCP-Server hinzufügen, um Tools zu importieren und per Toggle zu verwalten
- Wenn im Gespräch Developer mode ausgewählt wird und Connectoren sowie Tools explizit angegeben werden, fällt die präzise Tool-Auswahl leichter; Prompt-Techniken wie Eingabeschema- und Reihenfolgenvorgaben sind wirksam
- Schreibaktionen erfordern standardmäßig eine Freigabe; Tools ohne Annotation readOnlyHint gelten als Schreib-Tools, daher ist ein vorsichtiger Betrieb im Sinne von Missbrauchsprävention und Datenschutz erforderlich
Überblick
- Definition: Der Developer mode von ChatGPT ist ein Beta-Modus, der als Client mit Lese-/Schreibrechten für alle verbundenen MCP-Connectoren und -Tools fungiert
- Zielgruppe: Bereitgestellt für Pro-/Plus-Nutzer, die Connectoren sicher konfigurieren und testen können
- Hinweis: Es bestehen Sicherheitsrisiken wie Prompt-Injection, Datenzerstörung durch Schreibfehler des Modells und MCPs zum Informationsdiebstahl
Aktivierung und Import von MCPs
- Aktivierungspfad: Aktivierung unter Settings → Connectors → Advanced → Developer mode
- MCP-Server hinzufügen: Wenn im Connectors-Tab der Settings ein Remote-MCP-Server registriert wird, erscheint er in der Tool-Auswahl des Developer mode im Gespräch
- Protokoll: Unterstützung für SSE und Streaming HTTP
- Authentifizierung: Unterstützung für OAuth oder keine Authentifizierung
- Tool-Synchronisierung: In der Connector-Detailansicht lassen sich Tools per On/Off-Toggle verwalten; mit Refresh wird die neueste Liste samt Beschreibungen geladen
Richtlinien zur Tool-Nutzung im Gespräch
- Expliziter Aufruf: Connector- und Tool-Namen konkret angeben, etwa „Verwende update_record des Acme-CRM-Connectors, um …“
- Alternativen verbieten: Zur Vermeidung von Verwechslungen Verbote explizit formulieren, etwa „Kein integriertes Browsing, nur Acme CRM verwenden“
- Ähnliche Tools unterscheiden: Prioritätsregeln vergeben, etwa „Für Meetings Calendar.create_event bevorzugen, Reminders.create_task nicht verwenden“
- Eingabeschema und Reihenfolge fixieren: Sequentielle Aufrufe und Payload-Form konkretisieren, etwa „Zuerst Repo.read_file { path }, danach Repo.write_file …“
- Präferenz für verschachtelte Connectoren: Richtlinien zur Datenherkunft festlegen, etwa „Für Berechtigungsdaten CompanyDB bevorzugen, nur bei Fehlschlag die Sekundärquelle“
- Modellanleitung verbessern: Wenn der MCP-Server verhaltensorientierte Tool-Beschreibungen und Parameterkommentare mit „Use this when …“ bereitstellt, steigt die Genauigkeit der Tool-Auswahl
Beispiel-Prompts
- Termin erstellen: „Erstelle morgen um 3pm PT ein 30-minütiges Meeting mit Calendar.create_event, keine anderen Scheduling-Tools verwenden“
- PR erstellen: „Mit GitHub.open_pull_request feat-retry → main, Titel und Text angeben, direktes Pushen auf main verboten“
Prüf- und Freigabefluss
- Tool-Aufrufe prüfen: Die JSON-Ein- und Ausgaben jedes Aufrufs aufklappen, um Payloads zu validieren und Debugging durchzuführen
- Standardmäßig Freigabe für Schreibaktionen erforderlich: Da Fehleingaben zu Datenzerstörung oder -abfluss führen können, ist eine erneute Prüfung vor dem Senden nötig
- Erkennung von Nur-Lese-Tools: Nur Tools mit der Annotation readOnlyHint werden als Lese-Tools behandelt; Tools ohne Annotation gelten als Schreib-Tools
- Option zum Merken von Freigaben: Während eines Gesprächs kann die Freigabe oder Ablehnung für bestimmte Tools gemerkt werden, sollte aber nur für vertrauenswürdige Anwendungen erlaubt werden
- Sitzungsumfang: Bei einem neuen Gespräch oder beim Neuladen der Seite wird das Merken von Freigaben zurückgesetzt
Risikomodell und Sicherheitsregeln
- Schutz vor Prompt-Injection: MCP-Ergebnisse und -Inhalte nicht blind vertrauen, sondern prüfen; die Offenlegung von Secrets und Tokens verhindern
- Minimale Rechte: Schreib-Tools nur mit minimalen Rechten bereitstellen und Hochrisiko-Aktionen auf explizite Freigabe setzen
- Connector-Hygiene: Tool-Beschreibungen, Schemata und Fehlerfälle klar dokumentieren, um Fehlgebrauch und die falsche Auswahl integrierter Tools zu verringern
Betriebliche Tipps
- Leitfaden zur Tool-Auswahl: In die Beschreibung aufnehmen, wann dieses Tool verwendet werden sollte, sowie Verbote und Edge Cases, damit die Auswahlheuristik des Modells klarer wird
- Sequenzdesign: Den Zyklus Lesen → Validieren → Schreiben im Prompt fest verankern, um sichere Zustandsübergänge zu gewährleisten
- Überwachungsmetriken: Fehlerrate, Rollback-Anteil, Versuche zur Umgehung von Freigaben usw. protokollieren, um Betriebsrisiken zu beobachten
Zusammenfassung
- Der Developer mode ist eine leistungsstarke Beta-Funktion, mit der sich alle MCP-Tools lesend und schreibend aufrufen lassen
- Für Sicherheit und Betriebssicherheit sind explizite Anweisungen, Freigabeprozesse, minimale Rechte und bessere Tool-Beschreibungen unverzichtbar
- Mit passender Prompt-Disziplin und einem Prüfablauf werden End-to-End-Arbeitsautomatisierung und eine präzise Connector-Orchestrierung möglich
Noch keine Kommentare.