VitaminMCP

MCP-Server-Plugin für die Minecraft-Testautomatisierung für KI-Agenten.

VitaminMCP ist ein Paper/Purpur-Server-Plugin. Legen Sie VitaminMCP.jar in plugins/ ab, starten Sie den Server, und es öffnet einen MCP-Endpunkt von innerhalb des laufenden Servers – sodass ein KI-Agent diesen Server steuern und zurücklesen kann, was passiert ist, während echte Bot-Clients sich über das Minecraft-Protokoll mit ihm verbinden.

An dem Plugin, das Sie testen, ändert sich nichts. Kein Testframework, das Sie übernehmen müssen, kein Quellcode, der instrumentiert werden muss, kein Testrahmen, gegen den kompiliert werden muss, kein Mock-Server, der einen echten ersetzt: Das zu testende Plugin läuft auf einem echten Server durch seinen echten Lebenszyklus, und VitaminMCP beobachtet es vom nächsten Plugin-Slot aus. Das bedeutet auch, dass es mit Plugins funktioniert, die Sie nicht geschrieben haben – alles, was bereits installiert ist, ist testbar.

Steuern Sie einen echten Minecraft-Server und echte Spieler über MCP-Tools und führen Sie End-to-End-Plugin-Tests aus, ohne das Spiel zu öffnen.

• Testspieler spawnen und steuern – echte Protokoll-Clients, keine Mock-Player-Objekte

• Befehle als Konsole oder als Spieler ausführen

• Inventare und Plugin-GUIs öffnen, lesen, anklicken und prüfen

• NPCs und Dorfbewohner rechtsklicken, so wie ein Shop- oder Questgeber tatsächlich ausgelöst wird

• Spieler bewegen, Blöcke abbauen und benutzen, chatten

• Auf Ereignisse und Bedingungen warten, statt zu schlafen

• Blöcke, Spieler, Ereignisse, Inventare und die Nachrichten, die ein Spieler erhalten hat, prüfen

• Den gesamten Bildschirm des Spielers lesen: Menüs, Chat, Action Bar, Titel, Bossbars, Scoreboard

• Live-Serverstatus lesen: Ereignisse, Logs, Ausnahmen, Berechtigungen

• Mehrere Server gleichzeitig steuern – eine Sitzung pro Backend eines BungeeCord-Netzwerks, wobei Bots über alle hinweg verbunden bleiben

• Paper / Purpur 1.21 bis 1.21.11, aus einer einzigen Installation – der Runner ermittelt, welches Protokoll der Server spricht, und passt sich an

Die vollständige Nutzung finden Sie in docs/usage.md. Beitragsregeln stehen in CONTRIBUTING.md, und die Schritte für Veröffentlichungen in docs/publishing.md.

Wie es zusammenspielt

Drei JARs, an drei verschiedenen Orten. Nur das erste ist ein Minecraft-Plugin.

  your MCP client (Claude Code, Cursor, Codex, Gemini CLI, ...)
        |
        |  stdio
        v
  mcp-server.jar ---- HTTP(S) + token ---->  VitaminMCP.jar  <- the plugin, inside your server
        |                                    sees events, logs, exceptions, live state
        |  spawns
        v
  Node runner -------- Minecraft protocol ->  the same server, on :25565
                                             sees what a player's client was actually sent

Das Plugin sieht serverseitige Ereignisse, Logs, Berechtigungen und Zustand; der Node-Runner sieht, was ein echter Client empfängt. Der Nur-Lese-Modus ist die Standardeinstellung, und Bots sind optional.

Related MCP server: Minecraft RCON MCP Server

Beispiel

Bitten Sie den Agenten, ein Plugin zu testen, oder übergeben Sie ein Szenario an bot_run_scenario:

[
  {"action":"spawn", "bot":"Tester1"},
  {"action":"command", "bot":"Tester1", "command":"shop"},
  {"action":"wait_for", "condition":"inventory_open", "name":"Tester1", "title":"Shop"},
  {"action":"assert_inventory", "bot":"Tester1", "slots":[
    {"slot":11, "material":"DIAMOND_SWORD", "name":"Diamond Sword"}
  ]}
]

