คู่มือทดสอบเซิร์ฟเวอร์ MCP: แบบแมนนวล + อัตโนมัติด้วย Apidog

โพสต์ “Ableton Live MCP” Show HN ได้รับ 118 คะแนนและ 78 ความคิดเห็นเมื่อต้นสัปดาห์นี้ รูปแบบนี้คุ้นเคยกันดีในตอนนี้: มีคนเขียนเซิร์ฟเวอร์ Model Context Protocol สำหรับเครื่องมือที่ไม่น่าจะเป็นไปได้ กลุ่มผู้ใช้ Claude Desktop ชื่นชอบมัน และคลื่นของโพสต์ “ฉันควรเขียนสำหรับ X หรือไม่” ก็ตามมา MCP เปลี่ยนจากการทดลองเฉพาะของ Anthropic มาเป็นเลเยอร์การรวมเอเจนต์เริ่มต้นในเวลาน้อยกว่าหนึ่งปี

สิ่งที่การเติบโตนี้ซ่อนอยู่คือช่องโหว่ในการใช้เครื่องมือ: ไม่มีใครจัดส่งวิธีที่สะอาดในการทดสอบเซิร์ฟเวอร์ MCP การรัน JSON-RPC ด้วยตนเองผ่าน stdio ด้วยดีบักเกอร์นั้นใช้ได้สำหรับ hello-world แต่มันจะล้มเหลวทันทีที่เซิร์ฟเวอร์ของคุณมี 12 เครื่องมือ, 3 พร้อมต์ และ API อัปสตรีมที่ไม่เสถียร คู่มือนี้จะให้แนวทางปฏิบัติจริงสำหรับการทดสอบเซิร์ฟเวอร์ MCP ด้วยตนเองและทำให้การทดสอบเหล่านั้นเป็นไปโดยอัตโนมัติด้วย Apidog เพื่อให้คุณสามารถจัดส่งเซิร์ฟเวอร์ MCP ได้เหมือนกับที่คุณจัดส่ง API อื่น ๆ: ด้วยสัญญา, การจำลอง และชุดทดสอบการถดถอย

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

TL;DR

• MCP คือ Model Context Protocol จาก Anthropic; เป็น JSON-RPC 2.0 ผ่าน stdio หรือ HTTP และเปิดเผยองค์ประกอบพื้นฐานสามประการ: เครื่องมือ (tools), ทรัพยากร (resources) และพร้อมต์ (prompts)
• การทดสอบเซิร์ฟเวอร์ MCP หมายถึงการตรวจสอบการตอบสนองของ initialize, tools/list, tools/call, resources/read และ prompts/get กับสัญญา
• เริ่มต้นด้วยตนเอง: ขับเคลื่อนเซิร์ฟเวอร์จากบรรทัดคำสั่งด้วย stdio ยืนยันการตอบสนองด้วยสายตา และแก้ไขข้อบกพร่องด้านรูปร่างก่อนที่จะเพิ่มไคลเอนต์
• เปลี่ยนไปใช้ระบบอัตโนมัติ: บันทึกการรับส่งข้อมูล JSON-RPC ใน Apidog เปลี่ยนการเรียกแต่ละครั้งเป็นการร้องขอที่บันทึกไว้ สร้างการยืนยันเกี่ยวกับรูปร่างและเนื้อหาของการตอบสนอง และเรียกใช้ชุดทดสอบใน CI
• ใช้เซิร์ฟเวอร์จำลองของ Apidog เพื่อจำลอง API อัปสตรีมที่เซิร์ฟเวอร์ MCP ของคุณเรียกใช้ เพื่อให้การทดสอบคงที่
• ดาวน์โหลด Apidog เพื่อรับชุดการร้องขอ, เซิร์ฟเวอร์จำลอง และ CI runner ในที่เดียว

MCP คืออะไรในสองนาที

ข้อกำหนด Model Context Protocol กำหนดรูปแบบสาย JSON-RPC 2.0 ที่มีพื้นผิวขนาดเล็ก ไคลเอนต์ (Claude Desktop, Cursor, เอเจนต์ของคุณเอง) จะเริ่มเซิร์ฟเวอร์ MCP ดำเนินการ initialize handshake และจากนั้นจึงออกคำสั่งเรียก

