Safari-MCP-Server für Webentwickler

 (webkit.org)
1 Punkte von GN⁺ 5 시간 전 | 2 Kommentare | Auf WhatsApp teilen
  • Der Safari-MCP-Server verbindet Coding-Agenten mit einem echten Safari-Fenster, damit sie während Webentwicklung und Debugging direkt prüfen können, was im Browser zu sehen ist
  • Agenten erhalten Zugriff auf DOM, Netzwerk-Requests, Screenshots und Konsolenausgaben und können so Rendering-Ergebnisse und User Experience nachvollziehen, die sich allein aus dem Code nur schwer erkennen lassen
  • Bei Aufgaben, bei denen browserspezifische Unterschiede wichtig sind – etwa Safari-Kompatibilität, Performance, Barrierefreiheit sowie die Prüfung von Formular- und Checkout-Zuständen – reduziert er wiederholtes Wechseln zwischen Fenstern und den Aufwand für ausführliche Prompt-Beschreibungen
  • Er bietet Tools für Tab-Steuerung, URL-Navigation, JavaScript-Ausführung, Abfrage von Netzwerk-Requests, Extraktion von Seiteninhalten, DOM-Interaktionen, Screenshots sowie Viewport- und Medien-Emulation
  • Der Server läuft ausschließlich auf der lokalen Maschine und führt selbst keine Netzwerkaufrufe aus; erfasste Seitendaten werden jedoch direkt an den vom Nutzer ausgeführten Agenten weitergegeben, daher sollten nur vertrauenswürdige Agenten verwendet werden

Rolle des Safari-MCP-Servers

  • In Safari Technology Preview 247 wurde der Safari-MCP-Server hinzugefügt
  • Es handelt sich um einen Model-Context-Protocol-Server für Webentwickler, der Agenten mit einem Safari-Browserfenster verbindet
  • Da Agenten prüfen können, wie Code tatsächlich im Browser gerendert wird, verringert sich die Lücke zwischen Codeanalyse und Kontrolle des Browserzustands
  • Jeder MCP-kompatible Client kann sich mit dem Safari-MCP-Server verbinden
  • Verbundene Agenten können den Zustand, den der Nutzer im Browser sieht, genauer nachbilden
    • DOM-Zugriff
    • Zugriff auf Netzwerk-Requests
    • Zugriff auf Screenshots
    • Zugriff auf Konsolenausgaben

Wie Debugging-Schleifen reduziert werden

  • Typisches Web-Debugging wiederholt den Ablauf: Problem im Browser ansehen, Konsole und Styles-Tab prüfen, dann zurück zum Code und Änderungen vornehmen
  • Auch mit Agenten muss man oft Screenshots erstellen und das Problem erklären; wenn die Korrektur nicht ausreicht, wechselt man erneut zwischen Browser, Prompt und Agent
  • Der Safari-MCP-Server lässt Agenten den Browserzustand direkt prüfen und reduziert so Fensterwechsel und den Aufwand für detaillierte Prompts
  • Nutzer müssen die Situation nicht mit einem perfekten Prompt beschreiben; der Agent kann auf Basis der in Safari verfügbaren Informationen mit den nächsten Schritten fortfahren

Wichtige Anwendungsfälle

  • Webentwicklung in Safari

    • Agenten können nicht nur den Code, sondern auch das tatsächliche Rendering-Ergebnis in Safari prüfen

  • Verbesserung der Safari-Kompatibilität

    • Wer nur in einem Browser testet, kann potenzielle Bugs in anderen Browsern übersehen
    • Agenten können die Website in Safari öffnen und computed styles, Layouts sowie Abweichungen vom erwarteten Verhalten prüfen

  • Performance-Analyse

    • Durch Auswerten von JavaScript auf der Seite lassen sich Performance-Kennzahlen wie Navigation Timing und Resource Load Time sichtbar machen
    • Wenn die bremsenden Teile einer Website gefunden sind, lässt sich der Änderungsbereich leichter eingrenzen

  • Prüfung der Barrierefreiheit

    • Häufige Accessibility-Probleme wie fehlende Labels, ungeeignete ARIA-Attribute oder geringer Kontrast lassen sich prüfen

  • Prüfung von Nutzerzuständen

    • Möglich sind unter anderem das Prüfen von Formularzuständen, das Abfragen von Elementen per Selector, das Prüfen bestimmter Interaktionen und die Anzeige verschiedener Zustände eines Checkout-Flows

