MCP vs API: ควรใช้ MCP หรือ HTTP ตรงสำหรับเครื่องมือ AI

เมื่อเชื่อมต่อ AI agent กับเครื่องมือและ API ภายนอก มีแนวทางหลักสองแบบ: ใช้ Model Context Protocol (MCP) เป็นชั้น abstraction หรือเรียก API โดยตรงผ่าน HTTP ทั้งสองแบบใช้งานได้ แต่มีข้อแลกเปลี่ยนต่างกันในด้านความยืดหยุ่น ความซับซ้อน ประสิทธิภาพ และการพกพา

บทความนี้เปรียบเทียบสองแนวทางด้วยตัวอย่างโค้ดที่เป็นรูปธรรม การวิเคราะห์เวลาแฝง และกรอบการตัดสินใจสำหรับเลือกใช้งาน

สองแนวทาง

การเชื่อมต่อ HTTP โดยตรง

แอปพลิเคชัน AI (หรือ backend ของแอป) เรียก API ภายนอกโดยตรงด้วย HTTP request มาตรฐาน นักพัฒนาเขียนโค้ดเพื่อสร้าง request จัดการ authentication แปลง response และส่งผลลัพธ์กลับไปให้ LLM

┌──────┐     ┌────────┐                        ┌─────────────┐
│ User │────▶│ AI App │──── HTTP request ─────▶│ Weather API │
└──────┘     │        │◀─── JSON response ─────│             │
             │        │                        └─────────────┘
             │        │── result as context ──▶ LLM
             │        │◀── formatted answer ───
             └───┬────┘
                 │
                 ▼
           User gets answer

การเชื่อมต่อ MCP

แอปพลิเคชัน AI เชื่อมต่อกับ MCP server ที่ห่อหุ้ม API ภายนอกไว้ แอปพลิเคชันใช้โปรโตคอล MCP เพื่อค้นหาเครื่องมือที่มี เรียกเครื่องมือตามชื่อ และรับผลลัพธ์ MCP server จัดการการเรียก HTTP จริงไปยัง API ภายนอก

┌──────┐     ┌───────────────────┐              ┌────────────┐     ┌──────────┐
│ User │────▶│ AI App/MCP Client │── JSON-RPC ─▶│ MCP Server │────▶│ HTTP API │
└──────┘     │                   │◀─ JSON-RPC ──│            │◀────│          │
             │                   │              └────────────┘     └──────────┘
             │                   │── result as context ──▶ LLM
             │                   │◀── formatted answer ───
             └─────────┬─────────┘
                       │
                       ▼
                 User gets answer

ความแตกต่างสำคัญคือ เมื่อใช้ HTTP โดยตรง แอปพลิเคชัน AI เป็นเจ้าของโค้ดเชื่อมต่อ API เมื่อใช้ MCP, MCP server เป็นเจ้าของโค้ดส่วนนั้น และแอปพลิเคชัน AI เพียงเรียกเครื่องมือตามชื่อ

คุณสามารถมีฝั่ง MCP ตามไดอะแกรมนี้ได้โดยไม่ต้องสร้าง server เอง: Quickchat AI โฮสต์ MCP server แบบ streamable-HTTP สำหรับ AI Agent ทุกตัว และการเปลี่ยน agent ของคุณให้เป็น MCP server ทำได้ด้วยการวาง URL หนึ่งรายการลงในแอป AI

เปรียบเทียบโค้ด

มาเปรียบเทียบทั้งสองแนวทางด้วยตัวอย่างที่ใช้งานได้จริง: การดึง repository ของผู้ใช้ GitHub

การเชื่อมต่อ HTTP โดยตรง

import httpx

async def get_user_repos(username: str, token: str) -> list[dict]:
    """ดึง repositories สำหรับผู้ใช้ GitHub"""
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"https://api.github.com/users/{username}/repos",
            headers={
                "Authorization": f"Bearer {token}",
                "Accept": "application/vnd.github.v3+json",
                "X-GitHub-Api-Version": "2022-11-28"
            },
            params={"sort": "updated", "per_page": 10}
        )
        response.raise_for_status()
        repos = response.json()
        return [
            {
                "name": r["name"],
                "description": r["description"],
                "stars": r["stargazers_count"],
                "language": r["language"],
                "url": r["html_url"]
            }
            for r in repos
        ]