การเรียกห้าครั้งที่คุณจะใช้เวลา 90 เปอร์เซ็นต์ในการทดสอบ:

• initialize: การเจรจาเวอร์ชันและการเปิดเผยความสามารถ
• tools/list: เซิร์ฟเวอร์ส่งคืนเครื่องมือที่เปิดเผย รวมถึง JSON Schema สำหรับอาร์กิวเมนต์
• tools/call: ไคลเอนต์เรียกใช้เครื่องมือตามชื่อพร้อมอาร์กิวเมนต์
• resources/list และ resources/read: เซิร์ฟเวอร์เปิดเผยเนื้อหาที่เข้าถึงได้ด้วย URI
• prompts/list และ prompts/get: เซิร์ฟเวอร์เปิดเผยเทมเพลตพร้อมต์ที่ไคลเอนต์สามารถแสดงผลได้

การขนส่งเป็นได้ทั้ง stdio (JSON-RPC frames แยกด้วย newline บน stdin/stdout) หรือ HTTP แบบสตรีมมิ่ง (โดยทั่วไปคือ POST / พร้อม SSE สำหรับการสตรีม) เซิร์ฟเวอร์โลคอลส่วนใหญ่ใช้ stdio; เซิร์ฟเวอร์ระยะไกลใช้ HTTP

เหตุใดการทดสอบจึงสำคัญ: ผู้ใช้ Claude Desktop ทุกคน ผู้ใช้ Cursor ทุกคน IDE ทุกตัวที่เพิ่มการรองรับ MCP จะเรียกใช้เซิร์ฟเวอร์ของคุณ ข้อบกพร่องในรูปร่างของ tools/list จะทำให้ไคลเอนต์ทุกตัวเสียพร้อมกัน ค่าใช้จ่ายของการถดถอยนั้นสูง

คุณควรทดสอบอะไรบ้าง

ชุดทดสอบเซิร์ฟเวอร์ MCP ที่แข็งแกร่งครอบคลุมหกมิติ

การปฏิบัติตามโปรโตคอล (Protocol conformance) initialize ส่งคืน protocolVersion ที่ถูกต้องหรือไม่? เซิร์ฟเวอร์โฆษณาความสามารถที่รองรับจริงหรือไม่?

ความถูกต้องของ Schema (Schema correctness) เครื่องมือแต่ละตัวใน tools/list มี JSON Schema ที่ถูกต้องสำหรับอาร์กิวเมนต์หรือไม่? ฟิลด์ที่จำเป็นถูกทำเครื่องหมายไว้หรือไม่? คำอธิบายยาวกว่าสามคำหรือไม่? คำอธิบายที่ว่างเปล่าจะทำให้การเลือกเครื่องมือบน Claude เสียหาย

พฤติกรรมเครื่องมือ (Tool behavior) สำหรับเครื่องมือแต่ละตัว tools/call ส่งคืนบล็อกเนื้อหาประเภทที่ถูกต้องหรือไม่ (text, image, resource)? กรณีข้อผิดพลาดส่งคืนผลลัพธ์ isError: true แทนที่จะส่ง JSON-RPC errors หรือไม่?

การเข้าถึงทรัพยากร (Resource access) URI ของ resources/list สามารถแก้ไขได้เมื่อเรียกผ่าน resources/read หรือไม่? การแบ่งหน้าทำงานหลังจากหน้าแรกหรือไม่?

การแสดงผลพร้อมต์ (Prompt rendering) พร้อมต์ส่งคืนอาร์เรย์ messages ที่จัดรูปแบบอย่างดีหรือไม่? การแทนที่อาร์กิวเมนต์ลงในตำแหน่งที่ถูกต้องหรือไม่?

โหมดความล้มเหลว (Failure modes) จะเกิดอะไรขึ้นเมื่อ API อัปสตรีมล่ม? เมื่ออาร์กิวเมนต์เครื่องมือหายไป? เมื่อไคลเอนต์หมดเวลา? นี่คือข้อบกพร่องที่ปรากฏในการผลิต ไม่ใช่ที่ hello-world

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

การทดสอบด้วยตนเองด้วย stdio

เริ่มต้นด้วยการตั้งค่าที่ง่ายที่สุดเท่าที่จะทำได้: เทอร์มินัล, ไบนารีเซิร์ฟเวอร์ของคุณ และตัวตรวจสอบ MCP หรือ JSON-RPC แบบดิบด้วยตนเอง

