Thanawat Wongchai

Posted on May 11 • Originally published at apidog.com

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

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

ลองใช้ Apidog วันนี้

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

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

TL;DR

MCP คือ Model Context Protocol จาก Anthropic เป็น JSON-RPC 2.0 ผ่าน stdio หรือ HTTP และเปิดเผย primitives หลัก 3 แบบ: tools, resources และ prompts
จุดที่ควรทดสอบคือ initialize, tools/list, tools/call, resources/read และ prompts/get
เริ่มด้วย manual test: รันเซิร์ฟเวอร์ผ่าน stdio, ตรวจ response และแก้ shape ของ JSON-RPC ให้ถูกก่อนเพิ่ม client
จากนั้นทำ automation: บันทึก JSON-RPC request/response ใน Apidog, เพิ่ม assertions และรันใน CI
ใช้ mock server ของ Apidog เพื่อจำลอง API อัปสตรีมที่ MCP server เรียกใช้ ทำให้ test คงที่และไม่พึ่งระบบภายนอก
ดาวน์โหลด Apidog เพื่อจัดการ request collection, mock server และ CI runner ในที่เดียว

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

ข้อกำหนด Model Context Protocol นิยาม wire format บน JSON-RPC 2.0 โดย client เช่น Claude Desktop, Cursor หรือเอเจนต์ของคุณ จะเริ่ม MCP server, ทำ initialize handshake แล้วเรียก method ต่าง ๆ ต่อไป

การเรียกที่ควรทดสอบบ่อยที่สุดมีดังนี้:

initialize: เจรจา protocol version และประกาศ capabilities
tools/list: ส่งรายการ tools พร้อม JSON Schema ของ arguments
tools/call: เรียก tool ตามชื่อพร้อม arguments
resources/list และ resources/read: เปิดเผย content ที่เข้าถึงผ่าน URI
prompts/list และ prompts/get: เปิดเผย prompt templates ที่ client นำไป render ได้

Transport มีได้ 2 แบบหลัก:

stdio: JSON-RPC frames แยกด้วย newline ผ่าน stdin/stdout
HTTP streaming: โดยทั่วไปคือ POST / พร้อม SSE สำหรับ streaming

Local server ส่วนใหญ่ใช้ stdio ส่วน remote server มักใช้ HTTP

เหตุผลที่ต้องทดสอบจริงจัง: ถ้า tools/list คืน shape ผิด client ทุกตัวที่รองรับ MCP อาจพังพร้อมกัน ไม่ว่าจะเป็น Claude Desktop, Cursor หรือ IDE ที่เพิ่ม MCP support ภายหลัง

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

ชุดทดสอบ MCP server ที่ดีควรครอบคลุม 6 ด้าน

1. Protocol conformance

ตรวจว่า initialize คืนค่าถูกต้อง เช่น:

protocolVersion ตรงกับเวอร์ชันที่รองรับ
capabilities ประกาศเฉพาะสิ่งที่ server ทำได้จริง
response เป็น JSON-RPC 2.0 ที่ถูกต้อง

2. Schema correctness

สำหรับแต่ละ tool ใน tools/list ให้ตรวจว่า:

มี name
มี description
มี inputSchema
required fields ถูกกำหนดครบ
description ไม่ว่างเปล่าหรือสั้นเกินไป

description ที่แย่จะทำให้โมเดลเลือก tool ผิดได้ง่าย

3. Tool behavior

สำหรับแต่ละ tools/call ให้ตรวจว่า:

happy path คืน content ถูกชนิด เช่น text, image, resource
error path คืน isError: true
tool error ไม่ถูกส่งเป็น JSON-RPC protocol error

ตัวอย่างผลลัพธ์ที่ควรถูกต้อง:

{
  "jsonrpc": "2.0",
  "id": 42,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Weather in Tokyo: 22°C"
      }
    ]
  }
}

ตัวอย่าง tool error ที่ควรส่งเป็น result ปกติ:

