MCP-Integration
Anyy verbindet lokale stdio-Befehle und entfernte HTTP-MCP-Server anhand eines Profils und seiner Projektkonfiguration. Jeder Server hat eigene Aktivierungs-, Verbindungs- und Werkzeugbereitstellungseinstellungen. Hinzufügen speichert standardmäßig eine aktivierte, erst bei Bedarf verbundene Konfiguration; es prüft nicht und fordert keine Werkzeuglistenauswahl. Mit --disable speichern Sie deaktiviert.
Verbindungsvoraussetzungen
Unterstützte Client-Transporte sind stdio und Streamable HTTP (http). Ein separater sse-Transport wird abgelehnt; HTTP kann innerhalb von Streamable HTTP weiterhin Ereignisströme übertragen. Remote-Endpunkte müssen außer bei Loopback-HTTP-URLs HTTPS verwenden.
Installieren Sie für stdio die Serverprogrammdatei und ihre Abhängigkeiten auf dem Anyy-Rechner. Ein npx-Befehl benötigt dort Node.js/npm; Anyy liefert diese Laufzeiten nicht mit und installiert den Server nicht für Sie. Nur eine begrenzte Prozessumgebung einschließlich PATH und HOME wird geerbt; setzen Sie weitere erforderliche Werte ausdrücklich mit Server-env. HTTP-Server benötigen keine lokale Node.js-Laufzeit.
Profil- und Projektkonfiguration
Globale Serverdefinitionen liegen in config.yaml des Profils unter mcp.client.servers. Die Projektdatei ist .anyy/mcp.json im kanonischen Workspace dieses Profils (derzeit <ProfileHome>/workspace/.anyy/mcp.json). Ein Gesprächswechsel oder anderes Sitzungsarbeitsverzeichnis wählt keine andere Projektdatei.
Die Projektdatei verwendet ein Objekt mcpServers:
{
"mcpServers": {
"context": {"enabled": false, "exposure": "deferred"},
"project-docs": {"url": "https://mcp.example.com", "exposure": "codemode"}
}
}
Eine vollständige Projektdefinition ersetzt die gleichnamige Profildefinition. Ein Eintrag ohne command, url oder type ist eine Teilüberschreibung: Er benötigt einen gleichnamigen Profilserver und darf nur enabled, exposure und toolExposure enthalten. Jeder angegebene Wert ersetzt seinen geerbten Wert; toolExposure ersetzt das gesamte geordnete Regelobjekt. Andere Felder einschließlich Authentifizierung stammen weiterhin aus der Profildefinition. Eine vollständige Projektdefinition darf keine Anbieterreferenz auth setzen.
Prüfen Sie mit anyy mcp show SERVER_ID die ausgewählte Konfigurationsquelle und etwaige Projektüberschreibungen. Fehlerhafte Projektkonfiguration erscheint in Konfigurationsdiagnosen, statt stillschweigend zu einer anderen Serverdefinition zu werden.
Eine Projektdefinition hinzufügen oder entfernen
anyy mcp add project-docs --local --url https://mcp.example.com
anyy mcp remove project-docs --local
--local (oder -l) schreibt nur die Projektdatei dieses Profils. Hinzufügen ersetzt den gleichnamigen Projekteintrag ohne --force; Entfernen löscht nur diesen Eintrag, bewahrt Profildefinitionen und gespeicherte Autorisierungen und meldet einen Fehler, wenn der Projekteintrag fehlt. Diese Dateiänderungen verbinden laufende Server nicht neu. Start oder session.reload im Leerlauf lädt die neue Definition; nach Entfernen einer gleichnamigen Überschreibung wird die Profildefinition wieder sichtbar. Ohne --local behalten Hinzufügen/Entfernen das gewöhnliche Profilverhalten.
Werte und Pfade
Gewöhnliches Hinzufügen/Konfigurieren/Setzen und Dashboard-Speichern bewahrt die eingegebene Zeichenfolge, auch bei vertraulich wirkenden Umgebungs-/Headernamen oder einem OAuth-Clientgeheimnis. Daraus wird nicht automatisch eine Geheimnisreferenz. Verwenden Sie ausdrücklich secret:, um ein vorhandenes durch Anyy verwaltetes Geheimnis zu nutzen; gewöhnliche Zeichenfolgen behalten das folgende Ausdrucksverhalten.
Nur stdio-Umgebungswerte, HTTP-Headerwerte und OAuth-clientSecret verwenden Wertausdrücke. $VAR und ${VAR} lesen die Anyy-Prozessumgebung; $$ erzeugt ein wörtliches $, $! ein wörtliches !. Ein mit ! beginnender Wert führt einen lokalen Shell-Befehl aus und verwendet dessen getrimmte Ausgabe. Dies wird einmal ausgewertet: Ein expandierter Wert wird nicht erneut ausgewertet. Befehle laufen im Prozessarbeitsverzeichnis von Anyy mit 10 Sekunden und 1 MiB Ausgabelimit.
In Profildefinitionen verwenden Werte mit den exakten Präfixen env:, secret: oder file: zuerst den vorhandenen Zugangsdaten-Resolver von Anyy; sein Ergebnis ist endgültig. In vollständigen Projektdefinitionen sind diese Präfixe wörtlicher Text. Teilüberschreibungen erben die Wertinterpretation der Profildefinition. URLs und andere OAuth-Felder wie clientId, scope und callbackUrl verwenden diese Ausdrücke nicht.
Befehls- und Argumentpfade expandieren ein führendes ~; cwd unterstützt auch Home-relative oder Workspace-relative Pfade. $- oder !-Ausdrücke werden nicht ausgeführt. Das stdio-Arbeitsverzeichnis ist sowohl vom bekanntgegebenen Workspace-Stamm als auch vom für !command verwendeten Prozessverzeichnis getrennt.
Einen lokalen Server hinzufügen
anyy mcp add context \
--transport stdio \
--command npx \
--exposure codemode \
--args -y @upstash/context7-mcp
Setzen Sie Anyy-Optionen vor --args oder --; übrige Argumente gehen an den Server. Optionales --cwd DIR gilt für stdio-Server und akzeptiert dieselben absoluten, Workspace-relativen oder mit Home-Präfix beginnenden Pfade wie gespeichertes cwd; der eingegebene Pfad wird nicht getrimmt. Wiederholen Sie --env KEY=VALUE nach Bedarf und verwenden Sie Geheimnisreferenzen für vertrauliche Werte. Ein lokaler Server läuft mit dem Betriebssystemzugriff von Anyy.
Einen Remote-Server hinzufügen
anyy mcp add remote-docs --url https://mcp.example.com
anyy mcp add provider-docs --url https://mcp.example.com --auth '{"provider":"provider-id"}'
anyy mcp add header-docs --url https://mcp.example.com --header Authorization=secret:mcp/header-docs/token
HTTP unterstützt automatisches OAuth, wenn weder Anbieterreferenz noch Authorization-Header konfiguriert ist. Ein anonymer Server kann ohne Anmeldung verbinden; anfänglich fehlende Token bedeuten allein keine nötige erneute Authentifizierung. auth ist ein Anbieter-JSON-Objekt; oauth ist ein separates typisiertes Optionsobjekt. Übergeben Sie etwa --oauth '{"clientId":"registered-client"}' für eine vorhandene Registrierung. Die alten Zeichenfolgenselektoren oauth, header und none werden abgelehnt.
Speichern Sie den Server vor dem Anmeldestart:
anyy mcp login remote-docs
Lehnt der Server gespeicherte OAuth-Clientzugangsdaten ab, kann Anyy den abgelehnten lokalen Autorisierungszustand löschen und einmal wiederherstellen; es kann eine erneute Anmeldung verlangen. Dies wiederholt keinen Werkzeugaufruf. Ein fehlender Code-Austausch-Verifier beendet diesen Anmeldeversuch.
Browser-Callback und manuelle Weiterleitung
Führen Sie anyy mcp login remote-docs --timeout 300 aus oder wählen Sie Anmelden beim gespeicherten Server im Dashboard oder Werkzeuge und MCP in der TUI-Einrichtung. Autorisieren Sie im Browser. Kann er den Anyy-Rechner nicht erreichen, fügen Sie die vollständige Weiterleitungs-URL aus seiner Adressleiste in die Eingabe dieser Anmeldung ein. Halten Sie diese URL vertraulich.
Das CLI-Zeitlimit beträgt standardmäßig 300 Sekunden und umfasst nur Autorisierung, nicht Verbindungstests oder Neuverbinden danach. Zuerst wird die Verbindung geprüft: Ist sie schon bereit, erscheint Bereits angemeldet; ein gewöhnlicher Verbindungsfehler startet keine Anmeldung. Explizite CLI-Anmeldung kann einen gespeicherten deaktivierten Server authentifizieren, ohne seine Werkzeuge zu aktivieren. In einem nicht interaktiven Terminal wartet die CLI nur auf den Browser-Callback und liest keine eingefügte URL.
Die TUI verwendet Ctrl+Y zum Kopieren des vollständigen Autorisierungslinks und Esc zum Abbrechen. Das Schließen der Dashboard-Anmeldung oder Verlassen der Seite bricht die ausstehende Anmeldung ab. Abschluss leert temporären Link und Eingabe.
Benötigt ein Werkzeugaufruf eine interaktive OAuth-Autorisierung oder zusätzliche Berechtigungen, meldet die Verbindung erforderliche Anmeldung. Starten Sie diese ausdrücklich über CLI, Dashboard oder TUI. Der fehlgeschlagene Aufruf wird nicht automatisch aktualisiert oder wiederholt. Anmeldeabbruch beendet den Versuch mit dem eigenen Anmeldeabbruchergebnis; Autorisierung läuft nicht im Hintergrund weiter.
Anmeldung aus einem anderen Prozess
Speichert ein anderer Anmeldeprozess Zugangsdaten für dasselbe Profil/denselben Server, prüft eine auf Authentifizierung wartende Verbindung sie beim Start eines Modellschritts. Eine für diesen Schritt bereits vorbereitete Anfrage behält ihre ursprünglichen Werkzeugdeklarationen; neu entdeckte Werkzeuge erscheinen bei Vorbereitung einer späteren Anfrage. Anyy fragt Zugangsdaten nicht im Hintergrund ab. Manuell geänderte Konfiguration erfordert weiterhin Start oder Ressourcen- Neuladen einer untätigen Sitzung; geänderte Zugangsdaten starten keine gewöhnlich fehlgeschlagene oder geschlossene Verbindung über diesen Erkennungsweg neu.
Abmelden
anyy mcp logout remote-docs
Verwenden Sie die exakt konfigurierte Server-ID. Dies entfernt den aktuellen lokalen Zugangsdaten-Eintrag und schließt die Verbindung; Serverkonfiguration sowie zwischengespeicherte Werkzeuge/Ressourcen/Anweisungen bleiben erhalten. Ohne gespeicherten Eintrag ist es ein erfolgreicher Nullvorgang. Es widerruft keine Remote-Token; ein erkannter älterer Ersatz kann eine weitere Abmeldung benötigen. Der Befehl verwendet nach Möglichkeit das residente Profil; ein Zeitlimit oder eine fehlgeschlagene residente Antwort berechtigt nicht zu Offline-Dateiänderungen.
MCP fragt den Werkzeugkatalog nicht regelmäßig ab. Werkzeuge werden bei Verbindung, expliziten Aktionen und echten Werkzeuglistenänderungs-Benachrichtigungen entdeckt oder aktualisiert; Benachrichtigungsverbindung und unterstützte Sitzungswiederherstellung bleiben erhalten.
Die Servereinstellung connect_timeout_ms ist abgeschafft; entfernen Sie sie aus älterer Konfiguration. call_timeout_ms gilt separat für Initialisierung, Erkennung und Werkzeuganfragen; Öffnen hat keine zusätzliche Gesamtfrist. Geeignete anfängliche HTTP-Fehler können vor dem endgültigen Verbindungsfehler zweimal wiederholt werden.
HTTP-Streams und Tokenaktualisierung
Nach der Initialisierung öffnet der Standard-HTTP-Transport einen separaten GET-Stream für Serveranfragen und Benachrichtigungen. Anbieterbasierte Authentifizierung holt das aktuelle Token bei jedem tatsächlichen HTTP-Versand, auch für dieses GET; sie speichert keine zusätzliche MCP-Kopie des Anbietertokens. Dieses Transportverhalten ergänzt keinen Dashboard- oder Profilschalter.
Der HTTP-Client bewahrt konfigurierte Header, ohne für Loopback-Server ein localhost-
Origin hinzuzufügen. Ein explizit konfiguriertes Origin wird nicht
überschrieben. Server wenden weiterhin ihre eigene Origin-Prüfung an.
Anyy kann einen unterbrochenen Ereignisstrom fortsetzen, wenn der Server einen Cursor geliefert hat. Es setzt diesen Stream mit GET und letzter Ereignis-ID fort; der Werkzeugaufruf wird nicht erneut gesendet. Ohne Cursor lässt ein vor der Antwort endender Antwortstream die Anfrage scheitern. Das Schließen der Verbindung stoppt die Wiederherstellung.
Prozesse mit denselben Profil-/Serverzugangsdaten koordinieren auch Tokenaktualisierung und lesen vor einer weiteren Aktualisierung das gespeicherte Token erneut. Diese Koordination verspricht keine Wiederherstellung nach jedem Absturz oder verlorenen Lease.
Initialisierung und Workspace-Stämme
Ein Server-Initialisierungsergebnis muss eine Zeichenfolge protocolVersion, ein Objekt capabilities und serverInfo mit Zeichenfolgen name und version liefern. Optionales instructions muss eine Zeichenfolge sein. Ein ungültiges Ergebnis schließt die Verbindung, statt den Server als verbunden zu markieren. Fehlende, leere und ungetrimmte Anweisungen bleiben verschieden; die Prompt-Zusammenfassung trimmt sie zur Anzeige.
Server mit roots/list erhalten das kanonische Verzeichnis des residenten Workspaces als einen Dateistamm. Dieser wird beim Erstellen des MCP-Managers festgelegt; Gesprächs- oder logischer Workspace-Wechsel lenkt die gemeinsame Verbindung nicht um.
Ein lokaler stdio-Prozess verwendet standardmäßig dieses Verzeichnis. Sein cwd kann absolut, relativ dazu oder mit führender Home-Syntax sein; auch Befehls- und Argumentpfade unterstützen führende Home-Syntax. Leerraum in cwd bleibt erhalten. Eine Änderung des Prozess-cwd ändert den bekanntgegebenen Workspace-Stamm nicht. Der Stamm liefert Kontext, keine Dateisystem-Berechtigungsgrenze.
Werkzeugbereitstellung und Erkennung
| Bereitstellung | Verwendung |
|---|---|
codemode | Standard; über Codemode entdeckt und aufgerufen |
deferred | Über Werkzeugsuche entdeckt |
direct | Dem Modell direkt deklariert |
hidden | Für Modell- und Codemode-Erkennung nicht verfügbar |
Das geordnete Objekt toolExposure überschreibt die Servervorgabe. Exakte Namen haben Vorrang; andernfalls gewinnt der erste passende Platzhalter. Konfigurieren Sie es ohne Erkennungsrückfrage:
anyy mcp configure context --exposure deferred
anyy mcp set context description 'Documentation tools'
anyy mcp set context toolExposure '{"get-*":"deferred","*":"hidden"}'
Aktivierungs- und Bereitstellungseinstellungen werden in der ausgewählten Definitionsdatei oder ihrer vorhandenen Projektüberschreibung gespeichert. Eine Bereitstellungsänderung aktualisiert verfügbare Werkzeugdeklarationen ohne Neuverbindung; Aktivieren/Deaktivieren betrifft nur diesen Server. Schlägt die Verbindung nach dem Speichern fehl, prüfen Sie den Verbindungsstatus; die gespeicherte Einstellung bleibt.
Verwenden Sie für einen Profilserver ohne Projektüberschreibung anyy mcp disable SERVER_ID --project oder enable SERVER_ID --project, um nur dessen Aktivierungszustand in der Projektdatei zu speichern. Dies gilt nicht für vollständige Projektdefinitionen oder bereits überschriebene Server; gewöhnliches Aktivieren/Deaktivieren verwendet deren ausgewählte Quelle.
configure --description und --tool-exposure sowie allgemeines set/unset bearbeiten die rohe Profildefinition. Kombinieren Sie sie nicht mit configure --exposure oder --enable; führen Sie getrennte Befehle aus. Bearbeiten Sie zum Ändern einer Projektüberschreibung toolExposure diesen Projekteintrag, keine verborgene Profildefinition.
Diese Felder folgen der festen Pi-v1.2-MCP-Konfiguration und Registrierung. Anyy-RPC-tool_exposure ist eine JSON-Zeichenfolge, die Regelreihenfolge über die RPC-Map-Grenze erhält; die gespeicherte Konfiguration enthält einen geordneten Wert toolExposure.
MCP-Werkzeuge erzeugen oder aktivieren keine persönlichen Werkzeuggruppen mcp-*. Gewöhnliche persönliche Werkzeuggruppen, Rollen und Werkzeugnamensbeschränkungen der übergeordneten Sitzung bleiben getrennt. Globales mcp.client.enabled, tools.include, tools.exclude, tools.trusted, --include, --exclude, --activate-toolset und die alte Auswahlrückfrage sind abgeschafft. Entfernen Sie diese Felder aus älterer Konfiguration; sie werden abgelehnt, nicht ignoriert.
Serverzusammenfassungen im Prompt
Anyy fügt beim Start eines Laufs einen Abschnitt mcp_servers hinzu. Er listet aktivierte Server mit Codemode- oder verzögerter Erkennung einschließlich noch verbindender Server. Ausschließlich direkte, ausschließlich verborgene und deaktivierte Server werden ausgelassen; bei beiden Erkennungswegen verwendet ein gemischter Server das Codemode-Label. Die Liste ist ein Erkennungshinweis, kein Verbindungserfolgsbeleg.
Ihre konfigurierte Beschreibung hat Vorrang. Ansonsten verwendet die Zusammenfassung die erste Zeile verfügbarer Serveranweisungen. Namen werden sortiert, Zusammenfassungen gekürzt und ausgelassene Server in der begrenzten Liste gezählt. Halten Sie Beschreibungen knapp; sie sind kein Ort für Zugangsdaten.
Dieser Abschnitt bleibt während der weiteren Werkzeugschritte des Laufs fest. Geänderte Beschreibung, Konfiguration oder neu verfügbare Anweisungen erscheinen beim nächsten Prompt. Ohne geeigneten Server wird der Abschnitt entfernt.
Werkzeuge prüfen und aufrufen
anyy mcp show context
anyy mcp probe context
anyy mcp test context
anyy mcp list
anyy mcp status --json
anyy mcp logs context
anyy mcp reload context
# If the inspected server advertises a search tool with a query field:
anyy mcp call docs.search --args '{"query":"Anyy"}'
Der obige Aufruf ist beispielhaft: Verwenden Sie ursprünglichen Serverwerkzeugnamen und exakte Argumente aus show/probe. Modellsichtbare MCP-Namen in Anyy haben Namespaces und können bereinigt oder mit Kollisionssuffix versehen sein; Codemode-Erkennung liefert ihre JavaScript-Kennungen. Verwenden Sie die aktuelle Deklaration, statt Namen zu konstruieren. Siehe Codemode-Erkennung und Werkzeugsuche.
anyy mcp reload verbindet anhand bereits geladener Konfiguration neu; es liest bearbeitete Dateien nicht erneut. Start und RPC session.reload einer untätigen Sitzung laden Profil- und Projektdateien erneut. Es gibt keinen separaten MCP-Dateiwächter. Siehe Änderungen anwenden.
Prüfen ist optional und keine Voraussetzung für Speichern oder Aktivieren. Sein einzelnes tools-Inventar enthält name, visible_name, description, exposure und offered. Ein angebotenes Werkzeug wird aktuell vom Server bekanntgegeben; dies ist kein Freigabeergebnis. Ein vorbereiteter Aufruf löst beim Ausführen aktuellen Server und Angebot auf.
Neue direkte Aufrufe validieren gegen das aktuelle JSON-Schema des Werkzeugs. Ein bereits vor Konfigurationsersetzung vorbereiteter Aufruf behält deklariertes Schema und validierte Argumente und löst bei Ausführung den aktuellen Server auf. Ersetzen schließt alte laufende Verbindungen, ohne ihre Aufrufe auf dem neuen Server zu wiederholen. Ausgewählte Modellwerkzeuge und anyy mcp call werden direkt ausgeführt, einschließlich Schreibvorgängen. Profilbesitz, Serverauthentifizierung, Zugangsdaten-Schutz und normale Werkzeugnamensbeschränkungen gelten weiterhin. Alte Freigabe-/Ausführungsrichtlinienschlüssel bleiben abgelehnt.
Ressourcen und Vorlagen
Anyy bietet drei gemeinsame Ressourcenwerkzeuge:
| Werkzeug | Eingabe | Programmatisches Ergebnis |
|---|---|---|
list_mcp_resources | Optional server, cursor | resources, optional server, nextCursor, errors |
list_mcp_resource_templates | Optional server, cursor | resourceTemplates, optional server, nextCursor, errors |
read_mcp_resource | Erforderlich server, uri | {server, uri, contents} |
Geben Sie einen Server für eine Seite an und übergeben Sie dann dessen nextCursor für die nächste. Lassen Sie den Server weg, um alle Seiten geeigneter Server zu sammeln; ein Cursor benötigt einen Server. Gemeinsame Listen bewahren erfolgreiche Ergebnisse und nennen fehlgeschlagene Server in errors. Ein Fehler beim ausgewählten Server weist den Aufruf zurück.
Verfügbarkeit folgt aktivierten Servern mit gemeldeter Ressourcenfähigkeit und nicht verborgener Serverbereitstellung. Die gemeinsamen Werkzeuge verwenden die breiteste geeignete Bereitstellung: direct, dann codemode, dann deferred. Sie erscheinen nach Bekanntwerden der Ressourcenfähigkeit; Rücknahme verbirgt zuvor registrierte Definitionen. Ressourceninventare werden beim Aufruf abgerufen, nicht beim Start.
Leseergebnisse bewahren vollständiges programmatisches JSON. Modellausgabe verwendet Text, Bilder oder gespeicherte Dateireferenzen; langer Text folgt dem gemeinsamen Ausgabelimit von 20 KiB. MCP-App-UI-Ressourcen werden aus diesen Listen ausgelassen. Ein Zustellfehler wiederholt keinen erfolgreichen Ressourcenabruf.
Die alten serverbezogenen Ressourcen-/Prompt-Werkzeugnamen und Schalter tools.resources/tools.prompts sind abgeschafft. Entfernen Sie diese Schalter aus der Serverkonfiguration; ihr Vorhandensein wird auch bei false oder null abgelehnt. Der Status behält resources_advertised, prompts_advertised und server_capabilities und entfernt alte Aktivierungs-/Zustands-/Zählfelder für Ressourcen und Prompts. Rohe SDK-Promptmethoden bleiben Protokoll-APIs statt erzeugter Agentenwerkzeuge.
Einen anderen MCP-Client mit Anyy verbinden
anyy mcp serve stellt Gesprächs-, Nachrichten- und Ereignisschnittstellen des residenten Assistenten über stdio bereit. Seine Standardwerkzeuge sind conversations_list, conversation_get, messages_read, events_poll, events_wait und messages_send.
mcp.server.scopes unterstützt nur conversations und messaging. Weglassen schließt beide ein; [] stellt keine Werkzeuge bereit. Freigabeauflistungs-/Antwortwerkzeuge wurden entfernt. Die Konfiguration lehnt den alten Bereich approvals, nicht implementierte Bereichsplatzhalter und die abgeschafften Schlüssel expose_approvals/expose_tools ab. Operationen laufen weiterhin über die bestehenden Gateway-RPCs.
Gesprächsergebnis-API
messages_send akzeptiert nur session_id und text:
{"session_id":"ses_example","text":"Summarize my tasks"}
Es nimmt die Eingabe über session.submit auf und ruft dann execution.await mit der ursprünglichen submission_id auf. Der JSON-Textinhalt des Ergebnisses enthält:
| Feld | Bedeutung |
|---|---|
submission | Ursprünglicher Annahmebeleg einschließlich submission_id |
execution | Beobachteter Zustand und Ergebnis des tatsächlichen Aufrufs dieser Eingabe |
messages | Geordnete Ergebnisnachrichten aus den gespeicherten Referenzen dieses Aufrufs |
timed_out | Ob Beobachtung vor Verfügbarkeit eines Ergebnisses ablief |
Ein späterer Prompt derselben Sitzung kann diese Nachrichten nicht ersetzen. messages_read ist eine Verlaufsabfrage und keine Ersatzantwortquelle. Normaler Schutz und Anhangsbehandlung gelten weiterhin.
Das MCP-Ergebnis hat bei erfolgreichem Abschluss oder tatsächlicher Rückfrageunterbrechung isError=false. suspended bewahrt Rückfragehandles und bedeutet, dass der Assistent Eingabe benötigt; es ist keine abschließende Antwort. Fehler, Unterbrechung, entfernte Eingabe, Zeitlimit oder nicht finaler Zustand haben isError=true. Eine untätige Spur ist nur mit outcome=succeeded erfolgreich.
Bewahren Sie bei direkter Nutzung von Gateway-RPC beide IDs der Annahme:
{"execution_id":"exec_example","submission_id":"sub_example","timeout_ms":30000}
execution.await liefert {execution, submission_id, timed_out, messages}. Das Warten folgt dem ursprünglich reservierten oder ausgewählten Lauf und seiner Wiederherstellungslinie, einschließlich eines Vorbereitungsfehlers vor Eingabeauswahl. Entfernte, nicht ausgewählte Eingabe endet mit outcome=interrupted, stop_reason=input_cleared und ohne Ergebnisnachrichten. Warten aktiviert niemals wartende Eingaben.
Ein Zeitlimit liefert timed_out=true mit leerem Array messages. Zeitlimit oder Aufruferabbruch beendet nur Beobachtung; angenommene Arbeit läuft weiter. Eine execution_id allein beobachtet die wiederverwendbare Spur und identifiziert nicht das Ergebnis eines einzelnen Prompts. Prüfen Sie die Sitzung vor erneutem Senden einer zeitüberschrittenen Anfrage.
Deaktivieren oder entfernen
anyy mcp disable context
anyy mcp remove context
Deaktivieren bewahrt die Konfiguration. Das Entfernen einer MCP-Serverdefinition aus der Profilkonfiguration löscht diese Definition und ihre durch Anyy verwalteten Zugangsdaten; remove --local entfernt nur den Projekteintrag und bewahrt Autorisierungen. Gewöhnliche persönliche Werkzeuggruppen bleiben erhalten. Bei Operationen an MCP-Serverdefinitionen im Profil bestätigt --force das Ersetzen oder Entfernen in Skripten; Profilbesitz oder Zugangsdatenbehandlung werden nicht umgangen.
Fehlerbehebung
| Problem | Prüfung |
|---|---|
| Lokaler Server startet nicht | Befehl, Argumente, Programmdatei und Umgebung |
| Remote-Server nicht autorisiert | Anbieterreferenz, OAuth-Zustand oder geschützter Header |
| Werkzeug nicht verfügbar | Serveraktivierung, Bereitstellung und aktuelles Angebot |
| Werkzeugschema geändert | Aktuelle Definition prüfen und mit gültigen Argumenten erneut versuchen |
| Laufzeit zeigt noch alte Dateiinhalte | Konfiguration per Neuladen einer untätigen Sitzung oder Neustart erneut lesen und ausgewählte Quelle prüfen |
Formulare und Prüfung finden Sie unter Dashboard-MCP.
Ergebnisse und Anhänge
Programmatische Ergebnisse bewahren akzeptierte MCP-Protokollwerte einschließlich null, false, Zahlen, Zeichenfolgen und Arrays in structuredContent. Hat das Ergebnis Inhaltsblöcke, wandelt Anyy diese in Modellinhalt um, ohne structuredContent separat anzuhängen. Ist das Inhaltsarray leer und structuredContent vorhanden, formatiert Anyy dieses JSON als Modelltextblock. Dieser Ersatztext durchläuft denselben Zugangsdaten-Schutz und dieselbe 20-KiB-Ausgabebehandlung wie anderer MCP-Text. Ausgabeschemas beeinflussen die deklarierte programmatische Rückgabe; sie machen strukturierte Remote-Ergebnisse nicht zu einer lokalen Validierungsschranke. Modellinhalt bewahrt geordneten Text und Bilder. Audio und unbekannte Blöcke verwenden Pis Textplatzhalter; eingebettete Ressourcen werden zu Text/Bildern oder gespeicherten Binärdateien. Text über 20 KiB verwendet gespeicherte Vollausgabe und Anfangs-/Endprojektion.
Ein zurückgegebenes Remote-isError bleibt ein Fehlerergebnis. Eine Transport- oder JSON-RPC-Ausnahme weist den Aufruf zurück. Bild- und Dateizustellung nutzt den vorhandenen sitzungseigenen Artefaktweg, bewahrt Reihenfolge und wiederholt bei Zustellfehler keinen Remote-Aufruf. Text wird vor Speicherung geschützt. Speicherung startet für alle Blöcke, bevor die Konvertierung deren Abschluss abwartet; ein ungültiger Block kann daher Konvertierung zurückweisen, während gestartete Speicherungen fertig werden.
Gewöhnliche Netzwerkfehler wiederholen Werkzeugaufrufe nicht automatisch; Wiederherstellung abgelaufener Sitzungen ist ein separater Fall. OAuth-Registrierung, Tokenaktualisierung und Transportanforderungen hängen vom externen Dienst ab. Prüfen Sie tatsächliche Verbindung und Werkzeugergebnis, bevor Sie sich darauf verlassen.