หากคุณยังไม่ได้สร้างเซิร์ฟเวอร์ ให้สร้างโครงสร้างด้วย MCP SDK quickstart อย่างเป็นทางการ ใน Python หรือ TypeScript ตัวอย่างสภาพอากาศที่มีสองเครื่องมือก็เพียงพอสำหรับการทดสอบแล้ว

รันเซิร์ฟเวอร์ในโหมดตรวจสอบ:

npx @modelcontextprotocol/inspector node your-server.js

ตัวตรวจสอบจะบูต UI เว็บภายในเครื่องที่สื่อสาร MCP กับเซิร์ฟเวอร์ของคุณและแสดงคำขอและการตอบกลับทั้งหมด นี่เป็นวิธีที่เร็วที่สุดในการยืนยันว่าเซิร์ฟเวอร์เริ่มต้น โฆษณาความสามารถ และตอบสนองต่อ tools/list

เมื่อมุมมองของตัวตรวจสอบถูกต้องแล้ว ให้รันโฟลว์เดียวกันด้วย stdio แบบดิบเพื่อให้คุณสามารถบันทึกเฟรมสำหรับ Apidog ได้:

echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2026-04-01","capabilities":{}}}' | node your-server.js

คุณจะได้รับการตอบกลับ JSON-RPC บน stdout บันทึกคำขอและการตอบกลับ ทำซ้ำสำหรับ tools/list, tools/call, resources/list และที่เหลือ ท้ายที่สุดของแบบฝึกหัดนี้ คุณจะมีคู่คำขอ-ตอบกลับที่เป็นมาตรฐาน 6 ถึง 12 คู่ที่กำหนดสัญญาของเซิร์ฟเวอร์ของคุณในระดับ wire

สองสิ่งที่ต้องระวัง

ประการแรก บล็อกเนื้อหา ผลลัพธ์ของเครื่องมือจะส่งคืน content: [{ type: "text", text: "..." }] หรือ content: [{ type: "image", data: "...", mimeType: "image/png" }] การผสมประเภทในคำตอบเดียวได้รับอนุญาต; ไคลเอนต์จะแสดงผลแตกต่างกันไป

ประการที่สอง ข้อผิดพลาด ข้อกำหนด MCP ชัดเจน: ข้อผิดพลาดในการเรียกใช้เครื่องมือจะส่งคืนผลลัพธ์ปกติพร้อม isError: true และบล็อกเนื้อหาที่อธิบายความล้มเหลว อย่าส่ง JSON-RPC error responses จากภายในเครื่องมือ; นั่นเป็นการส่งสัญญาณความล้มเหลวระดับโปรโตคอล ไม่ใช่ระดับเครื่องมือ ไคลเอนต์จำนวนมากจะตัดการเชื่อมต่อเมื่อเกิดข้อผิดพลาดของโปรโตคอล

จากการทดสอบด้วยตนเองสู่การทดสอบอัตโนมัติ: การสร้างชุดทดสอบใน Apidog

การทดสอบด้วยตนเองจะพบข้อบกพร่องที่ชัดเจน คุณจะเปลี่ยนไปใช้ระบบอัตโนมัติเมื่อคุณเริ่มถามว่า "การเปลี่ยนแปลงครั้งล่าสุดของฉันทำให้ schema อาร์กิวเมนต์ของเครื่องมือ 7 เสียหายหรือไม่?" และไม่ต้องการพิมพ์คำสั่ง curl 12 คำสั่งเพื่อค้นหา

รูปแบบ: นำคู่คำขอ-ตอบกลับทุกคู่ที่คุณบันทึกไว้ระหว่างการทดสอบด้วยตนเอง วางลงใน Apidog เป็นคำขอที่บันทึกไว้ เพิ่มการยืนยัน และเรียกใช้ชุดทดสอบทุกครั้งที่พุช

1. สร้างโปรเจกต์ Apidog สำหรับเซิร์ฟเวอร์ MCP

เปิด Apidog สร้างโปรเจกต์ใหม่ ตั้งค่า URL พื้นฐานเป็น HTTP endpoint ของเซิร์ฟเวอร์ MCP ของคุณ (หรือ URL ของ stdio bridge; ดูด้านล่าง) โปรเจกต์ Apidog รองรับทั้ง REST และ JSON-RPC; สร้างสภาพแวดล้อม JSON-RPC