{
  "jsonrpc": "2.0",
  "id": 43,
  "result": {
    "isError": true,
    "content": [
      {
        "type": "text",
        "text": "Missing required argument: city"
      }
    ]
  }
}

4. Resource access

ตรวจว่า URI ที่ได้จาก resources/list สามารถอ่านผ่าน resources/read ได้จริง รวมถึง pagination หรือ cursor หลังหน้าแรก

5. Prompt rendering

สำหรับ prompts/get ให้ตรวจว่า:

คืน messages ที่ format ถูกต้อง
argument substitution ถูกตำแหน่ง
role และ content ตรงตามสัญญา

6. Failure modes

ทดสอบสถานการณ์จริง เช่น:

API อัปสตรีมล่ม
argument หาย
argument type ผิด
timeout
concurrent calls

ข้อผิดพลาดเหล่านี้มักไม่เจอใน hello-world แต่จะเจอทันทีเมื่อมีผู้ใช้จริง

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

เริ่มจาก setup ที่เล็กที่สุด:

terminal
MCP server binary/script
MCP Inspector หรือ raw JSON-RPC

หากยังไม่มี server ให้เริ่มจาก MCP SDK quickstart อย่างเป็นทางการ ใน Python หรือ TypeScript ตัวอย่าง weather server ที่มี 2 tools เพียงพอสำหรับใช้สร้าง test flow

รัน server ผ่าน inspector:

npx @modelcontextprotocol/inspector node your-server.js

Inspector จะเปิด local web UI, คุยกับ MCP server และแสดง request/response ทั้งหมด ใช้ตรวจอย่างรวดเร็วว่า server:

start ได้
ทำ initialize ได้
ประกาศ capabilities ถูกต้อง
ตอบ tools/list ได้

เมื่อ inspector แสดงผลถูกต้องแล้ว ให้รัน flow เดียวกันแบบ raw stdio เพื่อบันทึก request/response สำหรับนำไปใช้ใน Apidog

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

คุณจะได้ JSON-RPC response ทาง stdout จากนั้นบันทึก request/response และทำซ้ำกับ method ต่อไปนี้:

tools/list
tools/call
resources/list
resources/read
prompts/list
prompts/get

เป้าหมายคือมี canonical request/response 6-12 คู่ที่กำหนด contract ของ MCP server ระดับ wire

จุดที่ควรระวังระหว่าง manual test

Content blocks

ผลลัพธ์ tool ควรใช้ content block ที่ถูกต้อง เช่น:

{
  "content": [
    {
      "type": "text",
      "text": "..."
    }
  ]
}

หรือ:

{
  "content": [
    {
      "type": "image",
      "data": "...",
      "mimeType": "image/png"
    }
  ]
}

การผสมหลาย content types ใน response เดียวทำได้ แต่ client แต่ละตัวอาจ render ต่างกัน ต้องทดสอบกับ client ที่ใช้งานจริงด้วย

Error handling

MCP แยก tool error ออกจาก protocol error อย่างชัดเจน

ถ้า tool ทำงานไม่สำเร็จ ให้คืน result ปกติพร้อม isError: true ไม่ใช่ JSON-RPC error response เพราะ JSON-RPC error หมายถึง protocol-level failure ซึ่ง client หลายตัวอาจตัด connection ทันที

เปลี่ยน manual test เป็น automation ด้วย Apidog

Manual test ช่วยหาข้อผิดพลาดชัดเจน แต่ไม่เหมาะกับ regression test คำถามที่ต้องตอบทุกครั้งก่อน merge คือ:

การเปลี่ยนแปลงล่าสุดทำให้ schema ของ tool ใด tool หนึ่งพังหรือไม่?

รูปแบบการทำงานคือ:

บันทึก request/response จาก manual test
นำเข้าเป็น saved requests ใน Apidog
เพิ่ม assertions
ใช้ mock server สำหรับ upstream API
รัน test suite ใน CI

