Model Context Protocol (MCP): วิธีเชื่อมต่อ AI เข้ากับเครื่องมือของคุณ

ปรับปรุงล่าสุด: July 26, 2026

MCP — Model Context Protocol — เป็นมาตรฐานเปิดที่ Anthropic เปิดตัวเมื่อปลายปี 2024 สำหรับการเชื่อมต่อ AI assistants และ agents เข้ากับแหล่งข้อมูลภายนอกและเครื่องมือต่างๆ แทนที่จะต้องเขียนการผสานรวมเฉพาะสำหรับทุกโมเดลและทุกเครื่องมือ คุณเพียงแค่เปิดเผย MCP server ตัวเดียว และไคลเอนต์ที่เข้ากันได้กับ MCP ใดๆ ก็สามารถใช้งานมันได้ เมื่อสัปดาห์ที่แล้ว ผมเชื่อมต่อ filesystem server และ GitHub server เข้ากับ Claude Code และความแตกต่างในสิ่งที่เอเจนต์สามารถทำได้จริงนั้นเกิดขึ้นทันที บทความนี้จะครอบคลุมว่า MCP คืออะไร โมเดล client-server ทำงานอย่างไร ประเภทของความสามารถหลัก และวิธีการรันเซิร์ฟเวอร์ในระบบของคุณเอง

คำตอบสั้นๆ: MCP คืออะไร?

MCP เป็นโปรโตคอลที่อิงตาม JSON-RPC 2.0 ซึ่งทำหน้าที่กำหนดมาตรฐานการเชื่อมต่อระหว่างแอปพลิเคชันโฮสต์ AI (หรือ client ของ MCP เช่น Claude Desktop หรือ Claude Code) กับ servers ภายนอกที่เปิดเผยข้อมูลและการดำเนินการต่างๆ เซิร์ฟเวอร์ MCP เพียงตัวเดียวสามารถประกาศประเภทความสามารถได้สามประเภทแก่ไคลเอนต์:

• Tools — ฟังก์ชันที่โมเดลสามารถเรียกใช้ได้ (เช่น การสอบถามฐานข้อมูล, การส่งข้อความ, การค้นหา repo)
• Resources — ข้อมูลที่มีโครงสร้างที่โมเดลสามารถอ่านได้ (เช่น เนื้อหาไฟล์, API responses, records)
• Prompts — เทมเพลต prompt ที่นำกลับมาใช้ใหม่และมีการกำหนดพารามิเตอร์ให้ผู้ใช้เรียกใช้งาน

เป้าหมายคือการเป็น "USB-C สำหรับการผสานรวม AI": เซิร์ฟเวอร์เดียวสำหรับไคลเอนต์จำนวนมาก โดยไม่ต้องมีส่วนเชื่อมต่อเฉพาะโมเดล (per-model glue) ข้อกำหนด (spec) และ SDKs เป็นแบบ open source และดูแลอยู่ที่ modelcontextprotocol บน GitHub พร้อมด้วยเอกสารมาตรฐานที่ modelcontextprotocol.io

ทำไม MCP ถึงมีอยู่?

ก่อนมี MCP การรวมเครื่องมือทุกอย่างจะเป็นการทำแบบเฉพาะกิจ หากคุณต้องการให้ผู้ช่วยอ่านปัญหา GitHub ของคุณและสอบถามข้อมูลจาก Postgres คุณจะต้องเขียนตัวเชื่อมต่อที่กำหนดเองถึงสองตัว จากนั้นก็ต้องเขียนใหม่เมื่อเปลี่ยนโมเดลหรือโฮสต์ แรงจูงใจที่ Anthropic ระบุคือการยุติความซ้ำซ้อนนี้ด้วยโปรโตคอลที่ใช้ร่วมกัน — official docs อธิบายว่าเป็นการให้ "standardized access" แก่ models สำหรับ local files, databases, และ APIs