สำหรับเซิร์ฟเวอร์ stdio ที่ไม่มีส่วนหน้า HTTP ให้รันโดยมี HTTP wrapper บาง ๆ สำหรับการทดสอบ ตัวตรวจสอบอย่างเป็นทางการมีให้; หรือสคริปต์ Node 30 บรรทัดที่อ่าน JSON-RPC ผ่าน HTTP และส่งต่อไปยัง stdio ก็ใช้งานได้ดี เราใช้รูปแบบเดียวกันใน การทดสอบ API โดยไม่ต้องใช้ Postman ในปี 2026 สำหรับแบ็คเอนด์ที่ไม่ใช่ HTTP

2. บันทึกคำขอมาตรฐาน

สำหรับแต่ละ initialize, tools/list, tools/call, resources/list, resources/read, prompts/list, prompts/get ให้บันทึกเนื้อหา JSON-RPC เป็นคำขอ Apidog จะจัดเก็บพร้อมเนื้อหา เฮดเดอร์ และสถานะที่คาดไว้

คำขอ tools/call มีลักษณะดังนี้ในมุมมองเนื้อหาคำขอของ Apidog:

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "city": "Tokyo"
    }
  }
}

3. เพิ่มการยืนยัน

ประเด็นของการทำงานอัตโนมัติคือการยืนยันการตอบสนอง ไม่ใช่การส่งคำขอ Apidog รองรับการยืนยัน JSONPath โดยกำเนิด สำหรับ tools/list คุณต้องการอย่างน้อย:

• $.result.tools มีอยู่
• $.result.tools.length มากกว่าศูนย์
• เครื่องมือทุกตัวมี name, description และ inputSchema
• inputSchema ทุกตัวเป็น JSON Schema ที่ถูกต้อง

สำหรับ tools/call บนอินพุตที่ดีที่ทราบ คุณต้องการ:

• $.result.isError เป็น false (หรือไม่มี)
• $.result.content เป็นอาร์เรย์
• บล็อกเนื้อหาแรกมี type และเนื้อหาที่คาดไว้

สำหรับ tools/call บนอินพุตที่ไม่ดีที่ทราบ (อาร์กิวเมนต์ที่จำเป็นหายไป) คุณต้องการ:

• $.result.isError เป็น true
• $.result.content[0].text ตรงกับข้อความแสดงข้อผิดพลาดที่คุณคาดไว้

Apidog จัดเก็บการยืนยันเหล่านี้ต่อคำขอ ความล้มเหลวจะแสดงในรายงานการรัน

4. จำลอง API อัปสตรีม

เซิร์ฟเวอร์ MCP ส่วนใหญ่จะห่อหุ้ม API ภายนอก: ข้อมูลสภาพอากาศ, GitHub, Linear, ฐานข้อมูลภายใน คุณไม่ต้องการให้ CI รันไปกระทบ API จริงทุกครั้งที่ commit มีสองเหตุผล: ค่าใช้จ่ายและความไม่เสถียร

เซิร์ฟเวอร์จำลองในตัวของ Apidog แก้ไขปัญหานี้ได้ กำหนดแต่ละปลายทางอัปสตรีมเป็นเส้นทางจำลองที่ส่งคืนเนื้อหา JSON ที่สมจริง ชี้การกำหนดค่าเซิร์ฟเวอร์ MCP ของคุณไปยัง URL จำลองระหว่างการทดสอบ และไปยังการผลิตระหว่างการรันจริง เราครอบคลุมเวิร์กโฟลว์การจำลองโดยละเอียดใน การพัฒนา API แบบ contract-first

ผลลัพธ์: ชุดทดสอบที่ทำงานในไม่กี่วินาที ไม่ต้องใช้เครือข่ายภายนอก และตรวจจับการถดถอยของ Schema ได้นานก่อนที่จะจัดส่ง

5. รันชุดทดสอบใน CI

โปรเจกต์ Apidog สามารถส่งออกไปยัง CLI runners ได้ คำสั่ง apidog run จะรับ Project ID เรียกใช้คำขอที่บันทึกไว้ทุกรายการ ประเมินการยืนยัน และออกด้วยรหัสที่ไม่ใช่ศูนย์เมื่อเกิดความล้มเหลว เชื่อมโยงเข้ากับ GitHub Actions ของคุณ หรือ CI provider ใดๆ ที่คุณใช้อยู่แล้ว

