Safari MCP Server สำหรับนักพัฒนาเว็บ

 (webkit.org)
1 คะแนน โดย GN⁺ 5 시간 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Safari MCP Server เชื่อมต่อ coding agent เข้ากับหน้าต่าง Safari จริง ทำให้ตรวจสอบสถานะที่เห็นในเบราว์เซอร์ได้โดยตรงระหว่างการพัฒนาและดีบักเว็บ
  • Agent สามารถเข้าถึง DOM, คำขอเครือข่าย, สกรีนช็อต และเอาต์พุตคอนโซล เพื่อตรวจสอบผลลัพธ์การเรนเดอร์และประสบการณ์ผู้ใช้ที่ยากจะรู้ได้จากโค้ดเพียงอย่างเดียว
  • ช่วยลดการสลับหน้าต่างซ้ำ ๆ และภาระในการอธิบายผ่านพรอมป์ต์ สำหรับงานที่ความแตกต่างระหว่างเบราว์เซอร์มีความสำคัญ เช่น ความเข้ากันได้กับ Safari, ประสิทธิภาพ, การเข้าถึง, การตรวจสอบสถานะฟอร์มและ checkout
  • มีเครื่องมือสำหรับควบคุมแท็บ, ไปยัง URL, รัน JavaScript, ดูคำขอเครือข่าย, ดึงเนื้อหาหน้า, โต้ตอบกับ DOM, ถ่ายสกรีนช็อต, และจำลอง viewport/สื่อ
  • เซิร์ฟเวอร์ทำงานเฉพาะบน เครื่องภายใน และไม่เรียกเครือข่ายเอง แต่ข้อมูลหน้าที่ถูกจับไว้จะถูกส่งตรงไปยัง agent ที่ผู้ใช้กำลังรันอยู่ จึงจำเป็นต้องใช้ agent ที่เชื่อถือได้

บทบาทของ Safari MCP Server

  • มีการเพิ่ม Safari MCP Server ใน Safari Technology Preview 247
  • เป็น Model Context Protocol server สำหรับนักพัฒนาเว็บ โดยเชื่อมต่อ agent เข้ากับหน้าต่างเบราว์เซอร์ Safari
  • Agent สามารถตรวจสอบได้ว่าโค้ดถูกเรนเดอร์จริงในเบราว์เซอร์อย่างไร จึงช่วยลดช่องว่างระหว่างการวิเคราะห์โค้ดกับการตรวจสอบสถานะเบราว์เซอร์
  • ไคลเอนต์ที่รองรับ MCP สามารถเชื่อมต่อกับ Safari MCP Server ได้
  • Agent ที่เชื่อมต่อแล้วสามารถจำลองสถานะที่ผู้ใช้เห็นในเบราว์เซอร์ได้ใกล้เคียงขึ้น
    • เข้าถึง DOM
    • เข้าถึงคำขอเครือข่าย
    • เข้าถึงสกรีนช็อต
    • เข้าถึงเอาต์พุตคอนโซล

วิธีลดรอบการดีบัก

  • การดีบักเว็บโดยทั่วไปมักเป็นกระบวนการซ้ำ ๆ คือดูปัญหาในเบราว์เซอร์ ตรวจสอบคอนโซลและแท็บ styles แล้วกลับไปแก้โค้ด
  • แม้จะใช้ agent ก็ยังต้องถ่ายสกรีนช็อต อธิบายปัญหา และถ้าแก้ไขยังไม่พอ ก็ต้องสลับไปมาระหว่างเบราว์เซอร์ พรอมป์ต์ และ agent อีกครั้ง
  • Safari MCP Server ทำให้ agent ตรวจสอบสถานะเบราว์เซอร์ได้โดยตรง จึงลดภาระในการสลับหน้าต่างและการเขียนพรอมป์ต์อย่างละเอียด
  • แม้ผู้ใช้จะไม่ได้อธิบายสถานการณ์ด้วยพรอมป์ต์ที่สมบูรณ์แบบ agent ก็สามารถทำงานต่อจากข้อมูลที่ตรวจสอบได้ใน Safari

