การมาถึงของ Web 2.0 2.0: MCP

• Model Context Protocol (MCP) กำลังถูกนำไปใช้อย่างรวดเร็ว และกำลังก้าวขึ้นเป็น มาตรฐานเปิด แบบใหม่
• คุณค่าหลักของ MCP ไม่ได้อยู่ที่ความสมบูรณ์แบบ แต่อยู่ที่ ความเปิดกว้างและการทำงานร่วมกันได้
• ความหมายที่แท้จริงของ Web 2.0 ไม่ใช่ แพลตฟอร์มปิด แต่คือ API แบบเปิดและการแบ่งปันข้อมูล
• กำลังเกิดกระแสหวนกลับจากยุคของความปิด ไปสู่ คุณค่าของเว็บแบบเปิด อีกครั้ง
• การยอมรับ MCP อาจทำให้นักพัฒนา เรียกร้องการควบคุมแพลตฟอร์มและความโปร่งใส มากขึ้น

---

MCP: การมาถึงของเว็บแบบเปิดยุคใหม่

ในช่วงไม่กี่เดือนที่ผ่านมา ความสนใจต่อ Model Context Protocol (MCP) ได้พุ่งสูงขึ้นอย่างมากในหมู่นักพัฒนา จุดเริ่มต้นมาจากการที่ Anthropic ออกแบบมันขึ้นในปี 2023 เพื่อให้ระบบ LLM ภายในของตน (Claude) สามารถโต้ตอบกับแอปต่าง ๆ ได้ หลังจากนั้น OpenAI ก็รองรับโปรโตคอลเดียวกันใน ChatGPT ทำให้มันกลายเป็นมาตรฐานอย่างรวดเร็ว ตอนนี้ยังขยายไปสู่แพลตฟอร์มหลักอื่น ๆ เช่น Windows อีกด้วย

สิ่งที่น่าสนใจคือ จุดเด่นของ MCP ไม่ได้อยู่ที่ความชัดเจนหรือความสมบูรณ์ของตัวมันเอง แต่อยู่ที่ความสะดวกและความรวดเร็วในการใช้งาน ต่างจากมาตรฐานแบบดั้งเดิมที่ถูกออกแบบอย่างเข้มงวด MCP เป็นข้อกำหนดที่ค่อนข้างคลุมเครือและนิยามแบบหลวม ๆ แต่กลับใช้งานได้จริงดีมาก ที่สำคัญที่สุดคือ มันเป็น โปรโตคอลแบบเปิด ที่ใครก็สามารถนำไปใช้ได้

ความหมายที่แท้จริงของเว็บแบบเปิด

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

จิตวิญญาณของ Web 2.0 มุ่งไปที่ ระบบนิเวศแบบเปิด เช่น API แบบเปิด การแบ่งปันข้อมูล และการเพิ่มอำนาจควบคุมให้ผู้ใช้และนักพัฒนา ต้องระวังว่าแพลตฟอร์มปิดอย่าง Facebook คือ ตัวการที่ทำให้ Web 2.0 เสื่อมสลาย ในอดีต Flickr, del.icio.us, Upcoming และบริการอื่น ๆ เคยเป็นผู้นำวัฒนธรรมที่ให้ความสำคัญกับการแบ่งปันและการเชื่อมต่อ และบนแพลตฟอร์มอย่างไลฟ์บล็อกก็มีการถกเถียงเรื่องมาตรฐานเปิดของ API/โปรโตคอลอย่างคึกคัก

การกลับมาของความเปิด

เมื่อเวลาผ่านไปหนึ่งยุคสมัย ตอนนี้ความคาดหวังต่อ การทำงานร่วมกันได้ กำลังสูงขึ้นอีกครั้ง ในอดีตเราเผชิญกับประสบการณ์ซ้ำ ๆ ที่บริษัทเทคขนาดใหญ่ใช้นโยบายปิดกั้น API และปล่อยให้บริการหายไป ตัวอย่างเช่น เครื่องมือวิเคราะห์ข้อมูลโซเชียลเน็ตเวิร์กที่ผู้เขียนสร้างขึ้น สุดท้ายก็ต้องยุติลงเพราะฝั่งแพลตฟอร์มปิดกั้น API นโยบายเช่นนี้ได้ทำลายวิสัยทัศน์เรื่องข้อมูลเปิดและความเข้ากันได้ของ Web 2.0 ส่งผลให้ปัญหาอย่างการฝังคอนเทนต์ไม่ได้หรือการย้ายข้อมูลทำได้ยาก กลายเป็นเรื่องปกติ