Tools

Zwei Gruppen. Session-Tools leben in mcp-server und sind immer vorhanden. Agent-Tools werden über das Plugin weitergeleitet, sodass der Server, mit dem Sie verbunden sind, darüber entscheidet, welche existieren – session_start gibt ihre tatsächlichen Definitionen in agentTools zurück.

Verbindung

Spieler

Server

Welt und Zustand

Ereignisse und Logs

Warten

wait_for blockiert, bis eine Bedingung erfüllt ist, geprüft bei jedem Tick im Server.

Es gibt kein Schlafen, und es wird keins geben. Ein festes Warten ist eine Vermutung über das Timing, die auf einem untätigen Server richtig und auf einem beschäftigten falsch ist – das ist der gesamte Mechanismus, durch den flaky Tests entstehen. Bei Zeitüberschreitung gibt wait_for die Ereignisse und Logs von diesem Moment zurück.

Aktionen – Szenarioschritte

Verfügbar innerhalb von bot_run_scenario.

Assertions — Szenarioschritte

Verifikation ist der Kern, daher ist die Oberfläche hier am breitesten.

Verwende bot_inspect für Nachrichten, Bildschirmzustand und Effekte; verwende state_query für den Serverzustand. Übergib proxierte Parameter flach auf oberster Ebene. Vollständige Parameter findest du in docs/usage.md.

Anforderungen

Dies sind die Anforderungen für die Nutzung eines vorgefertigten Releases:

Versionsunterstützung

Runner-Unterstützung nach Betriebssystem

Legende: 🟢 unterstützt · 🟡 geplant oder erfordert die angegebene Laufzeitumgebung · 🔴 nicht unterstützt.

1.21 bis 1.21.11 werden heute unterstützt, und jede dieser Versionen läuft in der Matrix (versions.yaml). 1.21.11 ist das Ende dieser Linie — Minecraft ist danach auf Kalenderversionen umgestiegen, daher folgen auf 1.21.11 die Versionen 26.1 und 26.2 statt einer 1.21.12. Diese sind veröffentlicht, aber noch nicht in der Matrix: Eine hinzuzufügen bedeutet einen Kompatibilitätslauf gegen einen echten Server plus eine Prüfung, dass die gebündelten Daten des Runners sie weiterhin abdecken — niemals nur eine Bearbeitung von versions.yaml.

Woher der Anspruch jeder Plattform stammt. Die Matrix wird unter Windows gegen Paper-Builds ausgeführt, die sie selbst herunterlädt — was sie beweist, gilt also auf jedem Host, denn der Server, mit dem sie spricht, ist derselbe Server. Jedes Release baut seinen nativen Runner auf dem Betriebssystem, für das der Runner bestimmt ist, niemals cross-kompiliert, und jeder einzelne wird in CI gestartet und muss seinen eigenen Einstiegspunkt mit dem erwarteten Exit-Code ablehnen, bevor er hochgeladen wird. Die Weltansicht ist das einzige Stück, das weiterhin nur unter Windows verfügbar ist, und das wird dort, wo sie angeboten wird, auch so angegeben.

Unabhängig von der Version installierst du genau einen Node-Runner. Er fragt den Server, welches Protokoll er spricht, und wählt den passenden minecraft-data-Eintrag aus, sodass kein protokollspezifischer Runner gewählt werden muss.

Aus dem Quellcode bauen

Die meisten Nutzer benötigen diesen Abschnitt nicht. Mitwirkende benötigen JDK 21 und Node/npm:

./gradlew build
cd bot/bot-runner-node && npm ci && npm test

Native Runner werden mit npm run build:sea -- win32-x64, linux-x64, linux-arm64, darwin-x64 oder darwin-arm64 gebaut. macOS-Artefakte erhalten im Release-Workflow eine Ad-hoc-Signatur.

