Ich lege meine Karten auf den Tisch, bevor der Kaffee kalt wird: Der beängstigende Schlagzeilenpunkt in laravel/mcp 1.0, der Wegfall serverseitiger Sessions, ist für uns der einfachste Teil des Upgrades. Der Teil, der darüber entscheidet, ob Agents mit deiner App wirklich Nützliches anstellen, ist der Tool-Katalog, und der kommt mit einem Default, den du ignorieren darfst. Genau das zu tun, halte ich für den eigentlichen Fehler, der in diesem Release lauert.

Fangen wir mit den Sessions an, denn da sitzt die Angst. Das Paket spricht jetzt die MCP-Revision 2026-07-28, und in dieser Revision gibt es keine Unterhaltung mehr, die sich der Server zwischen zwei Aufrufen merkt. $request->sessionId() und $request->setSessionId() sind weg, SessionInitialized ebenso. Wenn du einen teuren Lookup oder eine laufende Zählung von Agent-Schritten an einer Session-ID abgelegt hast, kompiliert dieser Code in deinem Kopf nicht mehr, sobald du das Changelog liest. Geschenkt. Jetzt überleg mal, was PHP schon tut, lange bevor die meisten von uns ihr erstes foreach geschrieben haben: Jeder Request bootet, erledigt seinen Job und vergisst alles. Auf dieser Amnesie haben wir ganze Karrieren gebaut. Queues, Redis, eine Correlation-ID im Payload, eine Tabellenzeile mit einem Schlüssel, den dir der Aufrufer zurückreicht. Dieser Werkzeugkasten liegt längst in deinem vendor-Ordner.

Für einen Laravel-Laden sieht die Migration in der Praxis also so aus: Du durchsuchst das app-Verzeichnis nach den entfernten Methoden, und jeder Treffer wird zu einer kleinen Designfrage. Welche Kennung muss mir der Agent schicken, damit ich meine eigenen Notizen wiederfinde? Meistens ist die Antwort eine Job-ID oder eine Report-ID, die du ohnehin schon erzeugst. Ich habe Teams in anderen Ökosystemen dabei zugesehen, wie sie echten Aufwand in Sticky Routing für ihre langlebigen Prozesse gesteckt haben; die Go-Leute greifen, das muss man ihnen lassen, auch früh zu expliziten IDs, und es ist schön zu sehen, dass sich das Protokoll auf den Ansatz einigt, dem beide Lager schon vertraut haben. Deinem Load Balancer ist es künftig egal, welche Kiste antwortet. Das ist ein Geschenk.

Ältere Clients fallen auch nicht plötzlich hinten runter. Das Release erkennt weiterhin die Revisionen 2025-06-18 und 2025-11-25 für Clients, die auf dem alten Weg reinkommen, und das zählt, wenn Agents, die nicht dir gehören, auf deinen Server zeigen. Teste diesen Pfad separat. Das ist genau die Sorte Kompatibilitätscode, die am Launch-Tag funktioniert und bis Weihnachten vergammelt, wenn nichts ihn ausführt.

Jetzt zu dem Teil, über den du wirklich schlecht schlafen solltest. Mit 1.0 kann ein Agent Tools über search_tools und execute_tools finden, statt vorab dein komplettes Inventar zu bekommen. Stell dir die typische interne Admin-App vor, zu der ich gerufen werde: gut dreißig Tools, die Hälfte heißt irgendeine Variante von GetOrder, FindOrder, OrderLookup, jedes mit einem Absatz Beschreibung und einem fetten JSON-Schema. Jede Verbindung bezahlt das alles mit Kontext, bevor das Modell auch nur ein einziges Token nützlicher Arbeit geschrieben hat, und dann muss es aus einer Reihe fast identischer Zwillinge das richtige herauspicken. Es greift öfter daneben, als dir lieb ist, und am Ende gibst du dem Modell die Schuld für eine Speisekarte, die du selbst entworfen hast.

Der Statamic-MCP-Server hat die Entscheidung getroffen, die ich gern als Normalfall sehen würde: drei Tools sichtbar beim Verbinden, die restlichen acht über die Suche erreichbar. Das ist eine Produktentscheidung, von derselben Art wie die Frage, was in die Navigationsleiste kommt und was in den Einstellungen wohnt. Irgendwer muss sie verantworten. In den meisten Teams, die ich kenne, wird das niemand tun, weil das alte Verhalten weiter funktioniert und kein Test rot wird, wenn ein Agent ein Drittel seines Kontexts damit verbrennt, Beschreibungen von Tools zu lesen, die er nie aufruft. Häng die neuen Cache-Hinweise an das statische Zeug, also Referenztabellen und Schema-Beschreibungen, und du sparst obendrein wiederholte Round Trips.

Kurz zu Auth, damit du nicht überrumpelt wirst: PKCE ist jetzt Pflicht, und wenn ein Authorization Server eines Drittanbieters code_challenge_methods_supported nicht in seinen Metadaten ausweist, wirft redirect() eine Exception, statt einfach weiterzumachen. Dynamic Client Registration ist zugunsten von Client ID Metadata Documents deprecated. Deprecated heißt aber: Es funktioniert heute noch. Setz den Umstieg also auf deine Roadmap und erledige ihn an einem langweiligen Dienstag, nicht in der Woche, in der die Entfernung kommt.

Und hier möchte ich von dir hören, denn ich habe eine starke Meinung und dünne Daten. Wenn du deine Tools aufteilst in das, was ein Agent beim Verbinden sieht, und das, wonach er suchen muss: Nach welcher Regel gehst du vor? Am häufigsten aufgerufen, am gefährlichsten, am mehrdeutigsten, oder etwas, das an Benutzerrollen hängt? Erzähl mir, wie du diese Grenze in einer echten App gezogen hast und ob der Agent dadurch besser wurde oder nur anders.