Bereitgestellte Tools

  • browser_console_messages: Gibt die gepufferten Konsolen-Logs des aktuellen oder eines angegebenen Tabs zurück
  • browser_dialogs: Fragt die Liste der Browser-Dialoge ab und verarbeitet Antworten
    • Unterstützt accept, dismiss und Texteingabe in JavaScript-Prompts
  • create_tab, close_tab, switch_tab, list_tabs: Erstellt, schließt und wechselt Browser-Tabs und ruft die Tab-Liste ab
  • navigate_to_url: Navigiert zu einer URL und gibt den geladenen Seiteninhalt zurück
  • page_info: Prüft URL, title und loading state der aktuellen Seite
  • evaluate_javascript: Führt JavaScript-Code innerhalb der Seite aus und gibt das Ergebnis zurück
  • list_network_requests: Fragt eine Zusammenfassung der Netzwerk-Requests des aktuellen Tabs ab
    • Enthält URL, method, status und timing
  • get_network_request: Ruft Detailinformationen zu einem einzelnen Netzwerk-Request ab
    • Enthält headers, body und timing
  • get_page_content: Extrahiert Textinhalte der Seite in verschiedenen Formaten wie markdown, HTML oder JSON
  • page_interactions: Führt DOM-Interaktionen wie click, type, scroll, hover und keyPress nacheinander aus
  • screenshot: Erfasst die aktuelle Seite als PNG-Screenshot
  • set_emulated_media: Emuliert für Responsive-Design-Tests einen CSS media type wie print
  • set_viewport_size: Setzt die Größe des Browser-Viewports in CSS-Pixeln
  • wait_for_navigation: Wartet, bis das Laden der aktuellen Seite abgeschlossen ist, und gibt die finale URL und den title zurück

Erste Schritte

  • Zunächst muss Safari Technology Preview installiert werden
  • Nach der Installation müssen in den Safari-Einstellungen folgende Optionen aktiviert werden
    • Safari Settings > Advanced > Show features for web developers
    • Safari Settings > Developer > Enable remote automation and external agents
  • Wer Claude verwendet, kann im Terminal folgenden Befehl nutzen
claude mcp add safari-mcp-stp -- "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver" --mcp
  • Wer Codex verwendet, kann folgenden Befehl nutzen
codex mcp add safari-mcp-stp -- "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver" --mcp
  • Andere Agenten können die folgende Konfiguration in mcp.json oder config.json eintragen
"safari-mcp-stp": {  
  "command": "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver",  
  "args": ["--mcp"]  
}
  • Im obigen Beispiel lautet der Servername safari-mcp-stp, es kann aber ein beliebiger Name wie safari verwendet werden

Prompts und Agentenverhalten

  • Nach der Installation kann man mit einfachen Prompts wie den folgenden beginnen
Find bugs on my site in Safari  

How accessible is my site in Safari?  

See how my website performs in Safari
  • Je nach Agent unterscheidet sich das Verhalten etwas, er kann den Safari-MCP-Server aber selbstständig verwenden, auch ohne explizite Aufforderung dazu
  • In einem Beispielablauf fragt der Nutzer nach einem Bug auf der Flight-Page in Safari; der Agent findet zwei Bugs und prüft zusätzlich Punkte, die für Safari-Nutzer problematisch sein könnten
  • Schon mit der ersten Anfrage kann der Agent mithilfe des Safari-MCP-Servers weitere Prüfungen und die Problemerkennung fortsetzen

Lokale Ausführung und Datenverarbeitung

  • Der Safari-MCP-Server läuft vollständig auf der lokalen Maschine
  • Er führt selbst keine Netzwerkaufrufe aus
  • Er greift nicht auf persönliche Informationen in Safari zu
    • AutoFill
    • Sonstige Browseraktivitäten
  • Wenn Seiteninhalte, Screenshots oder Konsolen-Logs erfasst werden, werden diese Daten nicht an Apple, sondern direkt an den vom Nutzer ausgeführten Agenten weitergegeben
  • Wie die Daten anschließend verarbeitet werden, hängt vom verwendeten Agenten und Modell ab
  • Wie bei anderen Agenten, denen Browserzugriff gewährt wird, sollten nur vertrauenswürdige Agenten verwendet werden

Von WebKit erwartete Nutzung

  • Webentwicklung kann sowohl mit als auch ohne AI erfolgen
  • Wenn AI Teil des Entwicklungsablaufs ist, kann der Safari-MCP-Server dabei helfen, die Produktivität zu steigern
  • Ziel ist es, Agenten dabei zu unterstützen, Darstellung und Verhalten im Safari-Browser zu verstehen und so Safari-Tests und Debugging zu erleichtern
  • Bei Problemen kann ein Issue über den WebKit bug report eingereicht werden

Verwandte Beiträge

2 Kommentare

 
shakespeares 1 시간 전