Außerhalb des unterstützten Bereichs schlagen Dinge klar fehl, statt sich falsch zu verhalten: Ein älterer Server lehnt es ab, den Agenten zu laden, und ein Server, dessen Protokoll keinen minecraft-data-Eintrag hat, wird beim Start benannt.

Agent-Unterstützung und Bot-Unterstützung können sich ebenfalls unterscheiden. Der Agent benötigt eine kompatible Paper-API; Bots benötigen einen passenden minecraft-data-Eintrag und eine unterstützte Runner-Umgebung. Ein Server kann also für den Agenten lesbar sein, bevor Bots ihm beitreten können — Inspektion, Logs und Ereignisse funktionieren auch ohne sie weiterhin.

Installation

Zwei Hälften, und keine ist für sich allein nützlich: ein MCP-Server auf deinem Rechner, den dein Client startet, und das Agent-Plugin auf dem Minecraft-Server, wo all das passiert, wonach sich zu fragen lohnt.

1. Verbinde deinen MCP-Client

Der MCP-Server ist reines stdio: Jeder Client, der npx -y vitaminmcp starten kann, funktioniert — Claude Code, Cursor, Codex, Gemini CLI, Windsurf, Claude Desktop, VS Code. Das ist die eine Konfiguration, die jeder Client in seiner eigenen Datei ausdrückt:

{
  "mcpServers": {
    "vitaminmcp": {
      "command": "npx",
      "args": ["-y", "vitaminmcp"]
    }
  }
}

Claude Code hat eine Abkürzung: Das Plugin bringt den MCP-Server und das praktische Wissen, wie man ihn bedient, als Skill mit, der sich selbst lädt, wenn eine Frage danach verlangt. Gib diese in den Claude-Code-Prompt ein (es sind Claude-Code-Befehle, keine Shell-Befehle):

/plugin marketplace add Backas03/VitaminMCP
/plugin install vitaminmcp@vitaminmcp

Überall sonst registrierst du den Server dort, wo der jeweilige Client seine MCP-Konfiguration aufbewahrt:

Jedes Tool funktioniert in jedem Client gleich. Was nur Claude Code bekommt, ist der Skill des Plugins — das schriftliche Test-Playbook. Andere Clients erhalten weiterhin das Betriebswissen, das zum Aufrufzeitpunkt zählt: session_start gibt die vollständigen Tool-Definitionen des Agenten zurück, und die Tool-Beschreibungen tragen ihre eigenen Warnhinweise.

Das ist die gesamte Client-Seite. Es muss nichts von Hand heruntergeladen und kein Pfad richtig gesetzt werden: Das Paket vitaminmcp lädt die benötigten Jars beim ersten Start in ~/.vitaminmcp/jars/<version>/ herunter, wobei jedes gegen einen SHA-256 geprüft wird, der bei der Veröffentlichung im Paket fixiert wurde.

mcp-server.jar ist zwei Megabyte groß und wird erwartet. Mit installiertem Node wird der Source-Runner direkt verwendet und kein Runner-Asset heruntergeladen. Ohne Node wählt der Launcher das native Runner-Asset für die aktuelle Plattform aus – und jede unterstützte Plattform hat eines.

mcp-server spricht stdio. Er hat keinen Port und kein Token: Er ist ein Kindprozess des Clients, die Vertrauensbeziehung besteht also bereits. Nur die Agent-Seite überquert ein Netzwerk, und deshalb authentifiziert sich nur die Agent-Seite.

Benötigt Node 18.17+ für npx und Java 21, um die Jars auszuführen. Kein npm, oder keine Möglichkeit zum Herunterladen? Installation über die Jars.

2. Das Plugin auf dem Server installieren