เวิร์กโฟลว์ขั้นต่ำ:

name: MCP server tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22 }
      - run: npm ci
      - name: Start MCP HTTP wrapper
        run: node test/wrapper.js &
      - name: Run Apidog suite
        run: npx apidog run --project-id $APIDOG_PROJECT --env ci
        env:
          APIDOG_PROJECT: ${{ secrets.APIDOG_PROJECT }}
          APIDOG_TOKEN:   ${{ secrets.APIDOG_TOKEN }}

ทุกครั้งที่พุชจะรันสัญญา MCP ทั้งหมด การถดถอยของ Schema ของ Tool 7 ไม่สามารถเกิดขึ้นได้โดยไม่มีการตรวจพบ

ลักษณะของ Test Coverage ที่ดี

แผนการทดสอบเซิร์ฟเวอร์ MCP ที่สมบูรณ์ใน Apidog โดยทั่วไปจะประกอบด้วย:

• คำขอ initialize 1 รายการพร้อมการยืนยันความสามารถ
• คำขอ tools/list 1 รายการพร้อมการยืนยันรูปร่างและ JSON Schema
• คำขอ tools/call 2 ถึง 4 รายการต่อเครื่องมือ: happy path, อาร์กิวเมนต์หายไป, ประเภทไม่ถูกต้อง, ข้อผิดพลาดจากระบบต้นทาง
• resources/list 1 รายการ บวก resources/read 1 รายการต่อตระกูลทรัพยากร
• prompts/list 1 รายการ บวก prompts/get 1 รายการต่อเทมเพลตพร้อมต์

สำหรับเซิร์ฟเวอร์ที่มี 10 เครื่องมือ 3 ทรัพยากร และ 4 พร้อมต์ ชุดทดสอบจะมีการร้องขอ 50 ถึง 70 รายการ Apidog จะรันสิ่งนี้ในเครื่องภายในเวลาไม่ถึง 10 วินาทีเมื่อเซิร์ฟเวอร์จำลองพร้อมทำงาน

ข้อผิดพลาดทั่วไปในการทดสอบเซิร์ฟเวอร์ MCP

นี่คือรูปแบบที่เราพบบ่อยที่สุด

การข้ามการทำงานของ initialize เซิร์ฟเวอร์บางตัวจะล่มเมื่อ tools/list หากไม่เคยมีการเรียก initialize มาก่อน เนื่องจากพวกมันจะสร้าง tool registry แบบ lazy-build ภายใน handshake ควรเรียกใช้ initialize ก่อนเสมอ

การยืนยันสตริงข้อผิดพลาดดิบ ข้อความแสดงข้อผิดพลาดของเครื่องมือจะมีการเปลี่ยนแปลง ควรยืนยัน isError: true และโค้ดข้อผิดพลาดที่เสถียรหรือ regular expression ไม่ใช่การจับคู่สตริงที่แน่นอน

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

การลืมเรื่องสตรีมมิ่ง เซิร์ฟเวอร์ HTTP MCP จะสตรีมผลลัพธ์ของเครื่องมือผ่าน SSE (Server-Sent Events) ตัวรันการทดสอบของคุณต้องรองรับ SSE; Apidog ทำได้ แต่คุณต้องเปิดใช้งานการสตรีมในการร้องขอ

ไม่ทดสอบการทำงานพร้อมกัน ไคลเอนต์ MCP จะส่งคำขอ tools/call พร้อมกันใน agent loops หากเซิร์ฟเวอร์ของคุณเก็บสถานะที่ใช้ร่วมกันโดยไม่มีการล็อก การทดสอบคำขอเดียวจะผ่าน แต่ในการผลิตจะเสีย เพิ่มการทดสอบการทำงานแบบขนานลงในชุดทดสอบ

ความสับสนระหว่างข้อผิดพลาดโปรโตคอลกับข้อผิดพลาดเครื่องมือ ข้อกำหนด MCP แยกความแตกต่างระหว่างสองสิ่งนี้อย่างจงใจ การผสมปนเปกันจะทำให้ Claude Desktop ปิดการเชื่อมต่อ เราได้กล่าวถึงข้อผิดพลาดของสัญญาประเภทเดียวกันใน การพัฒนาแพลตฟอร์ม API แบบ contract-first