หากต้องการเชื่อมต่อสิ่งนี้กับ LLM คุณยังต้องมี:

• คำจำกัดความของเครื่องมือในรูปแบบที่ LLM คาดหวัง (OpenAI function calling schema, Claude tool use schema เป็นต้น)
• โค้ดเพื่อแปลง tool call ของ LLM เรียก get_user_repos และใส่ผลลัพธ์กลับเข้าไปในบทสนทนา
• การจัดการข้อผิดพลาดสำหรับ HTTP failure, rate limit และ auth expiration

MCP server

from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("github-server")

GITHUB_TOKEN = os.environ["GITHUB_TOKEN"]

@mcp.tool()
async def get_user_repos(username: str) -> str:
    """ดึง repositories 10 รายการที่อัปเดตล่าสุดสำหรับผู้ใช้ GitHub

    Args:
        username: ชื่อผู้ใช้ GitHub ที่ต้องการค้นหา
    """
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"https://api.github.com/users/{username}/repos",
            headers={
                "Authorization": f"Bearer {GITHUB_TOKEN}",
                "Accept": "application/vnd.github.v3+json",
                "X-GitHub-Api-Version": "2022-11-28"
            },
            params={"sort": "updated", "per_page": 10}
        )
        response.raise_for_status()
        repos = response.json()
        lines = []
        for r in repos:
            stars = r["stargazers_count"]
            lang = r["language"] or "unknown"
            lines.append(f"- {r['name']} ({lang}, {stars} stars): {r['description'] or 'ไม่มีคำอธิบาย'}")
        return "\n".join(lines)

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

เวอร์ชัน MCP ห่อหุ้มการเรียก API, authentication และการจัดรูปแบบ response ไว้ภายใน server client ที่รองรับ MCP ใด ๆ สามารถใช้เครื่องมือนี้ได้โดยไม่ต้องรู้อะไรเกี่ยวกับ GitHub API

สิ่งที่เปลี่ยนไปสำหรับแอปพลิเคชัน AI

เปรียบเทียบประสิทธิภาพ

MCP เพิ่มชั้นหนึ่งระหว่างแอปพลิเคชัน AI กับ API ภายนอก ชั้นนั้นมีต้นทุน

เวลาแฝง

สำหรับ stdio transport (MCP server ภายในเครื่อง) overhead ต่ำมาก: การ spawn process ตอนเริ่มต้น (ครั้งเดียว โดยทั่วไปต่ำกว่า 100ms) และการสื่อสารระหว่าง process ต่อข้อความ (ต่ำกว่ามิลลิวินาทีบนระบบสมัยใหม่) ในทางปฏิบัติ การเรียก API ภายนอกเป็นส่วนที่ครองเวลาแฝงรวม

สำหรับ remote MCP servers (Streamable HTTP หรือ SSE) คุณเพิ่ม HTTP round-trip หนึ่งครั้งระหว่าง client กับ MCP server รวมถึง HTTP round-trip ของ MCP server ไปยัง API ภายนอก หาก MCP server และ API ภายนอกอยู่ร่วมตำแหน่งกัน overhead นี้จะน้อย (ระดับมิลลิวินาทีหลักเดียว) หากอยู่คนละ region ก็จะทบเพิ่มขึ้น อย่างไรก็ตาม transport แทบไม่ใช่สิ่งที่ผู้ใช้รู้สึก: ระหว่างสร้าง help-center agent บน MCP server ที่ Notion โฮสต์ tool call 248 ครั้งใช้เวลาเฉลี่ยครั้งละ 2.7 วินาที โดยเกือบทั้งหมดเป็นเวลาที่ Notion ใช้ค้นหาและ render หน้า ไม่ใช่ hop ระหว่างกลาง

สำหรับกรณีใช้งาน AI agent ส่วนใหญ่ ซึ่งการ inference ของ LLM ใช้เวลา 500ms-5s, overhead ของ MCP ถือว่าเล็กน้อย

การจัดการ connection