Einfach fragen, und der Agent erledigt es. Der MCP-Server veröffentlicht einen setup-Prompt, der den Agenten durch diesen Schritt führt – er prüft, ob der Server Paper 1.21+ ist, legt das Jar in plugins/ ab, startet neu und verbindet sich. Clients zeigen MCP-Prompts unter ihren eigenen Namen an, die aus dem Namen gebildet werden, unter dem der Server registriert wurde. In Claude Code:

/mcp__plugin_vitaminmcp_vitaminmcp__setup    # installed as the plugin
/mcp__vitaminmcp__setup                      # added with claude mcp add vitaminmcp

/mcp zeigt, wie Ihr Server tatsächlich heißt. In einem Client, der Prompts woanders (oder gar nicht) auflistet, fragen Sie einfach in normalen Worten:

Prompt: Richten Sie VitaminMCP auf meinem Minecraft-Server unter ~/servers/test ein und verbinden Sie sich damit.

Von Hand stattdessen:

Laden Sie VitaminMCP.jar von den Releases in das plugins/-Verzeichnis des Servers herunter – ein gewöhnliches Bukkit/Paper-Plugin, keine Server-Flags und kein anzuhängender Java-Agent – und starten Sie den Server.

[VitaminMCP] No auth token was configured, so one was generated and written to config.yml: kQ8s...
[VitaminMCP] MCP endpoint listening on http://127.0.0.1:25585/mcp

Sie müssen dieses Token nicht kopieren. Ein Client auf derselben Maschine liest es aus dem eigenen Handshake des Agents. Kopieren Sie es nur für einen Client an einem anderen Ort.

Das ist die Mindestinstallation. Alle weiteren Einstellungen sind in config.yml dokumentiert, zusammen mit dem Grund, warum jeder Standardwert so ist, wie er ist. Drei Standardwerte sollten Sie kennen, bevor Sie etwas ändern:

• read-only: true ist die Standardeinstellung. Zustandsverändernde Tools wie command_exec werden überhaupt nicht bereitgestellt – eine Standardinstallation kann den Server selbst mit einem gültigen Token nicht verändern. Schalten Sie es nur aus, wenn Sie es benötigen.

• Der Endpunkt ist nie ohne Authentifizierung erreichbar. Ein leeres auth-token wird mit einem generierten ausgefüllt, statt durchgewunken zu werden, und wenn es nicht geschrieben werden kann, weigert sich das Plugin weiterhin zu starten. Dass ein Token existiert, war nie verhandelbar; es war nicht Teil davon, Sie eines aus einem Absturzprotokoll heraussuchen zu lassen.

• bind-address von Loopback zu entfernen macht TLS zur Pflicht. Das Token gewährt Konsolenzugriff, und über unverschlüsseltes HTTP überquert es das Netzwerk im Klartext, wo jede Komponente auf dem Weg es lesen kann. Diese Kombination ist also eine Startverweigerung, keine Warnung. Erfüllen Sie sie entweder mit tls.enabled (der Agent bedient HTTPS selbst) oder mit tls.terminated-upstream (ein vorgeschalteter Proxy beendet es). Der Agent wird für Sie kein selbstsigniertes Zertifikat erzeugen – bequem, aber es würde jedem Client beibringen, die Verifizierung zu überspringen.

3. Server-Einrichtung, wenn Sie Bots wollen

Überspringen Sie diesen Abschnitt, wenn Sie nur den Agenten benötigen.

Bots verwenden den Offline-Modus und verwenden dieselbe deterministische UUID wieder, wenn der Bot-Name wiederverwendet wird:

# server.properties
online-mode=false

Setzen Sie einen Server im Offline-Modus niemals dem Internet aus. Dies ist eine Test-Harness-Konfiguration, keine Produktionskonfiguration. Für normale Node-Anmeldungen ist keine BungeeCord-Einstellung erorderlich.

Die Wiederverwendung eines Bot-Namens verwendet auch seine deterministische Offline-UUID wieder. Aktiveren Sie BungeeCord-Forwarding ausdrücklich nur für einen Test, der clientIp übergibt und eine gefälschte Adresse oder UUID benötigt.