กรณีการใช้งานจริง

ทีมที่สร้างเซิร์ฟเวอร์ MCP ภายในสำหรับ API การจัดการเหตุการณ์ของบริษัท ตรวจพบข้อบกพร่องสามประการในหนึ่งสัปดาห์โดยใช้ Apidog assertions กับรูปร่างของ tools/list หากไม่มีการทดสอบนี้ ข้อบกพร่องจะถูกส่งไปยังวิศวกรทุกคนที่ใช้ Claude Desktop พร้อมกัน

นักพัฒนาเดี่ยวที่เผยแพร่เซิร์ฟเวอร์ MCP แบบโอเพนซอร์สสำหรับ Notion ใช้ Apidog mocks เพื่อรันชุดทดสอบโดยไม่กระทบต่อข้อจำกัดอัตราของ Notion ในระหว่าง CI ชุดทดสอบของพวกเขาจะรันในทุก PR ใช้เวลา 8 วินาที และแคช mock fixtures ของ Apidog ใน repo เพื่อให้ผู้ร่วมให้ข้อมูลไม่จำเป็นต้องเข้าถึง API เพื่อพัฒนา

ทีมแพลตฟอร์มที่รันเซิร์ฟเวอร์ MCP ภายใน 14 ตัว ได้สร้างพื้นที่ทำงาน Apidog ที่ใช้ร่วมกันซึ่งเป็นที่อยู่ของสัญญาของเซิร์ฟเวอร์ทุกตัว เซิร์ฟเวอร์ใหม่จะสืบทอดชุดทดสอบพื้นฐาน; ผู้ตรวจสอบสามารถเปรียบเทียบความแตกต่างของ Schema แบบเคียงข้างกันก่อนที่จะรวมเข้าด้วยกัน ทีมงานรายงานว่าป้องกันการหยุดทำงานได้สองครั้งในไตรมาสแรก ทั้งสองถูกตรวจพบโดยการยืนยันรูปร่างของ tools/list ใน PR ที่จะส่งอาร์กิวเมนต์ที่เปลี่ยนชื่อไปยังผู้ใช้ Claude Desktop ทุกคนในบริษัท

ทีมที่สองที่สร้างเซิร์ฟเวอร์ MCP สำหรับแพลตฟอร์มการสังเกตการณ์ภายในใช้ environment switcher ของ Apidog เพื่อรันชุดทดสอบเดียวกันกับ staging และ production แต่ละสภาพแวดล้อมชี้ไปยังไฟล์ mock fixture ที่แตกต่างกัน ดังนั้น 60 assertions เดียวกันจึงยืนยันการปรับใช้ทั้งสองโดยไม่ต้องเขียนคำขอใหม่แม้แต่รายการเดียว

สรุป

MCP ได้กลายเป็นกระแสหลักในปีนี้ แต่เรื่องราวของการทดสอบยังคงอยู่ในจุดเดียวกับที่การทดสอบ REST API เคยเป็นเมื่อทศวรรษที่แล้ว: เฉพาะกิจ, ทำด้วยมือ, เปราะบาง คุณไม่จำเป็นต้องรอให้ระบบนิเวศตามทัน ปฏิบัติต่อเซิร์ฟเวอร์ MCP ของคุณในฐานะ API ที่เป็นอยู่ ออกแบบสัญญา จำลองระบบต้นน้ำ และรันการยืนยันใน CI

ห้าข้อควรจำ:

• เซิร์ฟเวอร์ MCP คือ JSON-RPC API; ทดสอบด้วยความเข้มงวดเช่นเดียวกับ REST API
• เริ่มต้นด้วยตนเองด้วยตัวตรวจสอบอย่างเป็นทางการ จากนั้นบันทึกคำขอมาตรฐานและเปลี่ยนไปใช้ระบบอัตโนมัติ
• Apidog จัดการ JSON-RPC, การยืนยัน, การจำลอง และ CI ในโปรเจกต์เดียว
• ครอบคลุมหกมิติ: การปฏิบัติตามโปรโตคอล, ความถูกต้องของ Schema, พฤติกรรมเครื่องมือ, การเข้าถึงทรัพยากร, การแสดงผลพร้อมต์ และโหมดความล้มเหลว
• จำลอง API อัปสตรีมใน Apidog เพื่อให้ชุดทดสอบรวดเร็วและคงที่