อย่างไรก็ตาม การมาถึงของ MCP ทำให้คาดหวังได้ว่า AI จะเป็นตัวกระตุ้นให้ ความสามารถในการเขียนโปรแกรมได้ และ ความเปิดกว้าง กลับมาอีกครั้ง การที่หลายแพลตฟอร์มนำโปรโตคอลเดียวกันไปใช้ ช่วยให้เกิดวงจรเชิงบวกบนฐานเทคโนโลยีได้

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

ความสำคัญของการยึดตามมาตรฐาน

นักพัฒนารุ่นใหม่กำลังได้สัมผัสด้วยตัวเองถึงพลังของนวัตกรรมที่เกิดขึ้นบน โปรโตคอลและฟอร์แมตเดียวกัน ประสบการณ์แบบนี้มีแนวโน้มจะนำไปสู่การยึดมั่นกับ มาตรฐานเปิด อย่างจริงจังอีกครั้ง บรรยากาศนี้คล้ายกับยุคที่ฟอร์แมตเปิดอย่าง RSS, Podcast, OpenID, OAuth, OpenSocial เคยมอบอำนาจให้ผู้ใช้ได้จริง

ตอนนี้ไม่ใช่ช่วงเวลาที่ทุกอย่างเป็นของบริษัทใหญ่เพียงฝ่ายเดียวอีกต่อไป แต่เป็นช่วงที่ชุมชนนักพัฒนาและผู้ใช้สามารถใช้สิทธิในการเรียกร้องได้ด้วยตนเอง ทุกคนควรสามารถเรียกร้อง การควบคุมประสบการณ์ใช้งานและความโปร่งใส จากแพลตฟอร์มได้ และเมื่อแพลตฟอร์มนำมาตรฐานเปิดอย่าง MCP มาใช้ ก็จำเป็นต้องมีความโปร่งใสเกี่ยวกับการทำงานภายในและการใช้ข้อมูลรองรับไปด้วย แม้ MCP จะเปิดกว้าง แต่ก็ยังมีข้อบกพร่องในเรื่องกลไกภายในและประเด็นด้านความปลอดภัย ซึ่งยังต้องได้รับการปรับปรุงต่อไป

ความเป็นไปได้ของการฟื้นคืนจิตวิญญาณ Web 2.0

MCP ไม่ใช่ คำตอบสารพัดนึก ที่จะแก้ทุกปัญหาได้ทั้งหมด แต่ดูเหมือนว่าจะเป็น จุดตั้งต้น ที่ช่วยกระตุ้นการฟื้นคืนของระบบนิเวศแบบเปิดในยุค Web 2.0 ได้ ข้อจำกัดอย่างการพูดถึง AI แบบเกินจริงหรือการขาดเสียงวิจารณ์ยังคงมีอยู่

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

[GN⁺]

ความเห็นจาก Hacker News

