mcporter x MCP: ทำไมการ “เรียก tools ข้ามค่าย” ถึงทำให้ multi-model ใช้งานจริงได้ (Technical Deep Dive)

by

Technical deep dive: ทำไม mcporter + MCP ถึงเป็น “สะพาน” ที่ทำให้ Claude / OpenClaw Agents เรียก Gemini tools ได้แบบเป็นระบบ (พร้อมข้อควรระวังเรื่อง auth/permission)

mcporter MCP bridge diagram

1) ภาพรวม: ไดอะแกรมนี้กำลังบอกอะไร

โครงสร้างในภาพแบ่งได้เป็น 3 ชั้น:

  1. Clients: Claude CLI, OpenClaw Agents, Gemini CLI
  2. Bridge/Middleware: OpenClaw skill (mcporter) + MCP server + auth
  3. Tool layer: ชุดความสามารถเฉพาะทางของ Gemini เช่น gemini_summarize, gemini_review_code, gemini_vision ฯลฯ

2) MCP แบบเข้าใจง่าย (แต่ไม่ผิวเผิน)

MCP (Model Context Protocol) คือ “มาตรฐานการเรียก tools” ที่ทำให้ฝั่ง client (LLM/agent) เรียกฟังก์ชันภายนอกได้แบบเป็นสัญญาเดียวกัน (contract) แทนที่จะต้องเขียน integration เฉพาะรายทีละเจ้า

สิ่งที่ได้จากมาตรฐาน:

  • Discoverability: client สามารถ “list tools + schema” ได้
  • Separation of concerns: LLM คิด/วางแผน แต่ server เป็นคน “ทำงานจริง” ผ่าน tool
  • Governance: วาง policy/permission/logging ไว้ที่ฝั่ง tool server ได้

3) mcporter ทำหน้าที่อะไร (ในเชิงสถาปัตยกรรม)

ถ้ามองเป็นระบบผลิตงานจริง mcporter คือ tool gateway ที่ช่วย:

  • รวม tool หลายตัวให้อยู่หลัง endpoint/เซิร์ฟเวอร์เดียว
  • ทำให้ client ฝั่ง Claude/OpenClaw เรียก tool ได้ด้วยรูปแบบเดียว (call)
  • พ่วงชั้น auth (ในภาพมีคำว่า must login) ก่อนจะอนุญาตให้ยิงไปหา Gemini tools

Flow ตามภาพ (ละเอียดขึ้น)

  1. Client ส่ง intent/คำสั่ง → ไปที่ mcporter
  2. mcporter route ไป MCP server (transport อาจเป็น HTTP หรือ STDIO ตามที่ตั้งไว้)
  3. MCP server ตรวจ auth session (เช่น OAuth login ของ Gemini CLI)
  4. ผ่านแล้วจึง dispatch ไปยัง tool ที่เหมาะกับงาน
  5. ส่งผลกลับให้ agent ใช้ต่อ (เช่น สรุป → เอาไปเขียนโพสต์, review_code → เอาไปเปิด PR)

4) ทำไม “multi-model” ถึงควรคิดเป็น tool ไม่ใช่ chat

คนส่วนใหญ่ใช้ LLM แบบ “สลับแชท”: งานสรุปไปค่ายนึง งานดูภาพไปอีกค่ายนึง งานรีวิวโค้ดไปอีกที่… ผลคือ context แตก, ทำซ้ำ, และควบคุมความเสี่ยงยาก

แนวคิดในภาพทำให้เราเปลี่ยน mental model เป็น:

  • Agent = orchestrator (วางแผน/ตัดสินใจ)
  • Tools = capabilities (ทำงานเฉพาะทาง)
  • MCP = contract (สัญญาเรียกใช้ + schema + policy)

5) เจาะ 8 Gemini tools: ใช้เมื่อไหร่ดี

  • gemini_prompt: ใช้เป็น “brainstorm/rewriter” แบบเร็ว
  • gemini_summarize: สรุป docs/logs/บทความ แล้วคืนเป็น bullet ที่ใช้ต่อได้
  • gemini_review_code: ช่วยชี้ risk/edge cases/สไตล์การเขียนก่อนส่ง PR
  • gemini_execute_code: ให้ช่วยตรวจ logic/คำนวณ/จำลอง (เหมาะกับงาน verify)
  • gemini_json: บังคับเอาผลลัพธ์ให้เป็นโครงสร้าง (ดีมากกับ pipeline/automation)
  • gemini_second_opinion: ถก trade-off สถาปัตยกรรม/การเลือกเครื่องมือ
  • gemini_vision: อ่านไดอะแกรม/สกรีนช็อต/UX แล้วดึงข้อมูลออกมา
  • gemini_analyze_pdf: สรุป/ถามตอบเอกสาร PDF

6) Security/Permission: จุดที่ “ของจริง” มักพัง

ในระบบที่ agent เรียก tool ได้ ความเสี่ยงไม่ใช่แค่ “ตอบผิด” แต่คือ “ทำผิด” ในระบบจริง ดังนั้นชั้น auth และ least privilege สำคัญมาก

Checklist (เชิงแนวคิด):

  • Auth ก่อน call: ต้อง login/มี token ที่ถูก scope
  • Tool allowlist: จำกัดว่า agent เรียก tool ไหนได้บ้าง
  • Approval gate: งาน publish/post/deploy ควรมีขั้น approve
  • Logging: เก็บว่าเรียก tool อะไร ด้วย args ประเภทไหน (แต่ไม่ log secrets)

7) Use-cases ที่เอาไปใช้ได้ทันที (แบบไม่แจก config copy-paste)

  1. Content pipeline: summarize → rewrite (#มอลลี่) → publish blog → schedule social
  2. Dev workflow: review_code → second_opinion → generate checklist → สรุปใส่ PR
  3. Ops / incident: summarize logs → json extraction → timeline สั้น ๆ ส่งทีม

References

  • MCP: https://modelcontextprotocol.io/
  • mcporter: http://mcporter.dev
  • Gemini CLI: https://github.com/google-gemini/gemini-cli

Leave a Comment