HTTP โดยตรง: แอปพลิเคชันของคุณจัดการ connection ไปยัง API ภายนอกแต่ละตัว ซึ่งหมายถึงการจัดการ connection pool, retry logic และ rate limiting ต่อ API

MCP: แอปพลิเคชันของคุณจัดการหนึ่ง connection ต่อ MCP server server จัดการ connection ไปยัง API ภายนอก หากคุณมีเครื่องมือ 10 รายการกระจายอยู่ใน MCP server 3 ตัว คุณจัดการ 3 connection แทนที่จะเป็น 10

ควรใช้ MCP เมื่อใด

การเชื่อมต่อเครื่องมือหลายรายการ

หากแอปพลิเคชัน AI ของคุณต้องเชื่อมต่อกับบริการภายนอก 5 รายการขึ้นไป MCP ช่วยลดภาระการเชื่อมต่อ แทนที่จะเขียนและดูแล custom API client สำหรับแต่ละบริการ คุณเชื่อมต่อกับ MCP server (จำนวนมากมีให้ใช้เป็นโครงการ open-source)

การพกพาข้ามแพลตฟอร์ม AI

หากคุณสร้าง MCP server สำหรับเครื่องมือของคุณ server เหล่านั้นจะทำงานกับ MCP client ใดก็ได้: Claude Desktop, Cursor, Windsurf, custom applications และแพลตฟอร์มอย่าง Quickchat AI เมื่อใช้ HTTP โดยตรง คุณจะต้อง implement คำจำกัดความเครื่องมือใหม่สำหรับรูปแบบของแต่ละแพลตฟอร์ม

การค้นหาเครื่องมือแบบ dynamic

MCP รองรับการค้นหาเครื่องมือขณะ runtime ผ่าน tools/list แอปพลิเคชัน AI สามารถเชื่อมต่อกับ server และเรียนรู้ว่ามีเครื่องมือใดบ้างโดยไม่ต้องมี configuration ที่ hardcode ไว้ สิ่งนี้มีประโยชน์สำหรับสถานการณ์ที่เครื่องมือเปลี่ยนบ่อย หรือให้ผู้ใช้ตั้งค่าได้

การแยกความรับผิดชอบ

หากทีมต่างกันเป็นเจ้าของเครื่องมือต่างกัน MCP ให้ขอบเขตที่ชัดเจน ทีมที่เป็นเจ้าของการเชื่อมต่อ Salesforce สร้างและดูแล Salesforce MCP server ทีมแอปพลิเคชัน AI เชื่อมต่อไปยัง server นั้นโดยไม่ต้องเข้าใจ API ของ Salesforce การอัปเดต Salesforce API จะถูกจัดการใน MCP server โดยไม่ต้องแตะแอปพลิเคชัน AI

ควรใช้ HTTP โดยตรงเมื่อใด

การเชื่อมต่อหนึ่งหรือสองรายการ

หาก AI agent ของคุณต้องเรียก API เพียงตัวเดียว (เช่น การ lookup ฐานข้อมูล) overhead ของการรัน MCP server ไม่จำเป็น การเรียก HTTP โดยตรงง่ายกว่าและมีชิ้นส่วนที่ต้องจัดการน้อยกว่า

คุณไม่จำเป็นต้องเขียน request ด้วยมือเช่นกัน plain-English API Action builder อ่าน REST API ที่มีเอกสาร สร้าง method, URL, parameters และ description จากนั้นให้คุณทดสอบ response จริงก่อนเปิดใช้งาน

การควบคุม request สูงสุด

MCP server ซ่อนรายละเอียด HTTP หากคุณต้องควบคุมการสร้าง request อย่างละเอียด (header เฉพาะ, query parameter, request signing หรือ authentication ที่ไม่เป็นมาตรฐาน) HTTP โดยตรงให้การควบคุมนั้นโดยไม่ต้องขัดกับชั้น abstraction

งานที่ไวต่อเวลาแฝง

หากทุกมิลลิวินาทีมีความสำคัญ (เช่น voice agent แบบ real-time ที่ tool call ต้องเสร็จภายในงบเวลาที่เข้มงวด) การนำชั้น MCP ออกจะตัด hop หนึ่งครั้ง