• รู้สึกว่าหลายคนมักมองข้ามแก่นสำคัญของ MCP ว่าเหมาะกับซอฟต์แวร์องค์กร เพราะ LLM สามารถทำหน้าที่เป็นเลเยอร์กลางที่ยืดหยุ่น คล้ายเครื่องแปลสารพัดนึกที่เชื่อมระบบซึ่งปกติเชื่อมต่อกันยากเข้าด้วยกันได้ ทำให้ในอุตสาหกรรม B2B SaaS ก็เริ่มมีการนำเซิร์ฟเวอร์ MCP มาใช้กันอย่างคึกคัก ภายในบริษัทเองก็มีการถกเถียงกันมากขึ้นว่าจะปรับข้อจำกัดหรือโครงสร้างให้สอดคล้องกับรูปแบบการใช้งาน API อย่างไร แม้โปรโตคอลนี้จะยังไม่ “พร้อมสำหรับองค์กร” ในหลายความหมาย แต่ก็เห็นว่านั่นไม่ใช่ประเด็นใหญ่นัก เพราะในประวัติศาสตร์ของมาตรฐานนั้น สเปกที่ยังขรุขระและ “ไม่เนี้ยบ” หากตอบโจทย์ตลาดได้ สุดท้ายก็มักถูกยอมรับอยู่ดี
  • เข้าใจว่า MCP ให้ความรู้สึกเหมือน RPC ที่ทำงานบนการเชื่อมต่อแบบยาว และโดยมากอิงกับ WebSocket ส่วนตัวคิดว่า RPC ง่ายกว่า เพราะหนึ่ง มันช่วยลดการถกเถียงที่ไม่จำเป็นอย่างการออกแบบ REST endpoint ว่าควรใช้ POST เพื่อแทนที่ทั้งหมด หรือใช้ PUT เพื่อแก้เฉพาะบางฟิลด์ และสอง LLM ไม่จำเป็นต้องรู้คำศัพท์หรือ semantics ของ REST แค่เห็นเมธอดของ RPC ก็เรียกใช้ได้ทันที สรุปแล้วสองข้อนี้เป็นจุดแข็งมาก
  • อยากชี้ว่าจากมุมมองขององค์กร MCP เป็นโมเดลรายได้ที่ยอดเยี่ยม เพราะทุกคำขอข้อมูลเชื่อมตรงกับการรัน LLM ที่มีค่าใช้จ่าย แต่ก็ยังน่าเสียดายที่การนำ MCP มาใช้ยังไม่มีการเพิ่มประสิทธิภาพอย่างการต่อรองสคีมาที่จะทำให้การ query ในอนาคตถูกลง
  • มีทั้ง REST และ OpenAPI อยู่แล้ว ซึ่งรองรับความสามารถอย่าง self-discovery ได้ในตัว และเชื่อว่าบริษัทที่ถึงขั้นจะให้ MCP ก็คงล้วนมี API ที่ดีให้อยู่แล้ว
  • เห็นด้วยมากว่าในองค์กรขนาดใหญ่มีวิศวกรจำนวนมากที่ตั้งแต่ 9 โมงถึง 5 โมงก็โฟกัสทำงานเจ๋ง ๆ ให้เต็มที่ แล้วหลังเลิกงานก็ไม่คิดเรื่องบริษัทอีกเลย ถ้าอย่างนั้นในมุมบริษัท การคว้าโอกาสเพิ่มผลิตภาพของพนักงานภายในเวลางานให้สูงสุดก็คือทางเลือกที่สมเหตุสมผลที่สุด