move_to läuft standardmäßig zu seinem Ziel und verwendet dabei dieselbe clientseitige Physikschleife, die die Bewegungspakete zwischen den beiden Punkten sendet. Das bedeutet, dass Plugins, die auf Druckplatten und Bewegungsereignisse lauschen, die Route beobachten. Ein Pfad, der nicht gefunden werden kann, schlägt mit No path exists fehl; ein Pfad, der nicht vor timeoutMillis ankommt, schlägt mit did not arrive ... within ... fehl.

Für Einrichtungsschritte, die nur einen Bot an einer Koordinate benötigen, verwenden Sie "mode":"teleport". Das behält das alte Verhalten mit einem einzigen Positionspaket bei und ist weiterhin schnell, löst aber nicht die Ereignisse aus, die ein gehender Spieler verursacht hätte.

Gehen gräbt sich nicht durch Blöcke und platziert keine. Der Pfadfinder ist absichtlich für normale Fortbewegung konfiguriert, sodass eine Testwand eine Testwand bleibt.

4. Verbinden

Fragen Sie einfach. Das sind Prompts – kopieren Sie einen und tragen Sie Ihre eigenen Werte ein.

Ein Server auf dieser Maschine

Prompt: Verbinden Sie sich mit dem Minecraft-Server auf dieser Maschine und nennen Sie mir dann die Serverversion und welche Plugins geladen sind.

Hinter einem SSH-Tunnel – geben Sie an, welche lokalen Ports der Tunnel weiterleitet

Prompt: Der Testserver ist zu dieser Maschine getunnelt – Minecraft auf localhost:10000, der Agent auf localhost:25685. Das Token ist kQ8s…. Verbinden Sie sich und bestätigen Sie, dass er aktiv ist.

Oder lassen Sie das Token aus dem Gespräch heraus und verweisen Sie stattdessen auf eine Datei – der Agent liest sie und übergibt sie an session_start:

Prompt: Der Testserver ist zu dieser Maschine getunnelt – Minecraft auf localhost:10000, der Agent auf localhost:25685. Das Token befindet sich in ~/.secrets/vitaminmcp-token. Verbinden Sie sich und bestätigen Sie, dass er aktiv ist.

Wenn ein Token überhaupt nie in einem Prompt auftauchen soll, setzen Sie VITAMINMCP_TOKEN in der Umgebung des MCP-Servers (ein "env"-Block neben "command" in der Client-Konfiguration) – session_start fällt darauf zurück, wann immer kein token-Argument angegeben ist.

Remote per TLS – fügen Sie den Block ein, den der Agent beim Start ausgegeben hat

Prompt: Verbinden Sie sich damit: host 203.0.113.10, mcpPort 25585, tls true, token YLwNyFij…, fingerprint sha256:ffb61d8f…f163. Minecraft ist auf 25565.

Oder mit dem Token in einer Datei statt im Gespräch:

Prompt: Verbinden Sie sich damit: host 203.0.113.10, mcpPort 25585, tls true, fingerprint sha256:ffb61d8f…f163, token in ~/.secrets/vitaminmcp-token. Minecraft ist auf 25565.

Für alles, was nicht auf dieser Maschine läuft, geben Sie die Portnummern und das Token an. Ohne sie muss der Agent Standardwerte raten, und ein falscher Tipp zeigt sich als abgelehntes Token statt als falsche Adresse – derselbe Fehler, egal welches Detail gefehlt hat.

Was der Agent aufruft: session_start

session_start

Keine Argumente. Der Agent schreibt seinen Host, beide Ports und sein Token, während er läuft, in ~/.vitaminmcp/agents/<port>.properties, und session_start liest sie – für einen Server auf dieser Maschine gibt es also nichts zu übergeben und nichts nachzuschlagen. Eine erfolgreiche Verbindung liefert die Serverversion, TPS und Plugin-Liste, die tatsächlichen Tool-Definitionen des Agents und die aktuelle Sitzungsliste. Sitzungen, deren Runner-Prozess beendet wurde, werden aus dieser Liste entfernt.