HTTP call ที่ไม่ใช่ AI

หาก HTTP call ไม่ได้ถูก trigger โดย AI agent (เช่น backend cron job ที่ sync ข้อมูล) MCP ไม่เกี่ยวข้อง MCP ถูกออกแบบมาโดยเฉพาะสำหรับการสื่อสารจาก AI ไปยังเครื่องมือ บริการ backend ปกติควรใช้ HTTP client ปกติ

แนวทางแบบ hybrid

ระบบ production จำนวนมากใช้ทั้งสองแบบ รูปแบบคือ:

• MCP สำหรับการเชื่อมต่อเครื่องมือที่ AI agent เรียกระหว่างบทสนทนา (CRM lookup, การสร้าง ticket, การ query knowledge base)
• Direct HTTP สำหรับการทำงาน backend ภายใน, webhook และการสื่อสารแบบ system-to-system

นี่คือวิธีที่ Quickchat AI ทำงานภายใน แพลตฟอร์มรองรับทั้ง HTTP Request Actions (การเรียก API โดยตรงพร้อม parameter templating) และ Remote MCP Actions (connection ไปยัง MCP server ภายนอก) คุณเลือกแนวทางที่เหมาะสมสำหรับแต่ละ integration:

สำหรับการเปรียบเทียบโดยละเอียดว่าวิธีนี้ทำงานอย่างไรในทางปฏิบัติ รวมถึงความแตกต่างระหว่าง GPT Actions ของ OpenAI กับ MCP โปรดดู GPT Actions vs MCP

กรอบการตัดสินใจ

ใช้ flowchart นี้เพื่อเลือก:

1. AI agent เป็นผู้เรียกเครื่องมือหรือไม่ หากไม่ใช่ (เป็น backend operation) ให้ใช้ HTTP โดยตรง
2. คุณต้องใช้เครื่องมือภายนอกกี่รายการ หาก 1-2 รายการ HTTP โดยตรงง่ายกว่า หาก 3 รายการขึ้นไป ให้พิจารณา MCP
3. มี MCP server ที่สร้างไว้แล้วสำหรับบริการนั้นหรือไม่ หากมี การใช้ server นั้นช่วยประหยัดเวลา development
4. คุณต้องการให้ integration ทำงานได้บนหลายแพลตฟอร์ม AI หรือไม่ หากใช่ MCP ให้การพกพา
5. เวลาแฝงเป็นเรื่องสำคัญมากหรือไม่ (งบต่ำกว่า 100ms สำหรับ tool call) หากใช่ ให้ benchmark overhead ของ MCP แล้วตัดสินใจตามผล
6. ทีมต่างกันเป็นเจ้าของ integration ต่างกันหรือไม่ หากใช่ โมเดลหนึ่ง server ต่อหนึ่ง integration ของ MCP ช่วยเรื่องขอบเขตความเป็นเจ้าของ

ในทางปฏิบัติ หากคุณกำลังสร้าง AI agent ที่ต้องโต้ตอบกับบริการภายนอก MCP กำลังกลายเป็นตัวเลือกเริ่มต้นมากขึ้น ecosystem ของ server ที่สร้างไว้แล้วมีขนาดใหญ่พอที่คุณมักเริ่มต้นได้โดยไม่ต้องเขียนโค้ด server เลย

อ่านเพิ่มเติม

• เชื่อมต่อ AI Agent ของคุณกับ Remote MCP Server: มอบเครื่องมือแบบ live ให้ agent ของคุณแบบทีละขั้นตอน
• Model Context Protocol ทำงานอย่างไร อธิบาย MCP: บทนำ MCP
• GPT Actions vs MCP: เปรียบเทียบกับแนวทางของ OpenAI
• ข้อกำหนด MCP: ข้อกำหนดโปรโตคอลอย่างเป็นทางการ
• HubSpot AI Actions: ตัวอย่าง AI actions ที่ใช้ HTTP ในการใช้งานจริง
• เหตุการณ์ OpenAI Hugging Face สิ่งที่เกิดขึ้นจริง: อธิบายเหตุการณ์ทีละขั้นตอน และความหมายที่แท้จริงของการ hacking