1. สร้างโปรเจกต์ Apidog สำหรับ MCP server

เปิด Apidog แล้วสร้าง project ใหม่ ตั้ง base URL เป็น HTTP endpoint ของ MCP server หรือ URL ของ stdio bridge

Apidog รองรับ REST และ JSON-RPC ดังนั้นให้สร้าง environment สำหรับ JSON-RPC request ของ MCP

สำหรับ MCP server ที่มีเฉพาะ stdio ให้เพิ่ม HTTP wrapper บาง ๆ เฉพาะตอนทดสอบ เช่น:

ใช้ MCP Inspector ในช่วง manual test
เขียน Node script ที่รับ HTTP request แล้ว forward JSON-RPC ไปยัง stdio
ใช้ wrapper นี้เฉพาะใน CI

แนวคิดเดียวกันนี้ใช้กับ backend ที่ไม่ใช่ HTTP ในบทความ การทดสอบ API โดยไม่ต้องใช้ Postman ในปี 2026

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

สร้าง saved request สำหรับ method หลัก:

initialize
tools/list
tools/call
resources/list
resources/read
prompts/list
prompts/get

ตัวอย่าง request สำหรับ tools/call:

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

จัดกลุ่ม request ตาม feature หรือ primitive เช่น:

Protocol
Tools
Resources
Prompts
Failure cases

โครงสร้างนี้ช่วยให้รายงานใน CI อ่านง่ายขึ้น

3. เพิ่ม assertions

Automation มีประโยชน์เมื่อ response ถูกตรวจจริง ไม่ใช่แค่ส่ง request แล้วดู status ผ่าน

Apidog รองรับ JSONPath assertions สำหรับ tools/list อย่างน้อยควรตรวจว่า:

$.result.tools มีอยู่
$.result.tools.length มากกว่า 0
tool ทุกตัวมี name
tool ทุกตัวมี description
tool ทุกตัวมี inputSchema
inputSchema เป็น JSON Schema ที่ถูกต้อง

สำหรับ tools/call happy path ให้ตรวจว่า:

$.result.isError เป็น false หรือไม่มี field นี้
$.result.content เป็น array
$.result.content[0].type มีค่าที่คาดไว้
content มีข้อมูลที่ต้องการ

สำหรับ error path เช่น argument หาย ให้ตรวจว่า:

$.result.isError เป็น true
$.result.content[0].text มีข้อความ error ที่คาดไว้ หรือ match ด้วย regex
ไม่มี JSON-RPC protocol error

ตัวอย่าง assertion ที่ควรมีใน suite:

$.jsonrpc == "2.0"
$.id exists
$.result.content[0].type == "text"

ถ้า assertion ล้มเหลว Apidog จะแสดงผลใน test run report ทำให้ trace regression ได้ง่าย

4. จำลอง upstream API

MCP server ส่วนใหญ่มัก wrap API ภายนอก เช่น:

weather API
GitHub
Linear
Notion
database ภายใน
observability platform

ไม่ควรให้ CI เรียก API จริงทุกครั้ง เพราะมีปัญหาเรื่อง:

rate limit
ค่าใช้จ่าย
network flakiness
test data เปลี่ยน
credential management

ให้ใช้ mock server ของ Apidog แทน โดยทำตามขั้นตอนนี้:

กำหนด upstream endpoint เป็น mock route
สร้าง response fixture ที่สมจริง
ตั้งค่า MCP server ใน environment ci ให้ชี้ไปยัง mock URL
production runtime ยังชี้ไปยัง API จริง
อัปเดต mock fixture จาก response จริงเมื่อ API เปลี่ยน

แนวทาง mock และ contract-first อธิบายเพิ่มเติมใน การพัฒนา API แบบ contract-first

ผลลัพธ์คือ test suite ที่:

รันเร็ว
ไม่พึ่ง network ภายนอก
ไม่กระทบ rate limit
ตรวจ schema regression ได้ก่อน release