กรอบความคิดนี้มีความสำคัญอย่างยิ่งสำหรับ agentic workflows โดยเฉพาะ Agent ที่ทำได้แค่แชทคือ chatbot; ส่วน agent ที่สามารถอ่าน repo ของคุณ รัน query และเรียกใช้ tool ในลูปได้ คือ worker ตัวจริง MCP เป็นระบบโครงสร้างพื้นฐานที่ทำให้ตัวหลังพกพาได้ หากคุณต้องการภาพรวมว่าสิ่งนี้เข้ากับงานออกแบบ agent ได้อย่างไร โปรดดู our post on AI agent automation

การทำงานของโมเดลไคลเอนต์-เซิร์ฟเวอร์เป็นอย่างไร?

MCP ใช้โทโพโลยีแบบโฮสต์-ไคลเอนต์-เซิร์ฟเวอร์:

• Host — แอปพลิเคชันที่ผู้ใช้รัน (เช่น Claude Desktop, Claude Code, ส่วนขยายของ IDE)
• Client — อาศัยอยู่ภายในโฮสต์ รักษาเซสชันแบบ 1:1 กับเซิร์ฟเวอร์หนึ่งตัว
• Server — กระบวนการที่เปิดเผยความสามารถผ่านระบบขนส่ง (transport)

โฮสต์สามารถรันไคลเอนต์ได้หลายตัว โดยแต่ละตัวจะสื่อสารกับเซิร์ฟเวอร์หนึ่งตัว โปรโตคอลที่ใช้คือ JSON-RPC 2.0 ซึ่งมีสามระยะของวงจรชีวิตที่ฉันทดสอบทุกครั้งที่เพิ่มเซิร์ฟเวอร์ใหม่:

1. Initialize — ไคลเอนต์ส่งเวอร์ชันโปรโตคอล ความสามารถ และข้อมูลไคลเอนต์; เซิร์ฟเวอร์ตอบกลับด้วยของตัวเอง
2. Capability negotiation — ทั้งสองฝ่ายประกาศสิ่งที่พวกเขารองรับ (เครื่องมือ ทรัพยากร prompt การสุ่ม ตัวราก)
3. Operation — ไคลเอนต์ร้องขอรายการเครื่องมือ เรียกใช้เครื่องมือ อ่านทรัพยากร และเซิร์ฟเวอร์จะสตรีมผลลัพธ์กลับมา

ตัวเลือกการขนส่ง (Transport options)

stdio เป็นค่าเริ่มต้นสำหรับการตั้งค่าในเครื่อง และเป็นสิ่งที่ claude mcp add ใช้ เว้นแต่คุณจะระบุ URL แบบ HTTP สำหรับการดูรายละเอียดเชิงลึกของ claude mcp add และการตัดสินใจระหว่าง stdio กับ HTTP โปรดดู คู่มือการผสานรวม Claude Code MCP ของเรา

ประเภทความสามารถทั้งสามมีอะไรบ้างในทางปฏิบัติ?

มูลค่าส่วนใหญ่ของ MCP อยู่ที่ประเภทความสามารถทั้งสามนี้ นี่คือวิธีที่แต่ละอย่างทำงานจริงเมื่อโมเดลใช้งานมัน

Tools (model-invoked)

Tools คือกลไกหลัก โมเดลจะตัดสินใจเรียกใช้เครื่องมือเหล่านี้ตามการสนทนา ตัวอย่างเช่น ผมได้รันเซิร์ฟเวอร์ที่เปิดเผย search_logs tool และโมเดลก็เรียกใช้โดยไม่ได้ถูกกระตุ้นทันทีที่ผมถามว่า "ทำไมการ deploy ถึงล้มเหลวตอนตี 2?" คำจำกัดความของ Tool จะรวมถึง JSON Schema สำหรับอาร์กิวเมนต์ ทำให้โมเดลได้รับอินพุตที่มีประเภทและผ่านการตรวจสอบแล้ว

Resources (app-controlled)

