Passende Zugangsdaten wählen
Die bisherigen API-Schlüssel-Werkzeuge bleiben
list_models, get_balance, chat_completion, generate_image, generate_video, get_task. Gleichnamige persönliche Werkzeuge können andere Eingaben haben. Nach dem Verbinden immer tools/list lesen.
Token erstellen und verbinden
- Unter Dashboard → Agent Personal MCP öffnen.
- Einen Namen, die benötigten Rechte und 1–365 Tage Gültigkeit wählen; Standard sind 30 Tage.
- Für
models:invokeoderutilities:invokeeinen eigenen aktiven API-Schlüssel binden. Modellbeschränkungen, Budget und RPM bleiben wirksam. Kontodaten lassen sich ohne positives Guthaben lesen. - Den bei Erstellung angezeigten
mcp_user_-Token in den Geheimnis-Einstellungen des Clients speichern. Nicht in Quelltext, Chats oder Logs einfügen. Bei Bedarf im selben Dashboard widerrufen.
Authorization-Header unterstützen. Die Protokollversion wird ausgehandelt. OAuth ist nicht implementiert; reine OAuth-Clients können diese Verbindung nicht nutzen. Die Tabelle enthält Verbindungsdaten, keine clientspezifische Konfigurationsdatei.
Werkzeuge vor dem Aufruf prüfen
Nach der Initialisierungget_capabilities mit {} aufrufen und tools/list lesen. Die Antwort enthält audience: user, ownership: self, erlaubte scopes, Werkzeuge und oauth: false. Alle anderen persönlichen Werkzeuge verlangen ein input-Objekt, auch ohne fachliche Parameter.
Berechtigungen
Rechte werden auf der Website ausgewählt. MCP kann keine Berechtigungen ausstellen, eigene Rechte erweitern oder API-Schlüssel zu Administrator-Zugangsdaten machen. Auch bei direkten Aufrufen werden Eigentum und Rechte geprüft.usage:content verlangt zusätzlich eine ausdrückliche Inhaltsabfrage und aktivierte Inhaltsaufzeichnung am Schlüssel.
Schreiben, Ergebnisse und sichere Wiederholung
Jeder Schreibvorgang benötigt einen eigenen, vorher gespeichertenidempotencyKey: 1–191 druckbare ASCII-Zeichen ohne Leerzeichen. Bei verlorener Antwort dasselbe Werkzeug mit derselben Eingabe und demselben Schlüssel wiederholen. Andere Eingaben ergeben idempotency_conflict. Jeder Upload-Schritt braucht einen eigenen Schlüssel.
structuredContent und als JSON-Text in content. Der erste Aufruf liefert die folgende Hülle. Eine Wiederholung liefert replayed: true und einen kleinen receipt mit verfügbaren Kennungen, nicht das volle Originalergebnis oder einen Schlüssel-Geheimwert.
execution_pending (409) bedeutet, dass der erste Aufruf ungeklärt ist. execution_unknown (409) oder status: unknown bedeutet, dass die Wirkung bereits eingetreten sein kann. Erst get_execution, danach Aufgabe, Bestellung oder Kontoaktion prüfen. Diese Zustände niemals mit einem neuen Schlüssel umgehen. Eine abgeschlossene MCP-Ausführung kann noch eine offene Modellaufgabe oder Website-Bestätigung enthalten.
Modelle und Hilfsprogramme verwenden
Mitlist_models → get_model_schema eine öffentliche Modell-ID wählen. body enthält den vollständigen unterstützten HTTP-JSON-Request. Die ID steht in body.model; generate_content verlangt stattdessen das äußere model. Dateifelder sind nur bei edit_image (image, image[], mask) erlaubt. Andere Medieneingaben verwenden veröffentlichte URLs.
task_id speichern und get_task abfragen. Mit stream: true werden Ereignisse im abschließenden MCP-Ergebnis gesammelt; für Live-Streaming im SDK die HTTP-API verwenden. Die optionale UUID v4 client_request_id dient der Zuordnung von Videoanfragen und ist unabhängig von idempotencyKey. Modellaufrufe können Credits verbrauchen.
Die Erfassung von Modellergebnissen ist auf 8 MiB und 300 Sekunden begrenzt. Bei Abbruch oder Überschreitung bleibt eine bekannte request_id im Ausführungsbeleg erhalten. Erst get_execution und die bestehende Anfrage oder Aufgabe prüfen; keinen weiteren kostenpflichtigen Request und keinen neuen Idempotenzschlüssel für einen ungeklärten Aufruf erzeugen. Eine Client-Trennung bedeutet nicht, dass eine angenommene Modellaufgabe abgebrochen wurde.
Die 32 Hilfsprogramme über list_utilities → get_utility_schema → run_utility nutzen. Bestehende Voraussetzungen und Kontingente gelten weiter; einige Stapelaktionen erfordern ein qualifiziertes zahlendes Konto. Werte gehören in parameters, eigene Datei-IDs in files. Binäre oder große Ausgaben werden temporäre Dateien. Dateieingaben und Nicht-JSON-Ausgaben benötigen auch files:write.
Dateien hochladen und abrufen
begin_uploadmit Dateiname, MIME-Typ und exakter Bytezahl aufrufen, höchstens 250 MiB.upload_chunkmit nullbasiertemindexund Base64-dataaufrufen. Dekodierte Teile sind höchstens 1 MiB groß; die Indizes müssen bei null beginnen und lückenlos sein.finish_uploadmitfile_idund optional kleingeschriebenem SHA-256 aufrufen. Erst beistatus: readyverwenden.- Die ID an ein geeignetes Werkzeug übergeben.
get_artifactliefert Metadaten oder mitoffsetBase64-Bytes.next_offsetbisnullfolgen. Der Downloadlink verlangt die Website-Anmeldung des Eigentümers.
upload_image und upload_media veröffentlichen Dateien separat. Die erzeugten URLs sind teilbar; nur dafür vorgesehene Dateien veröffentlichen.
Vor dem Lesen von Dateiinhalten werden Eigentum, Bereitschaft, Anzahl und Größe geprüft. Jede Dateireferenz zählt für die Grenzen der Operation, auch wiederholte IDs.
upload_media: höchstens 20 Dateien / 250 MiB insgesamt.upload_image: eine Datei mit höchstens 50 MiB.edit_image: höchstens 20 Dateien über alle Felder, davon höchstens einemask; 50 MiB pro Datei / 100 MiB insgesamt. Die Array-Grenzen je Feld aus dem Eingabeschema gelten weiterhin.run_utility: Datei-, Einzelgrößen- und Gesamtlimits ausget_utility_schemagelten. Die feste Obergrenze beträgt 250 MiB insgesamt, auch wenn der Katalog mehr zulässt.
Website-Bestätigung und Zahlungen
- API-Geheimwert:
start_reveal_key_action→ Nutzer bestätigtconfirmation_url→reveal_api_keymit Aktions-idalsaction_id. Die Freigabe gilt für diesen Schlüssel und diese Zugangsdaten, läuft 15 Minuten nach Aktionserstellung ab und ist einmal nutzbar.create_api_keyliefert nur Metadaten. - Abo kündigen:
cancel_subscriptionstartet die Bestätigung. Der Nutzer führt sie auf der Website aus. Vor einer Erfolgsmeldungget_account_actionund Abostatus prüfen. - Passwort/Kontolöschung:
start_account_actionmitpassword_changeoderdelete_account. Codes und Passwörter gibt der Nutzer auf der Website ein, niemals beim Assistenten. Löschung widerruft den Zugriff und meldet ab; danach MCP nicht weiter abfragen. - Zahlung:
list_billing_products→create_checkout→ Nutzer bezahlt →get_payment_status. Ein Link beweist keine Zahlung. - Echte Nachrichten:
resend_invoiceundtest_credit_alertsenden E-Mail oder Webhook. Nur auf ausdrücklichen Wunsch ausführen.
Fehler ohne doppelte Arbeit behandeln
Verbindungs-/Authentifizierungsfehler können HTTP-Fehler sein. Werkzeugfehler setzenisError: true; structuredContent.error.code, status, execution_id und receipt prüfen. Wiederholungen können einen nicht abgeschlossenen Ausführungs-status enthalten.
Nützliche erste Leseabfragen
- Ausgaben prüfen:
get_balance→summarize_usage→ einzelne Anfragen mitlist_usage. - Fehler erklären:
diagnose_requestmittask_id; vor erneutem Modellaufruf Fehler und Erstattung prüfen. - Integration vorbereiten:
list_models→get_model_schema→get_api_guide, ohne Modellaufruf. - Kontosicherheit prüfen:
list_api_keys→get_api_key→list_login_records.
from einschließlich und to ausschließlich. Standard: letzte 30 Tage, maximal 366. Nur aufbewahrte Datensätze; fehlende Tage beweisen keine Nullnutzung. get_overview.timezoneOffset nutzt JavaScript-getTimezoneOffset in Minuten (UTC minus Ortszeit), Standard 0. Listen und Gruppierungen bleiben UTC.
In summarize_usage sind creditsCharged und netCreditsCharged die aufbewahrte Nettobelastung. linkedRefundCredits umfasst nur bekannte Erstattungen verknüpfter asynchroner Aufgaben. knownGrossCredits addiert diese zur Nettobelastung und ist keine vollständige Bruttoausgabe. totalTokens, averageLatencyMs, pending, processing beziehen sich auf passende aufbewahrte Anfragen.
Weiter mit vollständiger Werkzeugreferenz, Authentifizierung und HTTP-API-Fehlern.