Alle Beiträge

MCP-Server in PHP: was das offizielle SDK kann und wann du es lässt

KI-Werkzeuge · 4 Min. Lesezeit ·

Für das Model Context Protocol gibt es ein offizielles PHP-SDK, entwickelt zusammen mit The PHP Foundation und dem Symfony-Projekt, und es stand diese Woche auf der wöchentlichen Trending-Liste für PHP auf GitHub. Wer beruflich PHP schreibt, kann seine Anwendung also für einen KI-Assistenten öffnen, ohne die Sprache zu wechseln. Vorher lohnt es sich zu verstehen, was man da eigentlich baut: eine Tür in das eigene System, an die ein Modell klopfen darf.

MCP in zwei Sätzen

MCP ist ein offenes Protokoll, über das eine KI-Anwendung Tools (Aktionen) entdecken und aufrufen, Ressourcen (Daten) lesen und Prompts (Vorlagen) nutzen kann, die ein Server bereitstellt. Die KI-Anwendung ist der Host, dein Code ist der Server, und beide tauschen strukturierte Nachrichten aus, statt dass das Modell deine API aus der Dokumentation errät.

KI-App (der Host) startet dein Skript Nachrichten über STDIO oder HTTP bei einem Remote-Server Dein PHP-MCP-Server gebaut mit mcp/sdk Tools Ressourcen Prompts Aktionen, Daten, Vorlagen
Bei STDIO startet der Host dein PHP-Skript als Kindprozess und spricht über dessen Ein- und Ausgabe mit ihm. Kein Port wird geöffnet.

Was das PHP-SDK mitbringt

Das SDK ist an kein Framework gebunden und deckt beide Seiten ab: Server und Clients, Tools, Ressourcen und Prompts, die Transporte STDIO und HTTP, Sessions und Autorisierung. Es spricht außerdem beide Generationen des Protokolls, den älteren Handshake, der mit initialize beginnt, und die zustandslose Revision vom 2026-07-28. Installiert wird es mit composer require mcp/sdk, dazu symfony/finder, wenn es deine Tools durch Scannen des Codes finden soll. Das Server-Beispiel aus der README ist kurz genug für einen Blick:

class Calculator
{
    /** Adds two numbers. */
    #[McpTool]
    public function add(int $a, int $b): int { return $a + $b; }
}

exit(Server::builder()
    ->setServerInfo('Calculator', '1.0.0')
    ->setDiscovery(__DIR__, ['.'], excludeDirs: ['vendor'])
    ->build()
    ->run(new StdioTransport()));

Ein Attribut macht eine Methode zum Tool, der Doc-Kommentar wird zu ihrer Beschreibung und die typisierten Parameter zu ihrer Eingabe. Eine Ressource funktioniert genauso, mit #[McpResource] und einer URI. Wichtiger als der Code ist aber ein Satz in der README: Bis zum ersten Major-Release gilt das SDK als experimentell. Pinne die Version und rechne mit Änderungen.

Weil es framework-unabhängig ist, läuft es in einer Laravel-Anwendung wie jedes andere Composer-Paket. Die README nennt darauf aufbauende Integrationen für Symfony, API Platform, Drupal und weitere. Prüfe, ob es eine Laravel-Integration gibt, bevor du den Klebecode selbst schreibst.

Wann ein Server das richtige Werkzeug ist, und wann nicht

Ein MCP-Server lohnt sich, wenn er dem Modell etwas gibt, an das es sonst nicht kommt: Live-Daten aus deiner Datenbank oder eine Aktion in deinem System, etwa den Status einer Bestellung abfragen oder ein Support-Ticket anlegen. Für statische Dokumentation passt er schlecht. Cristian Tabacitu, Maintainer von Backpack for Laravel, schrieb diese Woche, dass der MCP-Server, den sie für Abfragen ihrer Doku gebaut hatten, durchwachsene Ergebnisse brachte, weil der Agent selbst entscheiden muss, ihn aufzurufen, und das meistens nicht tut. Hat der Agent die Information schon oder kann er sie aus deinem Code lesen, bringt ein Server vor allem ein weiteres bewegliches Teil.

Jedes Tool-Argument ist nicht vertrauenswürdige Eingabe

Ein Tool ist eine Aktion, und die Argumente stammen von einem Modell, das alles gelesen hat, was man ihm vorgelegt hat. Behandle sie genau wie ein Formular, das ein Fremder abgeschickt hat. Das Folgende ist allgemeine Praxis, nichts, was das SDK dir abnimmt:

Vertrauensgrenze unsichere Eingabe Deine Regeln Das Modell wählt ein Tool Tool-Aufruf mit Argumenten Deine Validierung Typ, Bereich, Nutzer Deine Daten minimale Rechte Abgelehnt, geloggt
Typisierte Parameter prüfen die Form eines Arguments. Ob dieser Nutzer diesen Datensatz anfassen darf, kann nur dein eigener Code prüfen.

Validiere jedes Argument wie einen Request-Body. Gib jedem Tool die kleinste Berechtigung, die für seine Aufgabe reicht: eine Read-only-Datenbankverbindung für ein Abfrage-Tool, eine Tabelle statt des ganzen Schemas. Stell nie ein Tool bereit, das beliebiges SQL oder beliebige Shell-Befehle ausführt, die man ihm übergibt. Kläre, wer der Aufrufer ist, und autorisiere pro Nutzer, so wie deine Controller es tun. Und logge jeden Aufruf, damit du bei überraschendem Verhalten eines Tools sehen, welche Argumente es verlangt haben.

Ein int in der Methodensignatur sagt dir, dass das Argument eine Zahl ist. Es sagt dir nicht, dass diese Zahl der Person gehört, die fragt.

Wenn du es ausprobieren willst, fang mit einem einzigen Read-only-Tool über Daten an, die dein Assistent heute nicht sieht, betreib es über STDIO auf deinem eigenen Rechner und lies eine Woche lang jeden Aufruf im Log, bevor du ein Tool hinzufügst, das irgendetwas schreibt. Quelle: das offizielle MCP-PHP-SDK auf GitHub.

Notizen der Leser

  1. Noch keine Notizen. Die erste ist immer die mutigste.
Baust du etwas Ähnliches? Ich kann helfen. Schreib mir auf WhatsApp