• สงสัยว่าต้องใช้เวลาอีกนานแค่ไหนกว่าจะมีการทดลองควบคุมสิ่งมีชีวิตอย่างแมลงสาบผ่านเซิร์ฟเวอร์ MCP เพราะในความเป็นจริง ตลอดกว่า 10 ปีที่ผ่านมา ก็มีตัวอย่างมากมาย เช่น การทดลอง RoboRoach, แมลงสาบไซบอร์ก
• เมื่อก่อนนักพัฒนา Unix เขียนเอกสารสเปกกันอย่างเคร่งครัด แต่ยุคสมัยเปลี่ยนไป และอยากเสนอว่าความเคร่งครัดกับความเหนื่อยล้าจากความเป็น extensible นี้เองเป็นหนึ่งในสาเหตุที่สถาปัตยกรรมแบบ XML ล้มเหลว ตอนนั้นมีทั้ง XSL, XHTML, XSD, WSDL, RDF, RSS และสถาปัตยกรรมที่ซับซ้อนเกินไป จนท้ายที่สุดฟอร์แมตเรียบง่ายอย่าง JSON ได้รับความนิยม แต่ช่วงหลังกลับเริ่มเห็นแนวโน้มการใช้ XML มากขึ้น โดยเฉพาะใน system prompt ของระบบ LLM อย่าง Anthropic ที่มักใช้ข้อความเชิงโครงสร้างอย่าง XML หรือ Markdown อย่างไรก็ตาม คิดว่าโมเดลของ MCP นั้นผิดทาง แทนที่จะให้โมเดลไป “ดึง” ข้อมูลมา ควรใช้วิธี “ผลัก” ข้อมูลบริบทให้ล่วงหน้าจะดีกว่า
  • สิ่งที่น่าสนใจคือช่วงหลังได้ทำภาษา macro extension บนฐาน JSON แล้วพบว่าแท้จริงมันคือการประดิษฐ์ XSLT หรือ XPath ขึ้นใหม่ และก็ประทับใจกับสเปก xpath ที่เก่งมากในการไล่สำรวจ graph เครื่องมืออย่าง BaseX ก็มีประโยชน์มาก เพราะสามารถดึง XML แบบใดก็ได้เข้า DB แล้ว query ด้วย XPATH/XQUERY ได้ ถ้าจะสร้าง data interface ที่แน่นอนเพื่อกัน LLM มั่ว วิธีที่ดีที่สุดน่าจะเป็นการใส่ XML schema ลงใน system prompt แล้วให้มันสร้าง data query ขึ้นมา
  • ยังสงสัยว่าโมเดลแบบ “push บริบทล่วงหน้า” จะรับมือกับปัญหาในโลกจริงได้มากแค่ไหน ถ้าผู้ใช้รู้ข้อมูลล่วงหน้าอยู่แล้ว ก็คงแก้ปัญหาเองไปเลย และความต้องการ MCP ส่วนใหญ่ที่สัมผัสได้คือประมาณว่า “ช่วยจัดการ query ให้หน่อยโดยไม่ต้องไปเรียนวิธีเชื่อมต่อ 15 แหล่งข้อมูล”
  • LLM จัดการ XML ในรูปแบบ tag ได้ดี แต่ในความเป็นจริง คนส่วนใหญ่ไม่ได้ใช้ก้อน XML ที่สมบูรณ์จริง ๆ ที่มี <?xml version="1.0" encoding="UTF-8"?> ขึ้นต้น มี namespace มี schema ฯลฯ แต่เป็นเพียงชุด tag สไตล์ SGML เท่านั้น
  • อยากเน้นเหตุผลที่เป็นจริงมากกว่าว่า สาเหตุแท้จริงที่ semantic web ล้มเหลว คือมันไม่สามารถเชื่อมโยงกับการแทรกโฆษณาหรือโมเดลธุรกิจได้สำเร็จ
  • มีจุดยืนเชิงวิจารณ์ต่อแนวทาง “push บริบท” เพราะความจุในการประมวลผลบริบทของ LLM (context window) มีจำกัดมาก ดังนั้นการส่งเฉพาะข้อมูลที่จำเป็นให้น้อยที่สุดจึงเหมาะที่สุด และจะมีโอกาสก้าวข้ามข้อจำกัดนี้ได้มากเมื่อแต่ละโมเดลสามารถเลือก pull เฉพาะบริบทที่ต้องใช้เอง