Übergeben Sie, was abweicht, und nur das. Ein Server an einem anderen Ort benötigt host und token, denn ein auf dieser Maschine ausgestelltes Token sagt nichts über einen Server auf einer anderen aus und wird nicht dorthin gesendet:

{
  "host": "203.0.113.10",
  "token": "auth-token from config.yml",
  "tls": "true",
  "tlsFingerprint": "sha256:ffb61d8f...f163"
}

Ein Netzwerk hinter einem Proxy besteht aus mehreren Servern. Öffnen Sie eine Sitzung pro Backend – sie koexistieren, und das Starten einer stört nie eine andere, was wichtig ist, weil das Schließen einer Sitzung ihre Bots trennt. In jeder Sitzung ist port der des Proxys; was sie unterscheidet, ist mcpPort, der Agent in jedem Backend. Wenn lokal mehr als ein Agent läuft, ist das auch das, was zwischen ihnen wählt, und das Weglassen führt zu einem Fehler, der sie benennt, statt zu einer Vermutung.

session_start {"session": "lobby",    "mcpPort": 25585, "port": 25577}
session_start {"session": "survival", "mcpPort": 25586, "port": 25577}
bot_spawn     {"session": "lobby", "name": "Tester1"}

Jedes andere Tool nimmt session entgegen. Wird es weggelassen, wird es nur aufgelöst, solange eine Sitzung offen ist; bei mehreren ist es ein Fehler, der sie benennt, statt einer Vermutung darüber, welchen Server Sie gemeint haben. Die vollständige Anleitung finden Sie in docs/usage.md.

Stattdessen von den Jars aus installieren

npx ist eine Bequemlichkeit, keine Voraussetzung. Zwei Artefakte plus die optionalen Plattform-Runner-Assets sind an jede Release angehängt, und jedes landet woanders:

Um sie stattdessen selbst zu bauen:

./gradlew dist

Richten Sie den Client in jedem Fall auf das Jar statt auf das Paket aus – dieselbe Registrierung wie in Schritt 1, anderer Befehl:

{
  "mcpServers": {
    "vitaminmcp": {
      "command": "java",
      "args": ["-jar", "/absolute/path/mcp-server.jar"]
    }
  }
}

Oder in Claude Code: claude mcp add vitaminmcp -- java -jar /absolute/path/mcp-server.jar.

VITAMINMCP_RUNNER_JAR bzw. das runnerJar von session_start benennt das Node-Skript oder den nativen Runner.

Ein Node-Runner für jede unterstützte Version. Er pingt den Server, bevor sich ein Bot verbindet, und wählt die passenden mineflayer-Daten aus, sodass derselbe Source-Runner von 1.21 bis 1.21.11 funktioniert.

Ein Server auf einer anderen Maschine

Zwei Möglichkeiten: Leiten Sie die Ports per SSH weiter, oder exponieren Sie den Agenten mit TLS. Wenn Sie bereits SSH zu der Maschine haben, ist der Tunnel weniger Aufwand und exponiert nichts.

Über einen SSH-Tunnel

Lassen Sie den Agenten auf seiner Loopback-Standardeinstellung und leiten Sie beide Ports weiter:

ssh -L 25585:127.0.0.1:25585 -L 25565:127.0.0.1:25565 user@your-server

Verbinden Sie sich dann so, als ob alles lokal wäre – host: "127.0.0.1", kein tls, kein tlsFingerprint. Der Agent sieht eine Loopback-Verbindung, weil es von seiner Seite aus genau das ist. Auf dem Server wird nichts ins Netzwerk veröffentlicht, und das Token überquert es nie im Klartext: SSH ist die Transportsicherheit, die TLS andernfalls bereitstellen müsste.

