MCP (Model Context Protocol)

Vor einem solchen Standard musste jede Anwendung, die einem Modell Zugriff auf einen Kalender, eine Datenbank oder ein Code-Repository geben wollte, ihren eigenen Anschluss schreiben. MCP teilt die Arbeit in zwei Teile. Ein Server umhüllt eine Fähigkeit, etwa ein Dateisystem oder ein Ticketsystem, und beschreibt, was er anbietet. Ein Client in der KI-Anwendung entdeckt diese Beschreibung und reicht sie an das Modell weiter, das diese Fähigkeiten dann aufrufen kann. Server können Werkzeuge anbieten, die Aktionen ausführen, Ressourcen, die Daten zum Lesen liefern, und Prompts, die fertige Anweisungen bündeln. Typische Server verbinden einen Kalender, eine Notiz-App, einen Bugtracker, eine Tabelle, eine Datenbank, ein E-Mail-Postfach, ein Code-Repository oder einen Webbrowser, jeden auf dieselbe vorhersehbare Weise. Ressourcen können Dateien, Tabellenzeilen, Screenshots oder Protokolle sein; Prompts können Vorlagen sein, etwa eine Checkliste für Code-Reviews oder eine Besprechungszusammenfassung. Stell dir eine Schublade voller inkompatibler Ladegeräte vor, die durch eine einzige universelle Steckdose ersetzt wird.

Server laufen entweder auf deinem eigenen Rechner und sprechen über Standardein- und -ausgabe mit der Anwendung oder entfernt über HTTP. Das ist eine andere Ebene als das Tool Calling. Tool Calling ist die Art, wie ein Modell in einer Anfrage eine Funktion anfordert; MCP ist die Art, wie die Anwendung viele solcher Funktionen überhaupt erst findet und erreicht. Die Anwendung übersetzt die entdeckten MCP-Werkzeuge meist in gewöhnliche Werkzeugdefinitionen für das Modell, beides ergänzt sich also, und das Modell verbindet sich nie direkt mit einem Server. Entfernte Server werfen zudem die Frage der Authentifizierung auf: Finde heraus, wie ein Server nachweist, wer ihn aufruft, und wo deine Zugangsdaten landen. Ein lokaler Helfer passt zur ersten Variante, ein gemeinsamer Teamdienst zur zweiten.

Die Bequemlichkeit bringt Risiken mit, die Aufmerksamkeit verdienen. Ein Server kann alles lesen und ändern, wozu du ihm Zugriff gibst, und ein bösartiger oder nachlässiger Server kann Daten abfließen lassen oder schädliche Aktionen auslösen. Beschreibungen und Ergebnisse eines Servers sind Text, den das Modell liest, sie können also Anweisungen verbergen, die es lenken sollen. Installiere Server nur aus vertrauenswürdigen Quellen, vergib möglichst enge Rechte, prüfe, was jedes Werkzeug tut, und bevorzuge Rückfragen bei allem, was schreibt, sendet oder löscht. Eine gute Gewohnheit ist, die Werkzeugliste, die ein Server ankündigt, vor dem Aktivieren zu lesen, so wie du die Berechtigungen einer Handy-App liest. Die bekannteste Falle ist Prompt-Injection: Ein vergiftetes Ergebnis fordert das Modell auf, eine Datei preiszugeben.

Damit klar ist, was es heute gibt: In den Missionen kann sich NeverNo mit einem entfernten MCP-Server verbinden, den du selbst hinzufügst (Adresse und optionales Token), während die API selbst keine MCP-Server betreibt und sich nicht mit ihnen verbindet. Es bietet Function Calling bei Chat-Completions, wo dein eigener Code die Werkzeuge definiert und ausführt, dazu einen Anthropic-kompatiblen Messages-Endpunkt. Modelle, deren capabilities.tools in der Liste /models true ist, akzeptieren Werkzeuge.

Ein Werkzeug, das du selbst betreibst und das MCP spricht, kann NeverNo trotzdem als Modell nutzen, indem du seine Basis-URL auf https://neverno.ai/api/v1 richtest, denn die Endpunkte folgen den Formaten von OpenAI und Anthropic. Die MCP-Verbindungen liegen dann in diesem Werkzeug, nicht bei NeverNo. DeepSeek V4 Flash, ein kostenloses privates Modell mit einem Kontextfenster von 128.000 Tokens, ist eines der Modelle auf der Liste.