• MCP ดูเหมือนจะสร้างความหวังว่าเพราะ AI กำลังได้รับความนิยม แพลตฟอร์มต่าง ๆ จะกลายเป็นสิ่งที่เขียนโปรแกรมได้ไม่ว่าด้วยจุดประสงค์ใดก็ตาม แต่กลับคิดว่ามันมีชะตาจะล้มเหลว เพราะเหตุผลที่ semantic web ล้มเหลวก็คือมันสร้างโครงสร้างรายได้ไม่ได้ ฟังก์ชัน “research” ที่ AI ใช้เจาะลึกเว็บแทนคนก็เช่นกัน เช่น เราเคยสามารถเผยแพร่เมทาดาทาของเมนูร้านอาหารเพื่อให้ระบบอัตโนมัติอย่าง “หาร้านทาโก้ที่ถูกที่สุดในเท็กซัส” ทำงานได้ แต่ความจริงคือกำแพงล็อกข้อมูลและการแข่งขันด้านโครงสร้างพื้นฐานที่ AI crawler พยายามเลี่ยงมัน เมื่อมองภาพใหญ่ก็สรุปได้ว่าระบบปัจจุบันไม่มีประสิทธิภาพ
  • มองว่า MCP สุดท้ายก็เป็นเพียงรูปแบบที่วิวัฒนาการมาจาก robots.txt โดยแก่นแท้คือโมเดลแบบ “ถ้าคุณอธิบายทรัพยากรของคุณให้ดี ฉันก็จะเอาไปใช้” ในอดีตระบบเอเจนต์บน Java ยุค 90 ก็ล้มเหลวเพราะปัญหาความไม่สมมาตรของข้อมูลระหว่างเอเจนต์ และก็ยังกังวลว่าหากลบข้อจำกัดเชิงการออกแบบนี้ออกไป ทั้งสังคมหรือธุรกิจอาจหยุดทำงานได้เลย
  • มองจากประสบการณ์ว่า Open API ยังไม่ทันติดปัญหาเรื่องหารายได้ แต่ในทางปฏิบัติถ้าไม่ทุ่มทรัพยากรแบบแทบไม่จำกัด ก็จะโดนคลื่น request bot จาก AI agent ใช้ทรัพยากรจนหมดและสุดท้ายล้มละลายได้ ในระยะยาวจึงคิดว่าโมเดลค่าบริการ RPC แบบ pay-per-call จะเป็นทางเลือกที่เสถียรกว่า โดยให้ผู้ให้บริการโมเดลหรือเอเจนต์ทำหน้าที่คล้าย clearing house ด้านการชำระเงิน แล้วบวกต้นทุนเข้าไปในค่าสมาชิกหรือค่าบริการอื่น ๆ
  • อุดมคติของสถาปัตยกรรม REST อย่าง HATEOAS เคยฮิตมากในช่วงต้นทศวรรษ 2010 แต่สุดท้ายก็เงียบหายไปโดยแทบไม่มีการต่อยอดจริงนอกจากเครื่องมืออัตโนมัติอย่าง swagger yaml และคิดว่ามันชวนล้มเหลวตั้งแต่คำศัพท์ที่ยากเกินไปแล้ว
  • ไม่เห็นด้วยกับมุมมองที่มองข้อความที่มนุษย์อ่านได้ว่าเป็นกำแพงประดิษฐ์ ตรงกันข้าม การไปคาดหวังให้ร้านอาหารมีทักษะผลิต JSON หรือซื้อซอฟต์แวร์ต่างหากที่เป็นกำแพงประดิษฐ์ ด้วยเครื่องมือ NLP ตอนนี้สามารถนำข้อมูลเดิมมาใช้ได้เลย ทำให้ต้นทุนพัฒนาแทบลดลงเหลือ 0 แม้จะมีความคลุมเครือทางภาษาอยู่บ้าง แต่ก็มองว่านั่นเป็นธรรมชาติของภาษามนุษย์อยู่แล้วจึงไม่ใช่ปัญหาใหญ่
  • แม้จะพูดเรื่องวิจารณ์ semantic web อยู่จึงขอพูดอย่างระมัดระวัง แต่ถ้าเป็นเจ้าของร้านอาหารที่ต้องการจริง ๆ ก็สามารถเผยแพร่เมทาดาทาได้เสมอ และมันอาจเป็นจุดเริ่มต้นที่ช่วยเชื่อมผู้ซื้อกับผู้ขายได้ง่ายขึ้น ยกตัวอย่างปลั๊กอิน WordPress ที่รองรับเมทาดาทาอย่าง schema.org/Restaurant, Menu, MenuItem, Offer อยู่แล้ว ดังนั้นอุปสรรคใหญ่สุดอาจเป็นการ gatekeeping ของบริการอย่าง Cloudflare มากกว่า ซึ่งในทางปฏิบัติก็เป็นปัจจัยที่ขัดขวางไอเดียระบบอัตโนมัติด้วย Python จริง ๆ