Leiten Sie beide Ports weiter. Über mcpPort erreichen die Tools den Agenten, und port ist der Ort, an dem sich Bots verbinden – wenn Sie nur den ersten weiterleiten, erhalten Sie ein funktionierendes server_info und einen bot_spawn, der sich nicht verbinden kann.

Wählen Sie lokale Ports, die tatsächlich frei sind. ssh -L bindet die lokale Seite, und wenn auf Ihrer Maschine bereits etwas diesen Port belegt, übernimmt der Tunnel ihn nicht – Ihre Anfragen erreichen stattdessen das andere Programm. Der daraus resultierende Fehler ist irreführend: Ein anderer VitaminMCP-Agent, der auf 25585 antwortet, lehnt Ihr Token ab, sodass es wie ein falsches Token statt wie ein falsches Ziel aussieht. Im Zweifelsfall weisen Sie einen eindeutigen lokalen Port zu (-L 25685:127.0.0.1:25585) und übergeben diesen als mcpPort.

Den Agenten mit TLS exponieren

Sobald bind-address nicht mehr auf Loopback zeigt, startet der Agent ohne TLS nicht. Richten Sie ein Zertifikat ein und starten Sie ihn, und der Agent gibt alles aus, was für die Verbindung nötig ist:

[VitaminMCP] MCP endpoint listening on https://203.0.113.10:25585/mcp
[VitaminMCP] Connect with session_start:
  "host": "203.0.113.10", "mcpPort": 25585, "tls": "true",
  "token": "YLwNyFij...",
  "tlsFingerprint": "sha256:ffb61d8f...f163"

Fügen Sie es ein, und Sie sind fertig. Ein selbstsigniertes Zertifikat erfordert weiterhin keinerlei Installation auf dem Client – tlsFingerprint pinnt genau dieses eine Zertifikat. Kein Exportieren, kein Kopieren, kein Truststore.

Mit einem echten Zertifikat (Let's Encrypt und Konsorten) lassen Sie tlsFingerprint weg, und die Verifizierung läuft normal ab.

Gegen mehrere Versionen ausführen

Dasselbe Szenario kann in einem Durchlauf gegen jede unterstützte Version ausgeführt werden. Die Matrix ist versions.yaml, kein Code – das Hinzufügen einer Version ist ein einzelner Block. Server-Jars werden von der PaperMC-API heruntergeladen und nativ gestartet (kein Docker, kein ViaProxy; keine zusätzliche Übersetzungsschicht).

Das Protokoll ist bewusst nicht in dieser Datei. Der Node-Runner fragt jeden Server, was er spricht, und wählt den passenden minecraft-data-Eintrag aus, sodass eine Version dort nichts außer dem herunterzuladenden Build benötigt.

Versionen jenseits von 1.21.11 – was jetzt 26.1 und höher bedeutet, da die 1.21-Linie dort endete – erfordern vor dem Hinzufügen einen Kompatibilitätslauf und eine Prüfung, ob die reduzierten Daten des Runners sie weiterhin abdecken. Der Runner wählt die passende Datenversion aus dem Server-Handshake aus und verweigert klar, statt nur halb zu funktionieren, wenn er keinen Eintrag hat.

Lizenz

MIT – siehe LICENSE.

Die verteilten JARs bündeln Drittanbieter-Code, der so verschoben wurde, dass er nicht mit dem Server oder anderen Plugins kollidieren kann:

Ihre Lizenz- und Hinweisdateien werden in den JARs unter META-INF/ mitgeliefert — das Verschieben eines Pakets benennt es um, hebt aber die Verpflichtung nicht auf, den Hinweis mitzuführen.

paper-api, log4j-core und die JetBrains annotations sind nur zur Compile-Zeit erforderlich und werden nicht mitgeliefert. Der Agent kompiliert gegen die API von Paper, die unter LGPL-3.0 steht; das JAR enthält sie nicht, und der Server stellt sie bereits bereit. Nichts hiervon berührt paper-server (GPL-3.0) — der Agent verwendet ausschließlich die Bukkit/Paper API, niemals NMS.