ขั้นตอนต่อไป: เปิด Apidog สร้างโปรเจกต์ วางเนื้อหาคำขอที่คุณบันทึกด้วยตนเอง เพิ่ม JSONPath assertions สำหรับ tools/list และรันชุดทดสอบ คุณจะรู้ได้ภายในหนึ่งชั่วโมงว่าสัญญาของเซิร์ฟเวอร์ของคุณแข็งแกร่งพอที่จะจัดส่งหรือไม่

คำถามที่พบบ่อย

MCP คืออะไร?

MCP หรือ Model Context Protocol เป็นข้อกำหนดแบบเปิดของ Anthropic สำหรับวิธีที่ไคลเอนต์ AI (เช่น Claude Desktop) เรียกใช้เครื่องมือ ทรัพยากร และพร้อมต์ภายนอก เป็น JSON-RPC 2.0 ผ่าน stdio หรือ HTTP แบบสตรีมมิ่ง ข้อกำหนด MCP ฉบับเต็ม ตีพิมพ์บน modelcontextprotocol.io

ฉันสามารถทดสอบเซิร์ฟเวอร์ MCP โดยไม่มี HTTP wrapper ได้หรือไม่?

ได้ ตัวตรวจสอบ MCP อย่างเป็นทางการ สื่อสารกับ stdio โดยตรงและให้ UI สำหรับการทดสอบด้วยตนเอง สำหรับการทดสอบอัตโนมัติใน Apidog ให้ห่อหุ้ม stdio ด้วย HTTP server บาง ๆ ในระหว่าง CI; การรับส่งข้อมูลในการผลิตยังคงผ่าน stdio

ฉันจะจำลอง API อัปสตรีมที่เซิร์ฟเวอร์ MCP ของฉันเรียกใช้ได้อย่างไร?

กำหนดปลายทางอัปสตรีมแต่ละรายการเป็นการจำลองในโปรเจกต์ Apidog ของคุณ ชี้การกำหนดค่าเซิร์ฟเวอร์ MCP ไปยัง URL การจำลองระหว่างการทดสอบ และสลับไปใช้ URL การผลิตในระหว่างการทำงาน เราจะอธิบายรูปแบบเดียวกันใน เครื่องมือทดสอบ API สำหรับวิศวกร QA

แล้วการสตรีมผลลัพธ์ของเครื่องมือล่ะ?

เซิร์ฟเวอร์ HTTP MCP จะสตรีมผลลัพธ์ของเครื่องมือผ่าน Server-Sent Events Apidog รองรับ SSE ในคำขอที่บันทึกไว้; เปิดใช้งานในการตั้งค่าคำขอและยืนยันกระแสข้อมูลที่ประกอบขึ้นมา

ฉันควรทดสอบเวอร์ชันโปรโตคอลหรือไม่?

ใช่ ปักหมุด protocolVersion ที่คุณรองรับใน initialize และยืนยันกับมัน ความไม่ตรงกันทำให้เกิดความไม่เข้ากันของไคลเอนต์ที่เงียบ

ฉันสามารถทดสอบเซิร์ฟเวอร์ MCP ของฉันกับ Claude Desktop จริงได้หรือไม่?

คุณทำได้ และคุณควรทำอย่างน้อยหนึ่งครั้งก่อนการออกรุ่นแต่ละครั้ง แต่อย่าพึ่งพา Claude Desktop เป็นวงจรการทดสอบของคุณ; มันช้า ทำด้วยมือ และไม่คงที่ ใช้ Apidog สำหรับชุดการถดถอยและ Claude Desktop สำหรับ smoke test

ฉันจะดูตัวอย่างเซิร์ฟเวอร์ MCP จริงได้ที่ไหน?

คลังเซิร์ฟเวอร์ MCP อย่างเป็นทางการ มีการใช้งานอ้างอิงสำหรับ filesystem, GitHub, Slack, Postgres และอีกมากมาย อ่านคำจำกัดความของเครื่องมือ; เป็นวิธีที่ง่ายที่สุดในการทำความเข้าใจว่ารูปร่าง MCP ที่ดีเป็นอย่างไร