Safari MCP also … das weckt ganz neue Gefühle, haha
 
GN⁺ 5 시간 전
Meinungen auf Hacker News

  • Seit November 2025 nutze ich den offiziellen MCP DevTools Server von Chrome
    https://github.com/ChromeDevTools/chrome-devtools-mcp
    Davor habe ich den Chrome WebDriver verwendet, aber MCP war schneller und hatte mehr Funktionen
    Um zu prüfen, ob es auch in Firefox funktioniert, habe ich das LLM angewiesen, die Seite mit dem offiziellen MCP von Firefox zu testen
    https://github.com/mozilla/firefox-devtools-mcp
    Jetzt werde ich auch Safari in die Kompatibilitätstests aufnehmen

    • Ich frage mich, ob es einen Unterschied gibt zwischen diesen Lösungen und Playwright MCP mit Chrome-/Firefox-Konfiguration
    • Manchmal ist es bei mir umgekehrt: Statt dass das LLM den Browser steuert, möchte ich, dass die Aktionen, die ich manuell im Browser ausführe, für das LLM sichtbar sind
      Um diesen Anwendungsfall abzudecken, habe ich MCP gebaut

  • Federico Viticci hat bei MacStories, auf Mastodon und in der neuesten Folge des Connected-Podcasts etwas ausführlicher behandelt, was das bedeutet, und es ist auch für Laien zugänglicher
    Es lohnt sich auch, die Links im Original anzusehen
    https://www.macstories.net/linked/safaris-new-mcp-server-is-...
    https://mastodon.macstories.net/@viticci/116847167023618099
    https://relay.fm/connected/610

  • Ich freue mich besonders darauf, nicht nur fürs Testen, sondern auch für alltägliche Aufgaben
    Wenn ein Agent in dem Browser, in dem ich eingeloggt bin, ganz natürlich Browser-Automatisierung für mich übernehmen kann, dürfte sich die Übergabe zwischen mir und dem Agenten deutlich reibungsloser anfühlen
    Auch deshalb, weil ich Safari als Hauptbrowser nutze, da Chrome viel Akku frisst

    • Ich baue Hyperia, und dort kann ein Agent ein auf Electron basierendes Web-Panel vollständig steuern und ziemlich drastische Aufgaben ausführen: https://github.com/deepbluedynamics/hyperia
      Außerdem nutze ich einen Agent-Container-Orchestrator; es gibt ein MCP-Tool, das Ports von Containern freigibt, sodass Arbeitsergebnisse im Web-Panel angezeigt werden können: https://github.com/DeepBlueDynamics/nemesis8
      Heute werde ich n8 um eine Safari-MCP-Anbindung erweitern, und heute Nacht soll ein neues Release mit weiteren Funktionen erscheinen
    • Wenn ich die Formulierung „greift nicht auf persönliche Informationen in Safari zu, etwa Autofill oder andere Browseraktivitäten“ lese, klingt das für mich so, als sei die Instanz, mit der der Agent interagiert, nicht eingeloggt
    • Der Teil mit „die Übergabe zwischen mir und dem Agenten ist reibungsloser“ macht mir Angst
      Denn aus Sicht des Dienstes auf der anderen Seite des Browsers gibt es keine Möglichkeit zu erkennen, wer was tut
      Ich weiß nicht, wie man den Agenten einschränkt oder wie man nachverfolgt, was ich getan habe und was der Agent getan hat
      Ich frage mich, ob ich etwas übersehe oder einfach nicht mehr zeitgemäß denke

  • Persönlich empfehle ich Playwright-CLI: https://github.com/microsoft/playwright-cli
    Es lief deutlich schneller als die MCP-Server, die ich ausprobiert habe

    • Wenn man eine dauerhafte Browser-Session braucht, gibt es auch spel (https://github.com/Blockether/spel)
      Es unterstützt über einen Daemon die Engines Chromium, Firefox und WebKit
    • Playwright ist hervorragend für End-to-End-Tests und passt auch gut zu Electron
      Allerdings verwende ich Playwright MCP
    • All das fühlte sich für mich schwergewichtig an
      Ein vollständiger Browser, Debug-Protokoll, bei jedem Lesevorgang ein DOM-Dump – wichtiger als die Frage MCP oder CLI ist, was darunter liegt
      Deshalb habe ich ein kleines Rust-Binary gebaut, das direkt die System-WebView ansteuert und statt des DOMs Status-Tokens und Deltas zurückgibt
      Selbst beim Laden der HN-Startseite kostet es den Agenten nur etwa 50 Tokens
      Es unterstützt sowohl MCP als auch CLI, also kann der Agent wählen, was er bevorzugt
      https://github.com/frane/vibesurfer

  • Der von Apple bereitgestellte safaridriver existiert schon seit einigen Jahren
    Er verwendet WebDriver W3C und kann zur Interaktion mit Safari-Instanzen genutzt werden

  • Ich weiß nicht, ob Apple sich wirklich um Webentwickler kümmert.
    Wie soll man in Safari testen, wenn man kein Apple-Gerät hat?
    Wäre es für Apple wirklich so schwierig, eine minimale virtuelle Maschine zu bauen, in der nur Safari steckt?

    • Zu fragen, wie man Safari ohne Apple-Gerät testen soll, ist ungefähr so, als würde man fragen, wie man PlayStation-Spiele ohne PlayStation testet.
      Es ist dasselbe Problem wie: Wie testet man Hardware-Firmware ohne Hardware, oder wie führt man ein Programm ohne die nötige Hardware aus, wenn es keinen Emulator oder Simulator gibt?
      Wenn etwas nur auf bestimmter Hardware läuft und es keine Virtualisierung oder Emulation gibt, kann man es außerhalb dieser Hardware nicht testen — und das ist seit den Anfängen der Computertechnik seit Jahrzehnten so.
      Apples Entscheidungen werden oft eher strategisch getroffen als danach, was schwierig oder einfach ist, und es ist ziemlich klar, dass sie einen Walled Garden bauen.
      Wenn es dir nicht gefällt, musst du dort eben nicht mitspielen, so wie der Rest von uns.
    • Auch wenn Chrome dominiert, testet man Chromium, weil man andere Browser wie Edge nicht übersehen will.
      Genauso kann man, wenn auch nicht perfekt, WebKit testen, und wenn man will auch unter Linux oder Windows:
      https://orionbrowser.com/platforms/linux
      Ich glaube nicht, dass Apple ins Geschäft mit Safari-VMs einsteigen wird, aber wenn man eine macOS-VM braucht, kann man sich Cloud-Anbieter ansehen: https://aws.amazon.com/ec2/instance-types/mac/
      Viele davon haben Software-Test-Orchestrierung bereits angebunden.
    • Da Apple dieses neue Tool gerade veröffentlicht hat, kann man wohl sagen, dass sie sich um Webentwickler kümmern.
    • Das ist wie damals, als man IE unter Linux oder OS X getestet hat.

  • In letzter Zeit lasse ich Agenten Chrome starten und direkt über CDP kommunizieren, und das funktioniert ziemlich gut.

    • Das sollte ich auch mal ausprobieren.
      Ich bin gespannt, wie es im Vergleich zu Playwright ist.
      Aus Sicht der Webentwicklung scheint der Vorteil von Playwright zu sein, dass es über mehrere Browser hinweg nutzbar ist.
      Wenn browserspezifische Tools schneller oder token-effizienter sind, wäre das für Aufgabenautomatisierung und Claws wohl die bessere Wahl.
    • Stimmt. Dieser Ansatz funktioniert deutlich besser als der MCP-Weg und ist schneller.

  • „Es gibt viele Möglichkeiten, Web zu bauen, mit oder ohne KI. Wenn KI Teil Ihres Workflows ist, denke ich, dass dieses Tool Ihnen helfen kann, produktiver zu sein. Wenn nicht, ist das auch in Ordnung.“
    Seltsam, so etwas im Jahr 2026 zu sagen.
    Denn wir leben in einer Zeit, in der man von manchen als Anfänger behandelt wird, wenn man Code selbst schreibt und nicht alles an Agenten delegiert.

    • Vor zwei Jahren galt das Gegenteil noch als völlig absurde Aussage.
      Schön, dass Leute, die KI nutzen, das inzwischen nicht mehr verheimlichen müssen.
    • Ich weiß nicht, welcher Teil daran seltsam sein soll.
      Ist es seltsam, dass man so einen Disclaimer einfügen musste, um das fanatische Anti-KI-Lager zu beschwichtigen?
      Das ist eindeutig ein Tool für KI-gestützte Entwicklung, und dass man einen Satz im Stil von „auch an alle, die keine KI nutzen, unser Mitgefühl“ anhängen musste, ist eher wirklich seltsam.
      Nur eben auf eine andere Weise seltsam, als du es vermutlich meinst.

  • Ein MCP für Browser-Automatisierung ist interessant, weil Safaris WebKit-Engine für die meisten KI-Agenten schwer zugänglich ist.
    Playwright und Puppeteer sind Chromium-zentriert; ein MCP-Server für Safari könnte daher eine echte Lücke im Cross-Browser-Testing von Agenten-Workflows schließen.