• คิดว่าเพราะ LLM สามารถอ่านเอกสาร API และปรับตัวอัตโนมัติได้ การปฏิบัติตามมาตรฐาน API อย่างเคร่งครัดจึงอาจไม่จำเป็นเท่าเดิม ไม่ว่าจะรับ MCP หรือไม่ก็ตาม การที่แต่ละเว็บไซต์ถูกคาดหวังให้ “มี API ให้ใช้” เองก็นับเป็นความเปลี่ยนแปลงครั้งใหญ่แล้ว
  • ในสภาพแวดล้อมจริง เอกสาร API อาจแย่จน LLM สร้างโค้ดหรือคำสั่งเรียกที่ผิดได้ และเมื่อผู้ใช้แก้แล้วส่งกลับให้ LLM สุดท้ายก็ลงเอยด้วยการสร้างชั้นกลางแบบหนึ่งขึ้นมาอยู่ดี ซึ่งก็คือเซิร์ฟเวอร์สไตล์ MCP นั่นเอง อีกทั้งการให้ LLM เข้าถึง API โดยตรงก็มีความเสี่ยงด้านความปลอดภัยและการจัดการทรัพยากร เช่น อาจมีค่าใช้จ่ายพุ่งจากการเรียกใช้งานมากเกินไป ยังมี pain point อื่นอีกหลายอย่าง ซึ่งบางข้อแก้ได้โดยโครงสร้างที่มีอินเทอร์เฟซกลางแบบ MCP แม้คำถามว่า “ตัวกลาง” นั้นจำเป็นต้องเป็น MCP หรือไม่จะเป็นอีกเรื่องหนึ่ง แต่ ณ ตอนนี้มันก็เป็นทางออกที่ใช้งานได้จริงมากพอ
• สิ่งที่น่ากังวลที่สุดใน MCP ไม่ใช่ระดับความไม่สมบูรณ์ของโปรโตคอล แต่คืออำนาจในการปรับปรุงหรือแก้ไขที่กระจุกอยู่กับทีมภายในของบริษัทอย่าง Anthropic และ OpenAI เท่านั้น จึงทำให้ระแวงว่ามันอาจเป็นสเปกที่ยังค้างอยู่แค่ระดับ brainstorming มากกว่ามีฐานจากนักพัฒนาและผู้ปฏิบัติการจริง ให้ความรู้สึกเหมือนเงาของตลาดผูกขาดคู่แบบ Visa-Mastercard
  • มีกรณี Microsoft เข้าร่วม steering committee เช่นกัน
• มีความคาดหวังว่า “semantic web” แท้จริงเป็นเพียงโครงสร้างทางไวยากรณ์ และบางที MCP อาจเป็นสิ่งที่มีความเป็นไปได้เชิงปฏิบัติจริงก็ได้
• มีภาพจำว่า “นักพัฒนา Unix รุ่นเก่าหลัก ๆ จู้จี้เกินไป” แต่ในอีกมุมก็รู้สึกประชดนิด ๆ เพราะจริง ๆ แล้ว Unix นี่เองคือรากของวัฒนธรรม “ลองเร็ว พังเร็ว” ดังนั้นแม้คนละรุ่น แต่แก่นแท้ก็อาจไม่เคยเปลี่ยน
• มีความกังวลตามจริงว่า MCP อาจถูกนำไปใช้ในทางที่ผิด คล้าย SEO ของ Google คือกลายเป็นช่องทางให้โฆษณาและสแปมแพร่กระจายไปสู่ AI
• คิดว่าต้องระวังอย่าหลงเชื่อว่า MCP จะทำให้ทุกคนเข้าถึงข้อมูลสารพัดได้ง่าย ความจริงแล้วสิ่งที่น่าจะเกิดขึ้นมากกว่าคือการติดอยู่กับชั้นการยืนยันการชำระเงินหลายชั้น รายชื่อ white list IP ที่ได้รับอนุญาต และสุดท้ายผู้ใช้จริงก็ได้กลับมาเพียงข้อผิดพลาด “ERR 402” เท่านั้น