กรณีใช้งานหลัก

  • การพัฒนาเว็บใน Safari

    • Agent สามารถตรวจสอบได้ไม่ใช่แค่โค้ด แต่รวมถึงผลลัพธ์การเรนเดอร์จริงใน Safari

  • การปรับปรุงความเข้ากันได้กับ Safari

    • หากทดสอบแค่ในเบราว์เซอร์เดียว อาจพลาดบั๊กที่อาจเกิดขึ้นในเบราว์เซอร์อื่น
    • Agent สามารถเปิดไซต์ใน Safari แล้วตรวจสอบ computed style, layout และความแตกต่างจากพฤติกรรมที่คาดหวัง

  • การวิเคราะห์ประสิทธิภาพ

    • สามารถประเมิน JavaScript บนหน้าเพื่อแสดงตัวชี้วัดประสิทธิภาพ เช่น navigation timing และ resource load time
    • เมื่อพบส่วนที่ทำให้ไซต์ช้า จะช่วยจำกัดขอบเขตสิ่งที่ต้องแก้ไขได้ง่ายขึ้น

  • การตรวจสอบการเข้าถึง

    • สามารถตรวจสอบปัญหาการเข้าถึงทั่วไป เช่น label ที่ขาดหาย, คุณสมบัติ ARIA ที่ไม่เหมาะสม, contrast ต่ำ

  • การตรวจสอบสถานะผู้ใช้

    • สามารถตรวจสอบสถานะฟอร์ม, ค้นหาองค์ประกอบด้วย selector, ตรวจสอบ interaction เฉพาะ และแสดงหลายสถานะใน flow การ checkout ได้

เครื่องมือที่มีให้

  • browser_console_messages: ส่งคืน log คอนโซลที่ถูกบัฟเฟอร์ไว้ของแท็บปัจจุบันหรือแท็บที่ระบุ
  • browser_dialogs: ดูรายการ dialog ของเบราว์เซอร์และจัดการการตอบกลับ
    • รองรับ accept, dismiss และการป้อนข้อความสำหรับ JavaScript prompt
  • create_tab, close_tab, switch_tab, list_tabs: สร้าง ปิด สลับ และดูรายการแท็บเบราว์เซอร์
  • navigate_to_url: ไปยัง URL และส่งคืนเนื้อหาหน้าเว็บที่โหลดแล้ว
  • page_info: ตรวจสอบ URL, title และ loading state ของหน้าปัจจุบัน
  • evaluate_javascript: รัน โค้ด JavaScript ภายในหน้าและส่งคืนผลลัพธ์
  • list_network_requests: ดูสรุปคำขอเครือข่ายของแท็บปัจจุบัน
    • รวม URL, method, status, timing
  • get_network_request: ดูรายละเอียดของคำขอเครือข่ายรายการเดียว
    • รวม headers, body, timing
  • get_page_content: ดึงเนื้อหาข้อความของหน้าในหลายรูปแบบ เช่น markdown, HTML, JSON
  • page_interactions: ทำ interaction กับ DOM ตามลำดับ เช่น click, type, scroll, hover, keyPress
  • screenshot: จับภาพหน้าปัจจุบันเป็นสกรีนช็อต PNG
  • set_emulated_media: จำลอง CSS media type เช่น print สำหรับการทดสอบ responsive design
  • set_viewport_size: ตั้งค่าขนาด viewport ของเบราว์เซอร์เป็นหน่วย CSS pixel
  • wait_for_navigation: รอให้หน้าปัจจุบันโหลดเสร็จ แล้วส่งคืน URL และ title สุดท้าย

วิธีเริ่มต้น

  • ก่อนอื่นต้องติดตั้ง Safari Technology Preview
  • หลังติดตั้ง ต้องเปิดรายการต่อไปนี้ในการตั้งค่า Safari
    • Safari Settings > Advanced > Show features for web developers
    • Safari Settings > Developer > Enable remote automation and external agents
  • หากใช้ Claude สามารถใช้คำสั่งต่อไปนี้ในเทอร์มินัล
