MCP

Everything MCP: für Client-Autoren, die Protokollmerkmale per npx durchspielen

Für alle, die einen MCP-Client bauen und einen Testserver brauchen, der tools/prompts/resources/sampling üben kann; kein Produktionswerkzeug.

Official source · Everything MCP Server

Install

npx @modelcontextprotocol/server-everything

Für wen

Wer einen MCP-Client implementiert oder debugt und einen Testserver braucht, der Protokollfunktionen einmal durchlaufen kann. Es ist ausdrücklich „not intended to be a useful server“ und dient nur dazu, MCP-Protokollmerkmale zu exercise. Passt zu Leuten, die @modelcontextprotocol/server-everything per npx starten und akzeptieren, dass Rückgaben Demodaten statt Geschäftsergebnisse sein können. Nicht als Produktions-Scrape, -Repository oder -Suchwerkzeug. Offizielle Seite: https://github.com/modelcontextprotocol/servers/tree/main/src/everything

Ersten Versuch in 3 Minuten

Nur einen offiziellen Weg: Standard-stdio.

Voraussetzung: npx ist auf der Maschine. Das ist ein Testbett für Client-Bauer, nicht für Endgeschäft.

Installations- und Konfigurationsort: im MCP-Client den Startbefehl so schreiben:

npx @modelcontextprotocol/server-everything

Das gleichwertige Konfigurationsfragment ist command: npx, Argumente -y und @modelcontextprotocol/server-everything.

Risikoarme Aktion: nach dem Verbinden den Client die vom Server deklarierten tools listen lassen, dann das erste tool der Liste aufrufen. Keinen Werkzeugnamen handschreiben, der im Dokument nicht vorkommt. Der Server implementiert auch prompts, resources, sampling; listet der Client prompts oder resources, darfst du stattdessen den ersten prompt nehmen oder eine resource lesen. Diese Aufrufe prüfen, ob der Client einen echten tool-/prompt-/resource-Hin-und-Rückweg schafft, nicht eine Geschäftsaufgabe.

Erfolgssignal: der Client listet mindestens eine Klasse (tools, prompts oder resources), und der gewählte Aufruf gibt Inhalt zurück. Leere Liste oder sofortiges Prozessende zählen als unvollständig. Bei Fehler zuerst bestätigen, dass der Befehl Standard-stdio ist, nicht veraltetes HTTP+SSE.

Anwendungsfälle

Fall 1: tools prüfen. Entspricht „It implements prompts, tools, resources, sampling, and more“. Mit einem Testclient list tools → call tool durchlaufen. Rückgaben können Platzhalter oder Demolasten sein; sie sagen nur, ob der Client korrekt geparst hat. Die Evidenz nennt keinen tool-Namen und keine Parameter; der Fall endet bei „einen Aufruf an ein auf der Liste wirklich vorkommendes tool“.

Fall 2: prompts, resources oder sampling prüfen. Derselbe Fähigkeitsatz. Den Client einen prompt holen oder eine resource lesen lassen; implementiert der Client sampling, beobachten, ob der Server einen Sampling-Lauf auslöst. Die Evidenz nennt nur Fähigkeitsklassen, keine prompt-Namen, resource-URIs oder Sampling-Nachrichtenformate. Fehlendes folgt Objekten, die der Client zur Laufzeit listet; keine URIs erfinden.

Nutzungsgrenzen

Das ist ein Testserver, kein nützlicher Geschäftsserver. Nicht für echte Kundendaten nutzen und keine stabile Geschäftssemantik erwarten.

HTTP+SSE Transport wurde am 2025-03-26 veraltet. npm install und npm run start:sse im Quellverzeichnis sind nicht der Erstversuchsweg.

Offizielle Empfehlung ist npx-Standard-stdio. Selbst wenn ein tool-Aufruf nur lesend wirkt, kann die Testimplementierung Benachrichtigungen senden, Sampling anfordern oder Demorisourcen schreiben; nicht als null Nebenwirkungen behandeln. Es gibt keine Clientliste und keine gehostete URL.