การมาถึงของ Web 2.0 2.0: MCP
(anildash.com)- Model Context Protocol (MCP) คือสเปกที่ Anthropic สร้างขึ้นเพื่อเชื่อม LLM กับแอปและระบบภายนอก หลังจาก OpenAI รองรับใน ChatGPT ก็แพร่หลายราวกับเป็นอินเทอร์เฟซร่วมของหลายแพลตฟอร์ม
- แม้สเปกจะหลวมและไม่สมบูรณ์ แต่หากผู้เล่นหลายรายนำวิธีเดียวกันไปใช้อย่างรวดเร็ว โปรโตคอลแบบเปิด ก็อาจทรงพลังขึ้นได้บนเว็บจริง
- คุณค่าดั้งเดิมของ Web 2.0 อยู่ใกล้กับระบบนิเวศของนักพัฒนาและผู้ใช้ที่เกิดจาก Open API และเครื่องมือที่ทำงานร่วมกันได้ มากกว่าไซต์โซเชียลแบบปิด
- เมื่อแพลตฟอร์มขนาดใหญ่อย่าง Facebook และ Twitter ปิด API จนความคาดหวังเรื่องการทำงานร่วมกันอ่อนแรงลง MCP อาจช่วยปลุกสิ่งนี้ขึ้นมาอีกครั้งในรูปแบบ แพลตฟอร์มที่โปรแกรมได้ ท่ามกลางกระแสเครื่องมือเขียนโค้ดด้วย AI
- MCP ไม่ใช่คำตอบสารพัดประโยชน์ และยังมีความไม่โปร่งใสในการจัดการข้อมูลกับ ความเสี่ยงด้านความปลอดภัย สูง แต่ก็อาจเป็นจุดเริ่มต้นใหม่ให้เรียกร้องการปฏิบัติตามมาตรฐานและความโปร่งใส
เบื้องหลังที่ทำให้ MCP แพร่หลายเหมือนมาตรฐาน
- Model Context Protocol หรือ MCP คือสเปกที่ Anthropic ออกแบบขึ้นสำหรับ Claude
- มีจุดประสงค์เพื่อให้ LLM ขอข้อมูลจากแอปต่าง ๆ หรือโต้ตอบกับระบบอื่นได้
- เมื่อ OpenAI รองรับโปรโตคอลเดียวกันใน ChatGPT เมื่อไม่กี่เดือนก่อน MCP ก็เริ่มเข้าที่เข้าทางเหมือนมาตรฐานที่ถูกนำไปใช้ในหลายแห่ง
- Windows ก็รวม MCP เข้าไปด้วย แสดงให้เห็นขอบเขตการแพร่กระจายของมัน
- ประเด็นสำคัญไม่ใช่ความสมบูรณ์ของสเปก แต่คือข้อเท็จจริงที่ผู้เล่นหลายรายนำอินเทอร์เฟซเดียวกันไปใช้อย่างรวดเร็ว
- MCP ค่อนข้างเป็นสเปกแบบหลวม ๆ แต่คล้ายกับวิธีที่เว็บประสบความสำเร็จตรงที่ เปิดกว้างและใช้งานได้จริง
Web 2.0 เดิมทีหมายถึงอะไร
- Web 2.0 ไม่ได้หมายถึงไซต์แบบปิดและผูกขาดอย่าง Facebook
- แกนกลางของชุมชน Web 2.0 ยุคแรกคือกระแสที่หลายไซต์提供 Open API และทำให้นักพัฒนากับผู้ใช้เชื่อมโยงผู้คนและข้อมูลเข้าด้วยกันได้
- Flickr, Del.icio.us และ Upcoming เป็นไซต์ตัวแทนของยุคที่บุกเบิกฟีเจอร์อย่างแท็กและการแชร์ทางโซเชียล
- แพลตฟอร์มอย่าง LiveJournal และ Movable Type ก็มีอิทธิพลต่องานมาตรฐานเปิดรอบ API และโปรโตคอลเช่นกัน
- คุณค่าร่วมในเวลานั้นค่อนข้างชัดเจน
- สร้างเครื่องมือ เทคโนโลยี และแพลตฟอร์มบน ข้อมูลแบบเปิด และโปรโตคอลแบบเปิด
- ผู้ใช้มีสิทธิ์ควบคุม
- นักพัฒนาโต้ตอบกับระบบด้วยเครื่องมือที่สอดคล้องกันและทำงานร่วมกันได้
การทำงานร่วมกันที่ถูกแพลตฟอร์มแบบปิดตัดขาด
- ตลอดหนึ่งเจเนอเรชันที่ผ่านมา นักพัฒนาเริ่มคาดหวังโดยอัตโนมัติได้ยากขึ้นว่าแอปกับแพลตฟอร์มจะทำงานร่วมกันได้
- ยังมีเสียงวิจารณ์ตามมาว่า VC รายใหญ่และผู้นำในอุตสาหกรรมเทคโนโลยีได้ทำให้ยุคแห่งความเปิดกว้างสิ้นสุดลง
- เครื่องมือที่วิเคราะห์กิจกรรมบนโซเชียลเน็ตเวิร์กเคยเจอกรณีที่ผลิตภัณฑ์และบริการสำหรับผู้ใช้ต้องหยุดลง เมื่อแพลตฟอร์มโซเชียลเน็ตเวิร์กขนาดใหญ่ปิด API
- แพลตฟอร์มอย่าง Facebook และ Twitter ทำให้ความคาดหวังของ Web 2.0 เรื่อง ข้อมูลแบบเปิด และเทคโนโลยีที่ทำงานร่วมกันได้พังทลายลงสำหรับผู้คนจำนวนมาก
- ผลก็คือสถานการณ์ที่ผู้ใช้จัดการเครือข่ายของตัวเองในแบบที่ต้องการได้ยากกลายเป็นเรื่องปกติ
- ดูรูป Instagram ที่ฝังอยู่ในไทม์ไลน์ Twitter ไม่ได้
- ใช้ฟีเจอร์อย่างการนำเข้าและส่งออกผู้ติดตามแบบที่ทำได้ใน fediverse หรือ Bluesky ได้ยาก
- ควบคุมเครือข่ายของตัวเองด้วยแอปที่ต้องการได้ยาก
ความเป็นไปได้ที่ MCP อาจเปิดขึ้นอีกครั้ง
- การผงาดขึ้นของ MCP สอดรับกับกระแสความนิยมของ AI ในหมู่คนเขียนโค้ด และสร้างความคาดหวังว่าแพลตฟอร์มอาจเปิดให้ใช้งานไม่ใช่แค่กับ LLM แต่รวมถึง วัตถุประสงค์ด้านการโปรแกรมที่หลากหลาย ด้วย
- จุดสำคัญคือแพลตฟอร์มอื่น ๆ นำสเปกที่ Anthropic สร้างไปใช้ตามเดิม
- หากนำโปรโตคอลของบริษัทอื่นมาใช้เป็นรายที่สองอย่างซื่อตรง ระบบนิเวศทั้งหมดก็จะทำงานในแนวทางเดียวกันได้ง่ายขึ้น
- ในทางกลับกัน วิธีคัดลอกและขยายโปรโตคอลแล้วสุดท้ายยกเลิกไป อาจทำร้ายระบบนิเวศได้
- เมื่อมีการนำไปใช้ด้วยเจตนาดีว่าจะใช้อินเทอร์เฟซเดียวกัน โอกาสที่เครื่องมือและแพลตฟอร์มหลายอย่างจะทำงานร่วมกันก็เพิ่มขึ้น
ความยากของการทำตามมาตรฐานอย่างเคร่งครัด
- การรองรับมาตรฐานตามเดิมนั้นยากกว่าที่เห็น
- แม้ตอนเปิดตัว ผลิตภัณฑ์ semantic caching สำหรับแพลตฟอร์ม AI ก็ไม่ง่ายที่จะโน้มน้าวให้นักพัฒนาใช้ ChatGPT API ทั่วไปตามเดิม
- นักพัฒนามักคิดได้ง่ายว่า “เราทำให้ดีกว่านี้ได้” แต่ทันทีที่เบี่ยงออกจากมาตรฐาน สิ่งนั้นอาจกลับแย่ลงกว่าเดิม
- บางครั้ง ต่อให้เป็นสเปกที่แย่และมีความไม่สอดคล้องมากมาย สิ่งที่สำคัญกว่าคือทุกคน implement ในแบบเดียวกัน
- HTML ก็เคยเป็นสเปกที่ไม่สมบูรณ์และขาดหลายอย่าง แต่เว็บก็ถูกสร้างขึ้นบนมัน
- อินเทอร์เน็ตทั้งระบบเองก็ตั้งอยู่บนสเปกไม่สมบูรณ์หลายชุด
ข้อเรียกร้องเรื่องการปฏิบัติตามมาตรฐานและความโปร่งใส
- นักพัฒนารุ่นใหม่กำลังได้สัมผัสความคิดสร้างสรรค์และความเป็นไปได้ที่เกิดขึ้นเมื่อเครื่องมือและแพลตฟอร์มที่ตนชอบใช้โปรโตคอลและรูปแบบเดียวกัน
- กระแสอย่าง RSS, พอดแคสต์, OpenID, OAuth และ OpenSocial บางส่วนในภายหลังนำไปสู่ผลลัพธ์อย่าง fediverse และ ActivityPub
- นักพัฒนา คนเขียนโค้ด ผู้สนใจเทคโนโลยี และผู้ใช้ทั่วไปก็สามารถเรียกร้องสิทธิ์เข้าถึงเพื่อควบคุมประสบการณ์บนแพลตฟอร์มด้วยโค้ดได้
- เมื่อต้องเข้าถึงผ่านมาตรฐานเปิดอย่าง MCP ก็ควรเรียกร้อง ความโปร่งใส ควบคู่กันด้วยว่าแพลตฟอร์มกำลังทำอะไรอยู่จริง ๆ
- MCP ยืดหยุ่น แต่ยังทิ้งความเสี่ยงไว้หลายอย่าง
- ไม่โปร่งใสว่าแพลตฟอร์มจัดการข้อมูลผู้ใช้อย่างไร
- ยากที่จะรู้ว่าจะเกิดการกระทำใดขึ้นในการโต้ตอบผ่าน MCP
- ความเสี่ยงด้านความปลอดภัยสูงมาก
- โปรโตคอลไม่ได้จัดการข้อกังวลเหล่านี้อย่างเพียงพอ
ข้อจำกัดและความคาดหวังของความเปิดกว้างแบบ Web 2.0
- MCP ไม่ใช่คำตอบสารพัดประโยชน์ที่จะแก้ทุกปัญหาของระบบนิเวศนักพัฒนา
- และไม่ได้แก้ไขกระแสเกินจริงกับการบิดเบือนการถกเถียงรอบ AI
- อย่างไรก็ตาม มีความเป็นไปได้ว่านักพัฒนารุ่นใหม่ที่ไม่เคยผ่านยุค Web 2.0 รุ่นก่อน จะใช้ MCP เป็นจุดเริ่มต้นในการพยายามพาเว็บกลับไปใกล้สถาปัตยกรรมดั้งเดิมของมัน
- เว็บไม่ได้ถูกตั้งใจให้อยู่ในโครงสร้างแบบผูกขาดหรือถูกควบคุมโดยคนไม่กี่คนในบริษัทใหญ่ไม่กี่แห่ง
- เว็บควรเป็นสิ่งที่โปรแกรมได้ผ่านสเปกหยาบ ๆ ที่ทุกคนรีบนำไปใช้ และความสนุกแบบแฮ็กได้นั้นมีอยู่บนเว็บมาตั้งแต่ก่อนเว็บจะมีหมายเลขเวอร์ชันเสียอีก
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
สิ่งที่หลายคนมองข้ามเกี่ยวกับ MCP คือมันเหมาะกับ ซอฟต์แวร์องค์กร มาก
LLM เป็นตัวแปลอเนกประสงค์ จึงเหมาะจะเป็นกาวที่เชื่อมระบบที่แยกขาดจากกันและเชื่อมต่อกันได้ยากมาก หากไม่มีเลเยอร์ตรงกลางที่ค่อนข้างยืดหยุ่น
เพราะอย่างนั้นวงการ B2B SaaS ถึงกำลังปล่อยเซิร์ฟเวอร์ MCP ออกมา และภายในก็กำลังคุยกันว่าจะออกแบบ API กับข้อจำกัดของมันใหม่อย่างไรให้สอดคล้องกับรูปแบบการใช้งานที่เปลี่ยนไป
โปรโตคอลนี้ตามคำนิยามหลายอย่างยังไม่ “พร้อมสำหรับองค์กร” แต่เหมือนที่ผู้เขียนบอก นั่นไม่ได้สำคัญมากนัก ถ้าดูประวัติของมาตรฐาน สิ่งที่เละเทะและ “แย่” ก็ถูกนำไปใช้อย่างแพร่หลายได้ ถ้ามันลงตัวกับคนที่ใช่ในเวลาที่เหมาะสม
การถกเถียงจะลดลงว่า การเปลี่ยนฟิลด์ของอ็อบเจ็กต์ผู้ใช้ควรเป็น PUT ที่แทนที่อ็อบเจ็กต์ผู้ใช้เดิม หรือเป็น POST กันแน่ ผมเคยเสียเวลากับกริยา REST มาไม่น้อย
LLM ก็ไม่จำเป็นต้องเข้าใจ semantics แบบ REST ของ API ด้วย แค่ดูเมธอด RPC ที่ใช้ได้ แล้วเรียกสิ่งที่น่าจะใช้ได้ก็พอ ประเด็นหลักจริง ๆ ผมว่ามีแค่นั้น
ไม่ใช่แบบที่ endpoint ต่าง ๆ เจรจาสคีมาเพื่อให้ query กันได้ถูก ๆ ในอนาคต
แค่นั้นก็ทำฟีเจอร์อย่าง self-discovery ได้แล้ว
ที่ไหนที่จะให้บริการ MCP ยังไงก็คงให้ API ที่ดีด้วยอยู่แล้ว
มีบริษัทไหนบ้างที่ไม่อยากรีดประสิทธิภาพการทำงานจากพนักงานให้ได้มากที่สุดในเวลางาน
ส่วนที่ว่า “เทียบกับยุคก่อนที่ลุง Unix แก่ ๆ จอมเรื่องมากเป็นคนเขียนสเปก” ผมมองว่าเป็นหนึ่งในหลายเหตุผลที่ Semantic Web ล้มเหลว และก็ไม่ได้ขัดกับใจความของผู้เขียนที่ว่า “ของแย่ดีกว่า”
ผมคิดว่าผู้คนอินกับคำว่า eXtensible ใน XML มากเกินไป และเกิดความล้ากันพอสมควร XSL, XHTML, XSD, WSDL, XSLT, RDF, RSS และอื่น ๆ มีมากเกินไป
สิ่งที่โลกต้องการในตอนนั้นคือรูปแบบแลกเปลี่ยนข้อมูลที่เรียบง่าย และ JSON ตอบโจทย์นั้นได้ แต่ฝั่ง XML นั้นแทบจะเป็นการทำ “สถาปัตยกรรมอวกาศ” รอบรูปแบบข้อมูล
แต่ผมก็เชื่อว่าตอนนี้ถึงเวลาของ XML แล้ว ใน system prompt ที่หลุดออกมาจากที่อย่าง Anthropic เราเห็น XML บ่อย ๆ LLM ดูเหมือนจะจัดการรูปแบบข้อความที่มีโครงสร้าง โดยเฉพาะ Markdown กับ XML ได้ค่อนข้างดี
อย่างไรก็ตาม ผมมองว่า MCP เป็นโมเดลที่ผิด แทนที่จะสั่งให้โมเดล “ดึง” บริบทเข้ามาเอง ผมคิดว่าเราควร “ยัด” บริบทเข้าไปให้โมเดล
แท็กมาโครสี่แบบ (
#=,#&,#?,#!) แต่ละอันแทนการกำหนดค่า การแทนที่ การแตกแขนงเงื่อนไขแบบcondและการเรียกฟังก์ชันที่ผู้ใช้กำหนด โดยแทนที่ตัวเองด้วยผลลัพธ์จากการขยายมาโคร แต่สุดท้ายก็รู้ตัวว่ากำลังสร้าง XSLT ขึ้นมาใหม่สิ่งที่ต้องการจริง ๆ คือ XPath วิธีอธิบายการเดินกราฟไปหน้าและถอยหลังตามแกนต่าง ๆ ซึ่งเป็นสเปกที่ยอดเยี่ยมจริง ๆ
แล้วผมก็เจอ BaseX https://basex.org/ ที่ช่วยนำเอกสาร XML ใด ๆ เข้าไปเป็นฐานข้อมูลที่ query ได้ และ query ด้วย XPath หรือ XQuery ได้
ถ้าจะสร้างอินเทอร์เฟซชุดข้อมูลภาษาธรรมชาติที่น่าเชื่อถือและไม่มี hallucination วิธีที่ดูดีที่สุดคือส่ง XML schema เข้าไปใน system prompt แล้วให้โมเดลเขียน query เพื่อดึงข้อมูล
ถ้ารู้ข้อมูลล่วงหน้า ก็คงแก้ปัญหาเองไปแล้ว
คุณค่าที่ได้จาก MCP ดูใกล้เคียงกับ “อย่าให้ฉันต้องเรียนรู้วิธีเชื่อมแหล่งข้อมูล 15 แหล่ง แต่ช่วยรัน query บางอย่างแทนฉันที” มากกว่า
ไม่มีใคร™ ป้อน XML ที่ถูกต้องซึ่งขึ้นต้นด้วย XML declaration ให้ LLM และก็ไม่ได้ใช้ namespace, XSLT หรือ XML Schema อะไรพวกนั้น
มันใกล้เคียงกับการรวมแท็กสไตล์ SGML แบบตามใจมากกว่า
XML เป็นสเปกขนาดใหญ่ที่มีมากกว่าแค่วงเล็บมุม และพยายามครอบคลุมทุกกรณี พร้อมจัดการความปลอดภัยกับการเข้ารหัสอักขระให้ถูกต้อง
เพราะงั้น “การแก้ไขแบบ plain text” จึงไม่ค่อยเป็นธรรมชาติเท่าไร ถ้าพิมพ์อะไรอย่างย่อหน้านี้ลงไป อาจ parse ได้ในโหมด compatibility แต่ก็อาจไม่ valid
ในฐานะรูปแบบแลกเปลี่ยนข้อมูล หรือรูปแบบที่โหลดเข้าแอปพลิเคชันที่สร้างมาเพื่อมันโดยเฉพาะ ยังมีโอกาสมากกว่า และ LLM ก็คงเข้าใจได้ไม่ยากแน่นอน ซึ่งนั่นเป็นเรื่องดี
ปัญหาจำนวนมากในอดีตมาจากโปรแกรมเมอร์ที่มีเวลาไม่พอและอยากยัดฟีเจอร์เข้าไปเร็ว ๆ ใช้สเปกที่มีโครงสร้างเข้มงวดเหมือนกระบอง “XML เหรอ? ใช้ regex ก็ได้” ถ้าโปรแกรมต่างกันสามตัวกับผู้เขียนสามคนทำแบบนี้ซ้ำ ๆ ก็กลายเป็นความโกลาหล
โดยส่วนตัว รูปแบบที่ใกล้กับสิ่งที่ผมต้องการจริง ๆ คือ BBCode มันยอดเยี่ยมในฐานะรูปแบบต้นฉบับของหลายสิ่ง โดยพื้นฐานก็ยังเป็นตระกูลวงเล็บมุม แต่มีโครงสร้างและความยืดหยุ่นพอเหมาะสำหรับใช้เป็นไวยากรณ์ frontend อเนกประสงค์
การ implement ยุคแรก ๆ คือ “ใช้ regex ก็ได้” แต่ผ่านการพิสูจน์ในงานจริงมาหลายสิบปี ทุกวันนี้ก็มี parser ที่สง่างามกว่านั้นแล้ว
ผมคิดตรงกันข้ามกับประโยคที่ว่า “การผงาดขึ้นของ MCP ทำให้เกิดความหวังว่า เมื่อ AI ได้รับความนิยมในหมู่โค้ดเดอร์ LLM อาจเปิดแพลตฟอร์มอื่น ๆ ให้สามารถโปรแกรมได้เพื่อวัตถุประสงค์ใด ๆ ไม่ใช่แค่เพื่อให้ LLM ควบคุมเท่านั้น”
MCP ถูกกำหนดให้ล้มเหลวด้วยเหตุผลเดียวกับที่ Semantic Web ล้มเหลว เพราะถ้าอะไรบางอย่างไม่ถูกล็อกไว้ ก็ไม่มีใครทำเงินได้
ผมสงสัยว่า AI ที่ค้นเว็บแทนเรา ขอโทษที ฟีเจอร์ที่เรียกว่า “deep-research” นั้น มีสักกี่ส่วนที่จริง ๆ แล้วอาจแก้ได้ด้วยวิธีที่ดีกว่านี้
ร้านอาหารอาจเปิดเผยเมนูในรูปแบบเมทาดาทา และใคร ๆ ก็ใช้สคริปต์ Python หา taco ที่ถูกที่สุดในเท็กซัสได้ แต่ความจริงคือ มือข้างหนึ่งล็อกข้อมูลไว้หลังกำแพงเทียม ส่วนอีกข้างก็สร้าง AI รวมถึงดาต้าเซ็นเตอร์เพื่อหาทางเลี่ยงมัน มองในภาพใหญ่แล้วมันก็เป็นเรื่องโง่ ๆ เท่านั้นเอง
เหตุผลที่กระแสเอเจนต์ก่อนหน้านี้ตายไป ก็เพราะสุดท้ายทุกคนตระหนักว่าไม่สามารถเชื่อถือโค้ดของตัวเองที่ไปรันอยู่บนเครื่องซึ่งทุกอย่างต่อรองได้ เหตุการณ์ฝั่ง Java ในยุค 90 นั่นแหละ
โดยพื้นฐานแล้ว ระหว่างเอเจนต์ที่โต้ตอบกันมีปัญหาความไม่สมมาตรของข้อมูลที่ถูกออกแบบมาอย่างจงใจ ถ้าเอามันออกไป สังคมส่วนใหญ่ก็จะหยุดทำงาน
ต่อให้ทุ่มทรัพยากรใส่ปัญหามากแค่ไหน ก็จะมีใครสักคนหาวิธีใช้ทรัพยากรนั้นจนหมดเพื่อผลประโยชน์เล็กน้อยมาก ๆ
MCP มีแต่จะทำให้ปัญหาแย่ลง เมื่อ AI agent แห่กันไปยังเซิร์ฟเวอร์ MCP สาธารณะเหมือนฝูงตั๊กแตน
ตัวเลือกที่เสถียรน่าจะเป็นการตั้งราคา RPC แบบคิดเงินต่อการเรียกใช้งาน อย่างน้อยผู้ที่รันโมเดลหรือเอเจนต์ก็คงทำหน้าที่เป็นสำนักหักบัญชีการชำระเงิน จึงมีโอกาสเป็นไปได้มากกว่า API ยุค Web 2.0
บางทีวิธีคิดเงินที่เป็นไปได้มากที่สุดน่าจะเป็นการรวมต้นทุนแบบนี้ไว้ในแพ็กเกจค่าสมัครสมาชิก นั่นดูเป็นวิธีที่ดีที่สุดในการทำให้แรงจูงใจสอดคล้องกัน
คนที่ตั้งชื่อว่า HATEOAS ตั้งแต่แรกก็เหมือนปูทางให้มันล้มเหลวแล้ว
ถ้ามีคุณค่าแบบ “ง่าย ๆ” ในการเปิดเผยข้อมูลเป็นรูปแบบมาตรฐาน endpoint ที่ทำงานร่วมกันได้ก็คงถูกนำไปใช้มากกว่านี้มาก
เช่นการใช้ schema.org หรือ ontology ร่วมทั่วไปอะไรแบบนั้น แต่ในความจริง มักมีรูปแบบเฉพาะที่ต้องใช้ SDK เวทมนตร์พิเศษทุกครั้ง
ฝ่ายที่เรียกร้องให้ร้านอาหารเปิดเผยเมนูในรูปแบบเมทาดาทาต่างหากที่เป็นกำแพงเทียม
ความงดงามของเครื่องมือประมวลผลภาษาธรรมชาติรุ่นใหม่อยู่ตรงนี้ เจ้าของร้านอาหารไม่จำเป็นต้องเรียน JSON หรือซื้อแพ็กเกจซอฟต์แวร์ที่สร้าง JSON
เราใช้ข้อมูลตามสภาพที่มันเป็นได้ ต้นทุนในการสร้างเครื่องมือที่มีประโยชน์ลดลงจนเกือบเป็นศูนย์
ถึงจะไม่แม่นยำก็เถอะ แต่ภาษามนุษย์ก็เป็นแบบนั้นอยู่แล้ว
คนที่คิดว่ามี MCP แล้วจะเข้าถึงอะไรก็ได้ ดูน่าสงสารนะ
สิ่งพวกนั้นจะถูกซ่อนไว้หลังชั้นการตรวจสอบการชำระเงินและการยืนยันตัวตนอีกเป็นสิบ ๆ ชั้น แน่นอนว่าต้องมี IP แบบ allowlist ด้วย และแน่นอนว่าจะเป็น IPv4
สิ่งเดียวที่คุณจะเห็นคงมีแค่
ERR 402;สิ่งที่น่ากังวลที่สุดเกี่ยวกับ MCP ไม่ใช่ว่าโปรโตคอลถูกทำมาแย่ แต่เป็นการที่งานแก้ไขและปรับปรุงมันขึ้นอยู่กับ ทีมภายในของ Anthropic และ OpenAI เท่านั้น
คนที่สร้างโปรโตคอลนี้ดูไม่เหมือนวิศวกรที่ลงมือ implement เองจริง ๆ
มันให้ความรู้สึกคล้าย ๆ การผูกขาดโดยผู้เล่นน้อยรายแบบ Visa-Mastercard อยู่เลา ๆ
https://techcrunch.com/2025/05/19/github-microsoft-embrace-a...
ตอนนี้ถ้า LLM สามารถอ่านเอกสาร API แล้วปรับตัวได้ การทำตาม API มาตรฐาน ก็อาจจำเป็นน้อยกว่าเดิมไม่ใช่หรือ
ข้อดีที่สำคัญสำหรับผมคือการเกิดความคาดหวังว่าไซต์นั้น “มี” API ไม่ว่าจะทำตามสเปก MCP หรือไม่ก็ตาม
แม้เอกสารจะดี LLM ก็อาจสร้างโค้ดที่โต้ตอบกับ API ผิดได้ ถ้าต้องแก้โค้ดที่สร้างขึ้น แล้วให้ LLM เรียกโค้ดนั้นเพื่อโต้ตอบกับ API อยู่ดี นั่นก็เท่ากับเริ่มเดินไปสู่ชั้นกลางอยู่แล้ว โดยพื้นฐานก็คือการสร้างเซิร์ฟเวอร์ “คล้าย MCP” นั่นเอง
การให้ LLM เข้าถึง API โดยตรงยังมีปัญหาเรื่องความปลอดภัยและการจัดสรรทรัพยากรด้วย LLM มีความรู้จำกัดว่า API ถูกเรียกครั้งล่าสุดเมื่อไร มันอาจเรียกบ่อยเกินไป และถ้าค่าใช้จ่ายต่อการเรียกแพง ก็อาจเกิดบิลโครงสร้างพื้นฐานที่คาดไม่ถึง
นอกจากนี้ยังมีจุดเจ็บปวดที่อาจเกิดขึ้นอีกมาก ซึ่งแก้ได้ด้วยการวางอะไรบางอย่างไว้ตรงกลาง
ว่า “อะไรบางอย่าง” นั้นจำเป็นต้องเป็น MCP หรือไม่ คนที่มีเหตุผลอาจมองต่างกันได้ ตอนนี้ดูเหมือนมันทำงานได้ดีพอสำหรับจัดการสิ่งที่ผู้คนต้องทำ
ตอนนี้เราสร้าง Semantic Web ได้แล้ว แค่องค์กรต่าง ๆ สร้างโปรโตคอลเล็ก ๆ สำหรับแชร์ SQL
CREATE TABLEDDL เป็นไฟล์สแตติกที่แอป MCP อ่านได้ก็พอ เป็นส่วนขยายแบบเลือกใช้ของ MCP ก็เพียงพอแล้วจากนั้นก็ใช้เครื่องมือที่มีอยู่แล้วซึ่งเชื่อมการเรียกฟังก์ชันของ AI/LLM เข้ากับ SQL เพื่อทำความเข้าใจและคิวรีข้อมูลได้ นั่นแหละจะเป็น Semantic Web
วิธีนี้เติมชิ้นส่วนที่ขาดหายไปซึ่งเคยขวาง Semantic Web มาตลอด นั่นคือปัญหาที่บริษัทไม่มีแรงจูงใจให้ใช้ “ชนิดข้อมูล” มาตรฐานแทนชนิดข้อมูลแบบกรรมสิทธิ์
ถ้ามี MCPQ หรือ MCP ที่รวมการคิวรีขึ้นมา จู่ ๆ องค์กรต่าง ๆ ก็จะมีเหตุผลให้ร่วมมือกันในชั้นโครงสร้างข้อมูล
กลายเป็นว่า “Semantic Web” ที่ผ่านมาจริง ๆ แล้วเป็น Syntactic Web มาตลอด และบางทีครั้งนี้อาจเป็นของจริงก็ได้
สงสัยว่าต้องใช้เวลานานแค่ไหนกว่าจะมีใครทำ MCP server สำหรับควบคุมอะไรอย่างแมลงสาบได้
แหล่งอ้างอิง:
https://www.technologynetworks.com/informatics/news/robo-roa...
https://www.sciencealert.com/scientists-turned-cockroaches-i...
และยังมีตัวอย่างอื่น ๆ อีกมากที่ย้อนกลับไปได้มากกว่า 10 ปี
สำนวนที่ว่า “ยุคที่สเปกเขียนโดยลุง Unix แก่ ๆ จู้จี้จุกจิก” ค่อนข้างตลกดี
น่าสนใจที่คนรุ่นนี้จินตนาการถึง “ลุง Unix แก่ ๆ” ว่าเป็นพวกจู้จี้จุกจิก ทั้งที่ Unix เคยเป็นการกบฏแบบ move fast and break things ขั้นสุด เพื่อต่อต้านสำนัก MIT เลยด้วยซ้ำ
ดูเหมือนว่าบางอย่างก็ไม่เคยเปลี่ยนสินะ :-)