5. รัน MCP test suite ใน CI

เมื่อ saved requests และ assertions พร้อมแล้ว ให้รันผ่าน CLI runner ใน CI

ตัวอย่าง GitHub Actions workflow:

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 }}

เมื่อมี push หรือ pull request ชุดทดสอบจะรัน MCP contract ทั้งหมด ถ้า tool schema, prompt shape หรือ error handling เปลี่ยนผิด CI จะ fail ก่อน merge

Test coverage ที่ดีควรหน้าตาแบบไหน

สำหรับ MCP server หนึ่งตัว test suite ใน Apidog โดยทั่วไปควรมี:

initialize 1 request พร้อม assertions เรื่อง protocol และ capabilities
tools/list 1 request พร้อม assertions เรื่อง shape และ JSON Schema
tools/call 2-4 requests ต่อ tool:
- happy path
- missing required argument
- invalid type
- upstream error
resources/list 1 request
resources/read อย่างน้อย 1 request ต่อ resource family
prompts/list 1 request
prompts/get อย่างน้อย 1 request ต่อ prompt template
concurrency หรือ parallel run สำหรับ server ที่มี shared state

ถ้า server มี 10 tools, 3 resources และ 4 prompts ชุดทดสอบมักอยู่ที่ประมาณ 50-70 requests ซึ่งสามารถรันในเครื่องได้ภายในไม่กี่วินาทีเมื่อใช้ mock server

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

ข้าม `initialize`

บาง server สร้าง tool registry ระหว่าง handshake หากเรียก tools/list โดยไม่เคย initialize มาก่อนอาจล่มหรือคืนผลผิด ควรให้ test suite เรียก initialize ก่อนเสมอ

Assert ข้อความ error แบบ exact string

ข้อความ error เปลี่ยนได้ง่าย อย่า assert string แบบตรงตัวทั้งหมด ให้ assert:

isError: true
error code ที่เสถียร ถ้ามี
regex สำหรับข้อความหลัก

Mock ไม่เหมือน production

ถ้า mock ส่ง shape ที่ API จริงไม่เคยส่ง test จะผ่านแต่ integration จริงพัง ควร refresh mock fixtures จาก response จริงทุกครั้งที่ upstream API เปลี่ยน

ลืมทดสอบ streaming

HTTP MCP server อาจ stream tool result ผ่าน SSE ตัว test runner ต้องรองรับ SSE และต้องเปิด streaming ใน request ที่เกี่ยวข้อง Apidog รองรับ SSE ใน saved requests

ไม่ทดสอบ concurrency

Agent loop อาจยิง tools/call พร้อมกันหลาย request ถ้า server ใช้ shared state โดยไม่มี lock manual test ทีละ request จะไม่เจอปัญหา เพิ่ม parallel execution หรือ concurrency scenario ใน test suite

สับสนระหว่าง protocol error กับ tool error

Protocol error หมายถึง JSON-RPC หรือ MCP layer มีปัญหา ส่วน tool error หมายถึง tool ทำงานไม่สำเร็จแต่ protocol ยังปกติ การปนกันอาจทำให้ client เช่น Claude Desktop ปิด connection ได้ ประเด็น contract ลักษณะเดียวกันนี้อธิบายไว้ใน การพัฒนาแพลตฟอร์ม API แบบ contract-first

ตัวอย่างกรณีใช้งานจริง

ทีมที่สร้าง MCP server ภายในสำหรับ incident management API ใช้ Apidog assertions ตรวจ shape ของ tools/list และพบข้อผิดพลาด 3 จุดภายในหนึ่งสัปดาห์ หากไม่มี test นี้ ข้อผิดพลาดจะถูกส่งต่อไปยังวิศวกรทุกคนที่ใช้ Claude Desktop พร้อมกัน