claude mcp add safari-mcp-stp -- "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver" --mcp
  • หากใช้ Codex สามารถใช้คำสั่งต่อไปนี้
codex mcp add safari-mcp-stp -- "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver" --mcp
  • สำหรับ agent อื่น สามารถใส่การตั้งค่าต่อไปนี้ใน mcp.json หรือ config.json
"safari-mcp-stp": {  
  "command": "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver",  
  "args": ["--mcp"]  
}
  • ตัวอย่างข้างต้นใช้ชื่อเซิร์ฟเวอร์เป็น safari-mcp-stp แต่สามารถใช้ชื่อที่ต้องการได้ เช่น safari

พรอมป์ต์และพฤติกรรมของ agent

  • หลังติดตั้งแล้ว สามารถเริ่มด้วยพรอมป์ต์ง่าย ๆ เช่นต่อไปนี้
Find bugs on my site in Safari  

How accessible is my site in Safari?  

See how my website performs in Safari
  • Agent แต่ละตัวมีวิธีทำงานแตกต่างกันเล็กน้อย แต่สามารถเลือกใช้เองได้แม้ไม่ได้บอกอย่างชัดเจนให้ใช้ Safari MCP Server
  • ใน flow ตัวอย่าง เมื่อผู้ใช้ถามถึงบั๊กของหน้า flight ใน Safari agent จะพบบั๊กสองรายการ และตรวจสอบเพิ่มเติมว่าสิ่งใดอาจก่อปัญหาให้ผู้ใช้ Safari
  • แค่คำขอเริ่มต้นก็สามารถอาศัยความช่วยเหลือจาก Safari MCP Server เพื่อดำเนินการตรวจสอบและระบุปัญหาต่อไปได้

การรันภายในเครื่องและการจัดการข้อมูล

  • Safari MCP Server ทำงานทั้งหมดบน เครื่องภายใน
  • ไม่เรียกเครือข่ายด้วยตัวเอง
  • ไม่เข้าถึงข้อมูลส่วนตัวของ Safari
    • AutoFill
    • กิจกรรมอื่น ๆ ในเบราว์เซอร์
  • เมื่อจับเนื้อหาหน้า, สกรีนช็อต หรือ log คอนโซล ข้อมูลดังกล่าวจะถูกส่งตรงไปยัง agent ที่ผู้ใช้กำลังรันอยู่ ไม่ใช่ Apple
  • หลังจากนั้น วิธีจัดการข้อมูลจะขึ้นอยู่กับ agent และโมเดลที่ใช้
  • เช่นเดียวกับ agent อื่นที่ได้รับสิทธิ์เข้าถึงเบราว์เซอร์ ควรใช้เฉพาะ agent ที่เชื่อถือเท่านั้น

การใช้งานที่ WebKit คาดหวัง

  • การพัฒนาเว็บมีทั้งวิธีที่ใช้ AI และไม่ใช้ AI
  • หาก AI เป็นส่วนหนึ่งของ workflow การพัฒนา Safari MCP Server อาจช่วยเพิ่มประสิทธิภาพการทำงานได้
  • เป้าหมายคือช่วยให้ agent เข้าใจภาพหน้าจอและพฤติกรรมในเบราว์เซอร์ Safari ทำให้การทดสอบและดีบัก Safari ง่ายขึ้น
  • หากมีปัญหา สามารถส่ง issue ผ่าน WebKit bug report ได้

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
shakespeares 1 시간 전

Safari MCP เหรอเนี่ย.. รู้สึกคิดถึงขึ้นมาเลยครับ haha
 