Resources ถูกระบุด้วย URI และโดยทั่วไปจะเป็นสิ่งที่ ผู้ใช้เลือก ไม่ใช่ที่โมเดลเลือก — ผู้ใช้จะแนบ Resource เช่น ไฟล์หรือบันทึก และโฮสต์ก็จะฉีดมันเข้าไปในบริบท สิ่งนี้สำคัญสำหรับการควบคุมขอบเขต: โมเดลสามารถเห็นได้เฉพาะสิ่งที่คุณมอบให้มันอย่างชัดเจนเท่านั้น

Prompts (user-invoked)

Prompts คือเทมเพลตที่มีอาร์กิวเมนต์ที่แสดงขึ้นใน UI ของโฮสต์เป็น slash-commands หรือรายการเมนู พวกเขาคือความสามารถที่ถูกใช้น้อยที่สุด — ผมใช้พวกเขาเพื่อเข้ารหัส "review this PR against our style guide" เพื่อที่ผมจะได้ไม่ต้องวางคำสั่งเดิมซ้ำ ๆ ทุกครั้ง

วิธีตั้งค่าเซิร์ฟเวอร์ MCP อย่างไร?

การตั้งค่าที่เป็นรูปธรรม โดยใช้ Claude Code เป็นโฮสต์ การกำหนดค่าเซิร์ฟเวอร์เดียวกันนี้สามารถใช้งานได้ในไฟล์ JSON ของ Claude Desktop

1. ติดตั้ง Node.js 20+ (หรือ Python 3.10+ ด้วย uv)
2. เพิ่มเซิร์ฟเวอร์อ้างอิง ตัวอย่างเช่น เซิร์ฟเวอร์ระบบไฟล์: npx -y @modelcontextprotocol/server-filesystem /Users/you/projects
3. ลงทะเบียนใน Claude Code: claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem /Users/you/projects
4. ตรวจสอบการเชื่อมต่อ: claude mcp list แล้วตามด้วย claude mcp get filesystem
5. รีสตาร์ทโฮสต์และมองหาเครื่องมือของเซิร์ฟเวอร์ในเซสชัน

นั่นคือวงจรทั้งหมด เซิร์ฟเวอร์อ้างอิงใน GitHub org ครอบคลุมระบบไฟล์, Git, GitHub, Postgres, SQLite, Slack, Google Drive, Puppeteer และอื่น ๆ อีกมากมาย

เซิร์ฟเวอร์ที่กำหนดเองแบบน้อยที่สุด (Python)

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("status")

@mcp.tool()
def healthcheck(service: str) -> str:
    """Return the current status of a service."""
    return f"{service}: ok"

if __name__ == "__main__":
    mcp.run(transport="stdio")

ฉันได้ทดสอบสิ่งนี้กับปลายทาง staging ในเวลาประมาณสิบนาที รวมถึงการเชื่อมต่อมันเข้ากับ Claude Code สำหรับรูปแบบที่กว้างขึ้นในการเปิดเผยบริการภายในเป็น APIs ที่เรียกใช้โดย agent, คู่มือพัฒนา AI API ของเรา จะเจาะลึกยิ่งขึ้นเกี่ยวกับ auth และ rate-limiting.

ภาพรวมของระบบนิเวศในปี 2026

ระบบนิเวศได้มีการรวมตัวกันรอบๆ official registry และเซิร์ฟเวอร์อ้างอิงที่ได้รับการดูแลอย่างดีจำนวนหนึ่ง ผมจึงรวบรวมรายการสั้น ๆ ของสิ่งที่ผมเชื่อถือในการใช้งานจริง (production):

• filesystem — การอ่าน/เขียนไฟล์ในเครื่องพร้อมข้อจำกัดของ root
• github — issues, PRs, search, file operations
• postgres / sqlite — ค่าเริ่มต้นเป็น read-only, schema introspection
• puppeteer / playwright — browser automation สำหรับ agents
• slack — การอ่าน channel และการส่ง message