นักพัฒนาเดี่ยวที่เผยแพร่ open-source MCP server สำหรับ Notion ใช้ Apidog mocks เพื่อรัน CI โดยไม่ชน rate limit ของ Notion test suite รันทุก PR ใช้เวลาประมาณ 8 วินาที และเก็บ mock fixtures ไว้ใน repo เพื่อให้ contributor พัฒนาได้โดยไม่ต้องมี API access

ทีม platform ที่ดูแล MCP server ภายใน 14 ตัว สร้าง Apidog workspace กลางสำหรับเก็บ contract ของทุก server server ใหม่สืบทอด base test suite ได้ทันที และ reviewer สามารถเปรียบเทียบ schema diff ก่อน merge ทีมรายงานว่าสามารถป้องกัน outage ได้ 2 ครั้งในไตรมาสแรกจาก assertions ของ tools/list

อีกทีมที่สร้าง MCP server สำหรับ observability platform ภายใน ใช้ environment switcher ของ Apidog เพื่อรัน test suite เดียวกันกับ staging และ production โดยแต่ละ environment ชี้ไปยัง mock fixture ต่างกัน ทำให้ reuse assertions เดิมได้โดยไม่ต้องเขียน request ใหม่

สรุป

MCP กำลังกลายเป็นมาตรฐานสำหรับเชื่อมเอเจนต์กับเครื่องมือภายนอก แต่แนวทางการทดสอบยังมักเป็นแบบ manual และเปราะบาง วิธีแก้คือปฏิบัติต่อ MCP server เหมือน API จริง: มี contract, มี mocks และมี regression suite ใน CI

สิ่งที่ควรทำทันที:

มอง MCP server เป็น JSON-RPC API และทดสอบด้วยความเข้มงวดเท่ากับ REST API
เริ่มจาก MCP Inspector และ raw stdio เพื่อเก็บ canonical requests
นำ request เหล่านั้นเข้า Apidog
เพิ่ม JSONPath assertions ให้ initialize, tools/list, tools/call, resources/read และ prompts/get
จำลอง upstream API ด้วย mock server เพื่อให้ CI เร็วและคงที่
รัน test suite ทุก push และ pull request

ขั้นตอนถัดไป: เปิด Apidog, สร้าง project, วาง request ที่บันทึกจาก manual test, เพิ่ม assertions สำหรับ tools/list แล้วรัน suite คุณจะรู้ภายในเวลาสั้น ๆ ว่าสัญญาของ MCP server พร้อมสำหรับการใช้งานจริงหรือยัง

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

MCP คืออะไร?

MCP หรือ Model Context Protocol เป็นข้อกำหนดแบบเปิดของ Anthropic สำหรับวิธีที่ AI client เช่น Claude Desktop เรียก tools, resources และ prompts ภายนอก เป็น JSON-RPC 2.0 ผ่าน stdio หรือ HTTP streaming อ่านข้อกำหนดเต็มได้ที่ MCP specification บน modelcontextprotocol.io

ทดสอบ MCP server โดยไม่มี HTTP wrapper ได้ไหม?

ได้ สำหรับ manual test ให้ใช้ MCP Inspector อย่างเป็นทางการ ซึ่งคุยกับ stdio โดยตรง แต่สำหรับ automation ใน Apidog ให้ใช้ HTTP wrapper บาง ๆ ระหว่าง CI โดย production ยังใช้ stdio ได้ตามปกติ

จะ mock upstream API ที่ MCP server เรียกใช้อย่างไร?

กำหนด upstream endpoint เป็น mock endpoint ในโปรเจกต์ Apidog จากนั้นชี้ config ของ MCP server ไปยัง mock URL ตอนรันทดสอบ และสลับกลับไป production URL ใน runtime จริง แนวทางเดียวกันอธิบายไว้ใน เครื่องมือทดสอบ API สำหรับวิศวกร QA

แล้ว tool result แบบ streaming ล่ะ?