GN⁺ 5 시간 전
ความคิดเห็นจาก Hacker News

  • ตั้งแต่เดือนพฤศจิกายน 2025 ผมใช้ MCP DevTools server อย่างเป็นทางการของ Chrome อยู่
    https://github.com/ChromeDevTools/chrome-devtools-mcp
    ก่อนหน้านั้นใช้ Chrome WebDriver แต่ MCP เร็วกว่าและมีฟีเจอร์มากกว่า
    ผมสั่งให้ LLM ทดสอบหน้าเว็บด้วย MCP ทางการของ Firefox เพื่อดูว่าทำงานบน Firefox ได้หรือไม่
    https://github.com/mozilla/firefox-devtools-mcp
    ตอนนี้ก็กำลังจะเพิ่ม Safari เข้าไปในการทดสอบความเข้ากันได้ด้วย

    • อยากรู้ว่าพวกนี้ต่างจากการใช้ Playwright MCP กับการตั้งค่า Chrome/Firefox อย่างไรบ้าง
    • บางครั้งก็กลับกัน คือแทนที่จะให้ LLM ควบคุมเบราว์เซอร์ ผมอยากให้สิ่งที่ผมทำเองด้วยมือในเบราว์เซอร์ปรากฏให้ LLM เห็น
      ผมสร้าง MCP ขึ้นมาเพื่อครอบคลุมกรณีใช้งานนั้น

  • Federico Viticci พูดถึงความหมายของเรื่องนี้ละเอียดขึ้นเล็กน้อยใน MacStories, Mastodon และตอนล่าสุดของพอดแคสต์ Connected ซึ่งคนทั่วไปเข้าถึงได้ง่ายกว่าด้วย
    ลิงก์ในต้นฉบับก็ควรดูด้วย
    https://www.macstories.net/linked/safaris-new-mcp-server-is-...
    https://mastodon.macstories.net/@viticci/116847167023618099
    https://relay.fm/connected/610

  • ผมคาดหวังกับมันเป็นพิเศษ ไม่ใช่แค่สำหรับการทดสอบ แต่รวมถึงงานประจำวันด้วย
    ถ้าเอเจนต์สามารถทำ browser automation แทนผมได้อย่างเป็นธรรมชาติในเบราว์เซอร์ที่ผมล็อกอินไว้อยู่ การส่งต่องานระหว่างผมกับเอเจนต์น่าจะลื่นไหลขึ้นมาก
    อีกเหตุผลคือผมใช้ Safari เป็นเบราว์เซอร์หลัก เพราะ Chrome กินแบตเตอรี่มาก

    • ผมกำลังสร้าง Hyperia อยู่ โดย web panel ที่ใช้ Electron สามารถถูกเอเจนต์ควบคุมได้เต็มที่และทำงานค่อนข้างแรง ๆ ได้: https://github.com/deepbluedynamics/hyperia
      ผมยังใช้ agent container orchestrator ด้วย และมีเครื่องมือ MCP สำหรับเปิดเผยพอร์ตของคอนเทนเนอร์ ทำให้แสดงผลลัพธ์งานใน web panel ได้: https://github.com/DeepBlueDynamics/nemesis8
      วันนี้ผมจะเพิ่มการเชื่อมต่อ Safari MCP เข้าไปใน n8 และคืนนี้จะมีรีลีสใหม่ที่มีฟีเจอร์เพิ่มขึ้น
    • ถ้าดูข้อความที่ว่า “ไม่เข้าถึงข้อมูลส่วนตัวของ Safari เช่น AutoFill หรือกิจกรรมอื่น ๆ ในเบราว์เซอร์” ผมอ่านได้ว่าอินสแตนซ์ที่เอเจนต์โต้ตอบด้วยไม่ได้ล็อกอินอยู่
    • ส่วนที่ว่า “การส่งต่องานระหว่างผมกับเอเจนต์ลื่นไหลขึ้น” ฟังดูน่ากลัว
      เพราะจากมุมมองของบริการที่อยู่อีกฝั่งของเบราว์เซอร์ ไม่มีทางรู้ได้ว่าใครกำลังทำอะไร
      ผมไม่รู้ว่าจะจำกัดเอเจนต์อย่างไร หรือจะติดตามได้อย่างไรว่าส่วนไหนผมทำเอง ส่วนไหนเอเจนต์ทำ
      เลยสงสัยว่าผมพลาดอะไรไป หรือแค่ตามยุคไม่ทันกันแน่

  • โดยส่วนตัวผมแนะนำ Playwright-CLI: https://github.com/microsoft/playwright-cli
    มันทำงานได้เร็วกว่าพวก MCP server ที่ผมเคยลองมาก

    • ถ้าต้องการเซสชันเบราว์เซอร์แบบต่อเนื่อง ก็มี spel(https://github.com/Blockether/spel) ด้วย
      รองรับเอนจิน Chromium, Firefox, WebKit ผ่าน daemon
    • Playwright ยอดเยี่ยมสำหรับ end-to-end testing และเข้ากับ Electron ได้ดี
      แต่ผมใช้ Playwright MCP อยู่
    • ทั้งหมดนี้สำหรับผมรู้สึกหนักเกินไป
      มีทั้งเบราว์เซอร์เต็มตัว, debug protocol และ DOM dump ทุกครั้งที่อ่าน ซึ่งสิ่งที่อยู่ข้างใต้นั้นสำคัญกว่าว่าจะเป็น MCP หรือ CLI
      ผมเลยทำ Rust binary เล็ก ๆ ที่ขับ system webview โดยตรง และส่งคืน state token กับ delta แทน DOM
      โหลดหน้าแรกของ HN ก็ใช้กับเอเจนต์แค่ประมาณ 50 token เท่านั้น
      รองรับทั้ง MCP และ CLI ดังนั้นเอเจนต์เลือกฝั่งที่ชอบได้
      https://github.com/frane/vibesurfer

  • safaridriver ที่ Apple ให้มามีมาหลายปีแล้ว
    ใช้ WebDriver W3C และสามารถใช้โต้ตอบกับอินสแตนซ์ของ Safari ได้

  • ไม่แน่ใจว่า Apple ใส่ใจนักพัฒนาเว็บจริง ๆ หรือเปล่า
    ถ้าไม่มีอุปกรณ์ Apple แล้วจะทดสอบบน Safari ได้อย่างไร
    มันยากขนาดนั้นเลยหรือที่ Apple จะทำเครื่องเสมือนขั้นต่ำที่มีแค่ Safari อยู่ข้างใน

    • คำถามที่ว่าไม่มีอุปกรณ์ Apple แล้วจะทดสอบ Safari ได้อย่างไร ก็คล้ายกับถามว่าไม่มี PlayStation แล้วจะทดสอบเกม PlayStation ได้อย่างไร
      เป็นปัญหาเดียวกับว่าไม่มีฮาร์ดแวร์แล้วจะทดสอบเฟิร์มแวร์ของฮาร์ดแวร์ได้อย่างไร หรือไม่มีอีมูเลเตอร์/ซิมูเลเตอร์แล้วจะรันโปรแกรมโดยไม่มีฮาร์ดแวร์ที่จำเป็นได้อย่างไร
      ถ้ามันรันได้เฉพาะบนฮาร์ดแวร์บางชนิด และไม่มี virtualization หรือ emulation ก็ทดสอบนอกฮาร์ดแวร์นั้นไม่ได้ เรื่องนี้เป็นแบบนั้นมาตลอดหลายสิบปีตั้งแต่ยุคแรก ๆ ของคอมพิวเตอร์
      การตัดสินใจของ Apple มักถูกกำหนดด้วยกลยุทธ์มากกว่าความยากหรือง่าย และค่อนข้างชัดเจนว่าพวกเขากำลังสร้าง สวนที่มีกำแพงล้อมรอบ อยู่
      ถ้าไม่ชอบ ก็แค่ไม่ต้องไปเล่นในนั้นเหมือนคนอื่น ๆ
    • แม้ในสถานการณ์ที่ Chrome ครองตลาด เราก็ยังทดสอบ Chromium เพราะไม่อยากพลาดเบราว์เซอร์อื่น ๆ อย่าง Edge
      ในทำนองเดียวกัน แม้จะไม่สมบูรณ์แบบ แต่ก็ทดสอบ WebKit ได้ และถ้าต้องการก็ทำบน Linux หรือ Windows ได้ด้วย:
      https://orionbrowser.com/platforms/linux
      Apple คงไม่น่าจะทำธุรกิจเครื่องเสมือน Safari แต่ถ้าต้องการเครื่องเสมือน macOS ก็ลองดูผู้ให้บริการคลาวด์ได้: https://aws.amazon.com/ec2/instance-types/mac/
      หลายแห่งเชื่อมต่อ orchestration สำหรับการทดสอบซอฟต์แวร์ไว้ล่วงหน้าแล้ว
    • Apple เพิ่งเปิดตัวเครื่องมือใหม่นี้ จึงถือได้ว่าใส่ใจนักพัฒนาเว็บอยู่
    • ก็เหมือนวิธีที่เคยใช้ทดสอบ IE บน Linux หรือ OS X

  • ช่วงหลังผมสั่งให้เอเจนต์เปิด Chrome แล้วสื่อสารโดยตรงผ่าน CDP ซึ่งทำงานได้ค่อนข้างดี

    • วิธีนั้นก็คงต้องลองดูสักครั้ง
      อยากรู้ว่าเทียบกับ Playwright แล้วเป็นอย่างไร
      จากมุมมองการพัฒนาเว็บ ข้อดีของ Playwright ดูจะอยู่ที่การใช้ได้กับหลายเบราว์เซอร์
      ถ้าเครื่องมือเฉพาะเบราว์เซอร์เร็วกว่า หรือมีประสิทธิภาพด้านโทเค็นดีกว่า สำหรับงานอัตโนมัติและ Claws ทางนั้นน่าจะเป็นตัวเลือกที่ดีกว่า
    • ใช่ วิธีนี้ทำงานได้ดีกว่าเส้นทาง MCP มาก และเร็วกว่าเยอะ

  • “มีหลายวิธีในการสร้างเว็บ ไม่ว่าจะใช้ AI หรือไม่ก็ตาม ถ้า AI เป็นส่วนหนึ่งของเวิร์กโฟลว์ของคุณ ผมคิดว่าเครื่องมือนี้จะช่วยเพิ่มผลิตภาพได้ ถ้าไม่ใช่ ก็ไม่เป็นไรเช่นกัน”
    แปลกดีที่ต้องมาพูดแบบนี้ในปี 2026
    เพราะเป็นยุคที่ถ้าคุณเขียนโค้ดเองและไม่ได้มอบหมายทุกอย่างให้เอเจนต์ บางคนก็จะมองว่าคุณเป็น มือใหม่

    • เมื่อ 2 ปีก่อน ฝั่งตรงข้ามกลับถูกมองว่าเป็นเรื่องเหลวไหล
      ตอนนี้ดีแล้วที่คนใช้ AI ไม่จำเป็นต้องปิดบังเรื่องนั้น
    • ไม่รู้ว่าส่วนไหนแปลก
      แปลกตรงที่ต้องใส่ข้อความปฏิเสธความรับผิดชอบแบบนี้เพื่อเอาใจ ฝ่ายต่อต้าน AI แบบสุดโต่ง หรือเปล่า
      นี่เป็นเครื่องมือสำหรับการพัฒนาแบบมี AI ช่วยอย่างชัดเจน แต่กลับต้องใส่ประโยคทำนองว่า “ขอส่งกำลังใจให้คนที่ไม่ใช้ AI ด้วย” ซึ่งต่างหากที่แปลกมาก
      เพียงแต่เป็นความแปลกคนละทิศกับที่คุณคิด

  • เหตุผลที่ MCP สำหรับ browser automation น่าสนใจคือ เอนจิน WebKit ของ Safari เป็นฝั่งที่เอเจนต์ AI ส่วนใหญ่จัดการได้ยาก
    Playwright และ Puppeteer เน้น Chromium เป็นหลัก ดังนั้นถ้ามี MCP server สำหรับ Safari ก็สามารถอุดช่องว่างจริงในการทดสอบข้ามเบราว์เซอร์ในเวิร์กโฟลว์ของเอเจนต์ได้