สำหรับการควบคุมเซิร์ฟเวอร์หลายตัวที่อยู่เบื้องหลัง subagents — โดยที่ subagent ตัวหนึ่งเป็นเจ้าของ database และอีกตัวเป็นเจ้าของ browser — our post on Claude Code subagents ได้อธิบายรูปแบบทีมไว้แล้ว

สิ่งที่คุณควรระวังมีอะไรบ้าง?

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

• ให้ถือว่าแต่ละเซิร์ฟเวอร์เป็นเหมือน dependency กำหนดเวอร์ชัน (Pin versions) และตรวจสอบแหล่งที่มาก่อนรัน npx บน repo ของคนแปลกหน้า เครื่องมือที่เป็นอันตรายสามารถส่งข้อมูลใด ๆ ที่ model เห็นออกไปได้
• จำกัดสิทธิ์ root เซิร์ฟเวอร์ระบบไฟล์จะปลอดภัยเท่ากับไดเร็กทอรีที่คุณชี้ไปเท่านั้น — ห้ามส่ง / เด็ดขาด
• ควรใช้การตั้งค่าฐานข้อมูลแบบ read-only จนกว่าคุณจะมีเหตุผลที่ชัดเจนในการเปิดใช้งานการเขียน (writes)
• ระวัง prompt injection หากเครื่องมือใด ๆ ส่งเนื้อหากลับมาและ model นำไปดำเนินการต่อ ข้อมูลที่ไม่น่าเชื่อถืออาจกลายเป็นคำสั่งได้ ให้สันนิษฐานว่าทรัพยากรใด ๆ ก็ตามเป็นอันตราย
• จำกัดขอบเขตของ OAuth tokens โทเคน Slack และ GitHub ควรมีขอบเขตที่น้อยที่สุดเท่าที่เซิร์ฟเวอร์ต้องการ ไม่ใช่โทเคนส่วนตัวของคุณ

ฉันเริ่มต้นเซิร์ฟเวอร์ใหม่ทุกครั้งในบัญชีแบบ sandboxed และสังเกตการเรียกใช้เครื่องมือ (tool calls) สองสามครั้งแรกก่อนที่จะเชื่อถือมันในการใช้งานจริง

ข้อสรุปที่สำคัญ

MCP เป็นโปรโตคอลขนาดเล็กที่แก้ไขปัญหาจริง: มันช่วยให้เซิร์ฟเวอร์หนึ่งสามารถเปิดเผย tools, resources, และ prompts ให้กับ AI host ที่เข้ากันได้ทุกตัว ซึ่งเป็นการขจัดภาระการรวมระบบแบบ N-times-M กลไกของมันนั้นเรียบง่าย — initialize, negotiate, operate over stdio หรือ HTTP — แต่ท่าทีด้านความปลอดภัย (safety posture) คือส่วนที่กำหนดว่ามันควรอยู่ใน workflow ของคุณหรือไม่ คุณต้องรันเซิร์ฟเวอร์ที่คุณสามารถตรวจสอบได้ กำหนดขอบเขต credentials อย่างเข้มงวด และสมมติว่า input ที่ไม่น่าเชื่อถือเป็นอันตราย หากทำเช่นนั้น MCP ก็คือวิธีที่สะอาดที่สุดในการเปลี่ยน assistant ให้กลายเป็น agent ที่สามารถเข้าถึงระบบของคุณได้จริง

เครดิตรูปภาพ

• แสดงโค้ดต้นฉบับบนหน้าจอเฝ้าดู — ภาพถ่ายโดย Markus Spiske จาก Pexels
• นักพัฒนาที่กำลังพิมพ์บนแล็ปท็อปขณะกำหนดค่าเซิร์ฟเวอร์ในเทอร์มินัล — ภาพถ่ายโดย Vlada Karpovich จาก Pexels
• องค์ประกอบแผงวงจรนามธรรมที่เป็นสัญลักษณ์ของสถาปัตยกรรมแบบเลเยอร์ — ภาพถ่ายโดย Christina Morillo จาก Pexels