HTTP MCP server อาจ stream result ผ่าน Server-Sent Events Apidog รองรับ SSE ใน saved requests ให้เปิด streaming ใน request setting และ assert ข้อมูลหลังประกอบ stream แล้ว

ควรทดสอบ protocol version หรือไม่?

ควร pin protocolVersion ที่รองรับใน initialize และ assert ค่าให้ชัดเจน เพราะ version mismatch อาจทำให้ client เข้ากันไม่ได้แบบเงียบ ๆ

ควรทดสอบกับ Claude Desktop จริงไหม?

ควรทำอย่างน้อยหนึ่งครั้งก่อน release แต่ไม่ควรใช้ Claude Desktop เป็น regression loop หลัก เพราะช้า, manual และไม่คงที่ ใช้ Apidog สำหรับ regression suite และใช้ Claude Desktop สำหรับ smoke test

ดูตัวอย่าง MCP server จริงได้ที่ไหน?

ดูได้ที่ official MCP servers repository ซึ่งมี implementation อ้างอิงสำหรับ filesystem, GitHub, Slack, Postgres และอื่น ๆ การอ่าน tool definitions ใน repo นี้เป็นวิธีที่ดีในการทำความเข้าใจ shape ของ MCP server ที่ออกแบบดีแล้ว

DEV Community

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

TL;DR

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

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

1. Protocol conformance

2. Schema correctness

3. Tool behavior

4. Resource access

5. Prompt rendering

6. Failure modes

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

จุดที่ควรระวังระหว่าง manual test

Content blocks

Error handling

เปลี่ยน manual test เป็น automation ด้วย Apidog

1. สร้างโปรเจกต์ Apidog สำหรับ MCP server

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

3. เพิ่ม assertions

4. จำลอง upstream API

5. รัน MCP test suite ใน CI

Test coverage ที่ดีควรหน้าตาแบบไหน

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

ข้าม `initialize`

Assert ข้อความ error แบบ exact string

Mock ไม่เหมือน production

ลืมทดสอบ streaming

ไม่ทดสอบ concurrency

สับสนระหว่าง protocol error กับ tool error

ตัวอย่างกรณีใช้งานจริง

สรุป

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

MCP คืออะไร?

ทดสอบ MCP server โดยไม่มี HTTP wrapper ได้ไหม?

จะ mock upstream API ที่ MCP server เรียกใช้อย่างไร?

แล้ว tool result แบบ streaming ล่ะ?

ควรทดสอบ protocol version หรือไม่?

ควรทดสอบกับ Claude Desktop จริงไหม?

ดูตัวอย่าง MCP server จริงได้ที่ไหน?

Top comments (0)

TL;DR

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

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

1. Protocol conformance

2. Schema correctness

3. Tool behavior

4. Resource access

5. Prompt rendering

6. Failure modes

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

จุดที่ควรระวังระหว่าง manual test

Content blocks

Error handling

เปลี่ยน manual test เป็น automation ด้วย Apidog

1. สร้างโปรเจกต์ Apidog สำหรับ MCP server

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

3. เพิ่ม assertions

4. จำลอง upstream API

5. รัน MCP test suite ใน CI

Test coverage ที่ดีควรหน้าตาแบบไหน

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

ข้าม initialize

Assert ข้อความ error แบบ exact string

Mock ไม่เหมือน production

ลืมทดสอบ streaming

ไม่ทดสอบ concurrency

สับสนระหว่าง protocol error กับ tool error

ตัวอย่างกรณีใช้งานจริง

สรุป

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

MCP คืออะไร?

ทดสอบ MCP server โดยไม่มี HTTP wrapper ได้ไหม?

จะ mock upstream API ที่ MCP server เรียกใช้อย่างไร?

แล้ว tool result แบบ streaming ล่ะ?

ควรทดสอบ protocol version หรือไม่?

ควรทดสอบกับ Claude Desktop จริงไหม?

ดูตัวอย่าง MCP server จริงได้ที่ไหน?

ข้าม `initialize`