อธิบาย MCP เทียบกับสเปก: เซิร์ฟเวอร์จริง ๆ คืออะไร

ก่อนพูดถึง wire มาดูเลขก่อน คุณมีแอป AI $N$ ตัว และสิ่งที่มันควรเข้าถึงได้ $M$ อย่าง — calendar, ticket tracker, warehouse database, design tool หากไม่มีสัญญาร่วมกัน ใครสักคนต้องเขียน integration $N \times M$ ชุด และทุกชุดคือ schema บวก endpoint บวกเรื่อง authentication บวกภาระ maintenance ถ้ามีสัญญาร่วมกัน tool vendor เขียน server, application vendor เขียน client และยอดรวมคือ $N + M$

นี่ไม่ใช่ข้อสังเกตใหม่ และ specification บอกไว้ว่าได้แรงบันดาลใจจากใคร:

MCP takes some inspiration from the Language Server Protocol, which standardizes how to add support for programming languages across a whole ecosystem of development tools. In a similar way, MCP standardizes how to integrate additional context and tools into the ecosystem of AI applications.¹

จงอ่านการเปรียบเทียบนั้นตามตัวอักษร ไม่ใช่เป็นคำชม ก่อน protocol นั้น การรองรับภาษาใน editor หมายถึง plugin ต่อ editor หนึ่งตัว หลังจากนั้น ทีมภาษาส่ง server ตัวเดียว แล้ว editor ทุกตัวก็ใช้ได้ ตัวชี้วัดความสำเร็จไม่ใช่ความสง่างาม แต่คือจำนวน integration หยุดทวีคูณ เหตุผลเดียวกันใช้กับที่นี่: คุณค่าอยู่ที่จำนวน implementation ไม่ใช่ที่ดีไซน์ protocol ที่มีผลิตภัณฑ์สองตัวพูดได้ ก็เป็น data format ที่มีพิธีรีตองเพิ่มขึ้นเท่านั้น

ข้อความ MCP คือ JSON-RPC 2.0 request คือ object ที่มี jsonrpc, id, method และ params ที่เป็น optional; response ถือ id เดียวกัน และมี result หรือ error อย่างใดอย่างหนึ่ง; notification คือ request ที่ไม่มี id และไม่มี reply specification เพิ่มข้อจำกัดอีกสามอย่าง: id ต้องเป็น string หรือ number และ ต้องไม่ เป็น null, ต้องไม่ชนกับ request อื่นที่ยังค้างอยู่ และทุก result ต้องมี field resultType²

บน stdio transport — ตัวที่คำสั่งข้างบนใช้ — กฎ framing คือหนึ่งข้อความต่อหนึ่งบรรทัด:

Messages are delimited by newlines, and MUST NOT contain embedded newlines. […] The server MUST NOT write anything to its stdout that is not a valid MCP message.³

ประโยคท้ายคือวิธีที่ server ทำเองพังบ่อยที่สุด และมันพังแบบเงียบ ๆ: console.log ที่หลุดมา, progress bar, deprecation warning จาก dependency แล้ว line parser ของ client ก็ชนสิ่งที่ไม่ใช่ JSON ทางหนีอยู่ใน section เดียวกัน — server may เขียนอะไรก็ได้ที่ต้องการไปที่ stderr และ client should not ถือว่านั่นเป็น error reference server ข้างบนพิมพ์ Starting default (STDIO) server... ทุกครั้งที่ launch บน stderr จึงเป็นเหตุผลที่ pipe ยังทำงานได้

transport มาตรฐานอีกแบบคือ Streamable HTTP: แต่ละข้อความเป็น POST ไปยัง endpoint เดียว และ reply เป็น JSON object หรือ stream ของ Server-Sent Events ที่ scoped กับ request — wire format ที่บทที่ 14 parse ด้วยมือ semantic เหมือนกันทั้งสองแบบ เพราะ transport คือ binding: มันกำหนด framing และ delivery ไม่ใช่ความหมาย⁴

คำสั่งข้างบนส่ง tools/list และไม่มีอะไรอีก ภายใต้ revision ปัจจุบัน request นี้ malformed และ server ที่ conform ต้อง reject

ตั้งแต่ 2026-07-28 เป็นต้นมา MCP เป็น stateless protocol และ specification ระบุโดยไม่อ้อมค้อม:

The Model Context Protocol (MCP) is a stateless protocol: all the information needed to process a request is contained in the request itself. A server processes each request independently; no state should be inferred from previous requests, even those on the same connection or stream.²

ดังนั้นทุก request จึงพก protocol version ของตัวเองและ client capabilities ของตัวเอง ใน object ที่ reserve ไว้ชื่อ _meta ภายใน params field สองรายการในนั้น required ในทุก request; request ที่ขาดรายการใดรายการหนึ่งถือว่า malformed และ server must ตอบ -32602:²

ถ้าเขียนเต็ม tools/list ที่ถูกต้องจะเป็นแบบนี้ — และนี่เป็นครั้งสุดท้ายที่บทนี้แสดง metadata แบบเต็ม เพราะจากนี้ไปมันอยู่ในทุก request:

{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{"_meta":{
  "io.modelcontextprotocol/protocolVersion":"2026-07-28",
  "io.modelcontextprotocol/clientCapabilities":{"elicitation":{"form":{}}},
  "io.modelcontextprotocol/clientInfo":{"name":"bare-hands","version":"0.0.1"}}}}

capability object นั่นแหละคือการ negotiation ไม่มีขั้นตอน negotiation แยกต่างหากอีกแล้ว: client ประกาศว่าตัวเองทำอะไรได้ในแต่ละ request, server ประกาศว่าตัวเองทำอะไรได้ใน result และทั้งสองฝั่งห้ามใช้ feature ที่อีกฝั่งไม่ได้ claim server ที่ต้องการ capability ซึ่ง client ไม่ได้ประกาศ must ตอบ -32021 และระบุ capability ที่ขาดใน data.requiredCapabilities server ที่พูด version ที่ขอมาไม่ได้ must ตอบ -32022 และ list version ที่พูดได้²

client ที่ต้องการคำตอบล่วงหน้าถามได้: server/discover เป็น RPC แบบ mandatory ที่ return supported versions, capabilities, identity และ block optional ของ instructions ในหนึ่ง round trip⁵ การเรียกเป็น optional แต่การ implement ไม่ใช่

คำสั่งทำงานได้ ภายใต้ revision ปัจจุบันมันไม่ควรทำงาน และเหตุผลที่มันทำงานควรถูกวัดมากกว่าถูกเล่าเป็นย่อหน้า เพราะมันคือสภาพของ ecosystem ทั้งหมดในหนึ่งบรรทัด

probe reference server ตามวิธีที่ specification บอกให้ client สมัยใหม่ probe:

echo '{"jsonrpc":"2.0","id":1,"method":"server/discover","params":{"_meta":{
  "io.modelcontextprotocol/protocolVersion":"2026-07-28",
  "io.modelcontextprotocol/clientCapabilities":{}}}}' \
  | npx @modelcontextprotocol/server-everything stdio

{"jsonrpc":"2.0","id":1,"error":{"code":-32601,"message":"Method not found"}}

นั่นคือ branch ที่สามของ compatibility rule: DiscoverResult หมายถึง modern, error สมัยใหม่ที่ recognize ได้หมายถึง modern-but-wrong-version และ อย่างอื่นทั้งหมด — รวมถึง -32601 — หมายถึง legacy ให้ fallback ไป handshake initialize³ ดังนั้นทำแบบนั้น โดยขอ revision ปัจจุบัน:

→ {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2026-07-28",
   "capabilities":{},"clientInfo":{"name":"bare-hands","version":"0.0.1"}}}

← {"result":{"protocolVersion":"2025-11-25","capabilities":{"tools":{"listChanged":true},
   "prompts":{"listChanged":true},"resources":{"subscribe":true,"listChanged":true},
   "logging":{},"tasks":{…},"completions":{}},"serverInfo":{"name":"mcp-servers/everything",
   "title":"Everything Reference Server","version":"2.0.0"},"instructions":"…"}}

client ขอ 2026-07-28 และ server ตอบ 2025-11-25 วันที่ 7 กันยายน 2026 official reference server — npm package @modelcontextprotocol/server-everything, version 2026.8.31, เผยแพร่ 31 สิงหาคม 2026 — ยังไม่ implement revision ปัจจุบัน TypeScript SDK ที่มันสร้างอยู่บนก็เช่นกันตามวันที่: release 1.30.0 ออกวันที่ 27 กรกฎาคม 2026 หนึ่งวันก่อน revision นี้

อ่านผลลัพธ์ ไม่ใช่ซุบซิบ เกือบทุกอย่างที่เขียนเกี่ยวกับ MCP อธิบาย protocol ที่มี handshake initialize, session, request roots/list ที่ server ส่งให้ client และ HTTP+SSE transport ทั้งสี่อย่างหายไปแล้วหรือกำลังจะหายไป เวลาอ่านอะไรก็ตามเกี่ยวกับ MCP รวมถึงหน้านี้ สิ่งแรกที่ต้องมองหาคือ revision number

และเหตุผลที่คำสั่งแรกสุดทำงานได้ระบุไว้ใน specification ว่าเป็น hazard ไม่ใช่ feature:

some legacy servers do not validate that a request arrives after initialize and would process an era-ambiguous method (such as tools/call) under legacy semantics. Probing yields a deterministic failure instead.³

วัดแล้ว: ส่ง tools/list ไปยัง server นั้นโดยไม่มี handshake เลย return catalogue เต็ม method ที่ควรถูกปฏิเสธกลับถูกให้บริการ ซึ่งเป็นเหตุผลตรง ๆ ที่ specification บอกให้ probe ด้วย server/discover ก่อน แม้คุณจะ support เฉพาะ version สมัยใหม่ก็ตาม

MCP มีสามฝ่าย และความแตกต่างระหว่างสองฝ่ายแรกคือสิ่งที่คนมักยุบรวมกัน:

Server. process หรือ service ที่ expose resources, tools และ prompts อาจเป็น local หรือ remote ก็ได้ มันทำงานเป็นอิสระ และงานทั้งหมดของมันคือพื้นที่โฟกัสเดียว⁶

กฎ “server หนึ่งตัวพอดี” ไม่ใช่ bookkeeping แต่มันคือสิ่งที่ทำให้ design principle ด้านล่าง implement ได้ และนี่คือประโยคที่ควรเก็บจาก specification หากคุณจะเก็บเพียงประโยคเดียว:

Servers should not be able to read the whole conversation, nor “see into” other servers. Servers receive only necessary contextual information. Full conversation history stays with the host. Each server maintains isolation. Cross-server interactions are controlled by the host.⁶

นี่พลิก mental model ที่คนส่วนใหญ่มีตอนเข้ามา weather server ที่คุณเชื่อมกับ assistant ของคุณ ไม่ได้ เห็นสิ่งที่คุณถาม มันเห็น tools/call พร้อม arguments ที่ model เลือก และไม่มีอะไรอีก — ไม่เห็น turns ก่อนหน้า ไม่เห็น system prompt ของคุณ ไม่เห็นผลลัพธ์ที่ calendar server เพิ่ง return เมื่อกี้ หาก server สองตัวต้องร่วมมือกัน host จะถือ value จากตัวหนึ่งไปอีกตัวหนึ่งอย่างตั้งใจ เพราะ model ขอให้ทำ นี่คือเหตุผลที่ isolation เป็น security property ที่บทที่ 30 พึ่งพา: server ที่ถูก compromise มี blast radius เล็กและชัดเจน และการขยาย radius นั้นต้องให้ host ร่วมมือ

คำสั่งแรกขอ tools จาก server นั้นและได้สิบสามรายการ ถามคำถามอีกสองแบบ มันก็ตอบเช่นกัน: resources/list return เจ็ดรายการ, prompts/list return สี่รายการ ไม่มีรายการใดโผล่มา เพราะไม่มีอะไรถาม และนี่พาเรามาถึงแกนการสอนของ MCP ซึ่งอยู่ใน specification เป็นตารางที่แทบไม่มีใคร quote:

ไม่ใช่ “สามวิธีในการ expose capability” แต่คือสามคำตอบของคำถามว่า ใครตัดสินใจว่าสิ่งนี้เกิดขึ้น model ตัดสินใจ call tool แอปพลิเคชันตัดสินใจแนบ resource คนตัดสินใจ run prompt ถ้าคุณเข้าใจผิด feature ยังทำงานได้ แต่มันทำงานผิดจังหวะและผิดเหตุผล

วิธีที่ชัดที่สุดในการรู้สึกถึงมันคือ calendar นี่คือ server ที่ expose calendar เดียวกันสามครั้ง หนึ่งครั้งต่อ primitive ใน Node เปล่า ๆ ร้อยบรรทัด ไม่มี dependency:

const TOOL = {
  name: "create_event",
  description: "Create a calendar event. Writes to the calendar.",
  inputSchema: {
    type: "object",
    properties: {
      title:    { type: "string", description: "Event title." },
      startsAt: { type: "string", format: "date-time", description: "Start, ISO 8601 UTC." },
    },
    required: ["title"],
  },
};

switch (method) {
  case "resources/read":                                          
    return ok(id, { contents: [{ uri: "calendar://week",
      mimeType: "application/json", text: JSON.stringify(EVENTS) }],
      ttlMs: 60000, cacheScope: "private" });

  case "prompts/get":                                             
    return ok(id, { description: PROMPT.description, messages: [{ role: "user",
      content: { type: "text", text: `Read calendar://week and draft a plan. ` +
        `Focus: ${params.arguments?.focus ?? "balance"}.` } }] });

  case "tools/list":                                              
    return ok(id, { tools: [TOOL], ttlMs: 300000, cacheScope: "public" });
}

รันมันและถามทั้งสามแบบ output จริง หนึ่งข้อความต่อหนึ่งบรรทัดบน wire ห่อบรรทัดไว้ที่นี่เพื่อแสดงบนหน้า โดยละ _meta ของ request และ identity block ของ server:

→ resources/read  {"uri":"calendar://week"}
← {"resultType":"complete","contents":[{"uri":"calendar://week",
   "mimeType":"application/json","text":"[{\"id\":\"e1\",\"title\":\"Standup\",
   \"startsAt\":\"2026-09-07T09:00:00Z\"},{\"id\":\"e2\",\"title\":\"Design review\",
   \"startsAt\":\"2026-09-09T15:00:00Z\"}]"}],"ttlMs":60000,"cacheScope":"private"}

→ prompts/get    {"name":"prepare_week","arguments":{"focus":"deep work"}}
← {"resultType":"complete","description":"Read the week and draft a plan.",
   "messages":[{"role":"user","content":{"type":"text",
   "text":"Read calendar://week and draft a plan. Focus: deep work."}}]}

→ tools/call     {"name":"create_event","arguments":{"title":"Dentist",
                  "startsAt":"2026-09-10T08:30:00Z"}}
← {"resultType":"complete","content":[{"type":"text",
   "text":"Created e3: Dentist at 2026-09-10T08:30:00Z"}],
   "structuredContent":{"id":"e3","title":"Dentist","startsAt":"2026-09-10T08:30:00Z"},
   "isError":false}

สาม method, สาม shape, calendar เดียว ทีนี้ประเด็นคือ:

แทบทุกคนทำทั้งสามอย่างนี้ให้เป็น tools ผลลัพธ์คือ catalogue ที่การอ่านซึ่งแอปพลิเคชันควร attach เงียบ ๆ ต้องแข่งขันเพื่อ attention ของ model กับการเขียนที่ต้อง approval และสิ่งหนึ่งที่คนอยากได้เป็นปุ่มกลับถูกฝังอยู่ใน schema การทำให้ถูกไม่เสียอะไร และตัดสินได้ก่อนเขียนโค้ดสักบรรทัด

calendar tool มี required argument หนึ่งตัวคือ title และ optional startsAt ลองขอให้มันสร้าง event โดยไม่มี date แล้วสิ่งที่น่าสนใจจะกลับมา:

→ tools/call {"name":"create_event","arguments":{"title":"Dentist"}}

← {"resultType":"input_required",
   "inputRequests":{"when":{"method":"elicitation/create","params":{"mode":"form",
     "message":"When should \"Dentist\" start?",
     "requestedSchema":{"type":"object",
       "properties":{"startsAt":{"type":"string","format":"date-time"}},
       "required":["startsAt"]}}}},
   "requestState":"eyJ0aXRsZSI6IkRlbnRpc3QifQ=="}

server ไม่ได้ส่ง request มัน ตอบ request ที่ได้รับ ด้วย resultType: "input_required" และ description ว่ายังต้องการอะไร client เก็บคำตอบจากคน แล้วส่ง call เดิมอีกครั้ง — ด้วย id ใหม่ โดยถือ inputResponses และ echo requestState แบบ opaque กลับไป:

→ tools/call {"name":"create_event","arguments":{"title":"Dentist"},
   "inputResponses":{"when":{"action":"accept",
     "content":{"startsAt":"2026-09-10T08:30:00Z"}}},
   "requestState":"eyJ0aXRsZSI6IkRlbnRpc3QifQ=="}

← {"resultType":"complete","content":[{"type":"text",
   "text":"Created e3: Dentist at 2026-09-10T08:30:00Z"}],"isError":false}

นี่คือ Multi Round-Trip Requests ที่ introduce ใน revision ปัจจุบัน และมันแทนที่ design เก่าที่ server ส่ง JSON-RPC requests กลับไปหา clients transport specification ตอนนี้ระบุกฎแบบตรง ๆ: “servers do not initiate JSON-RPC requests and clients do not send JSON-RPC responses”⁴ มี initiative ทิศทางเดียว และมันเป็นของ host

client-side features สองอย่างวิ่งบนกลไกนั้น และหนึ่งในนั้นมีชื่อที่จะทำให้คุณสะดุด

Elicitation คือ server ขออะไรบางอย่างจาก คน: form ที่มี JSON Schema จำกัดอย่างตั้งใจ — flat objects, primitive properties, ไม่มี nesting — เพื่อให้ client ใด ๆ render ได้โดยไม่ต้องมี layout engine มันมีกฎแข็ง: servers must not ใช้ form mode เพื่อขอ “passwords, API keys, access tokens, or payment credentials” และ must ใช้ URL mode สำหรับสิ่งเหล่านั้น ซึ่งส่งผู้ใช้ไปยังหน้าที่ client ไม่เคยอ่าน⁷

Sampling คือ server ขอ generation จาก model ของ host เพื่อให้ server ฉลาดได้โดยไม่ต้องถือ API key และนี่คือคำเตือนด้านศัพท์ เพราะคำนี้มีความหมายอื่นในคอร์สนี้อยู่แล้ว: นี่ไม่ใช่ sampling ของบทที่ 17 ไม่มีอะไรเกี่ยวกับ temperature, top-p หรือ shape ของ probability distribution ตรงนี้คือ nested model call ที่เดินทางย้อนกลับผ่าน protocol

มีเหตุผลที่สองที่ไม่ควรรีบหยิบมันมาใช้: ณ revision นี้ sampling ถูก deprecate แล้ว พร้อมกับ roots และ logging ภายใต้ SEP-2577 พร้อม migration ที่พูดตรงมาก — “integrate directly with LLM provider APIs instead of Sampling”⁸ ไอเดียไม่ได้ล้มเหลวทางเทคนิค แต่มันอธิบาย surface area ของตัวเองให้คุ้มไม่ได้ และ protocol ที่ลบสิ่งต่าง ๆ ได้สุขภาพดีกว่า protocol ที่ทำไม่ได้

Statelessness ฟังดูเหมือนรายละเอียด wire-format จนกว่าคุณจะทดสอบ ลองเอา exchange สามข้อความข้างบน แล้วรันแต่ละข้อความใน process แยกกัน — node calendar.mjs ใหม่เอี่ยม ไม่มี shared memory ไม่มีอะไรถูกถือข้ามไป:

process A   tools/call (no date)   → resultType: input_required
                                     requestState: eyJ0aXRsZSI6IkRlbnRpc3QifQ==
process B   tools/call (with the answer, same requestState)
                                   → resultType: complete
                                     "Created e3: Dentist at 2026-09-10T08:30:00Z"
process C   resources/read calendar://week
                                   → events: 2  (Standup, Design review)

Process B ซึ่งไม่เคยเห็นคำถาม กลับ complete multi-round-trip call ที่ process A เริ่มไว้ได้ นั่นคือประเด็นของ requestState: continuation เดินทางในข้อความ ดังนั้นไม่มีอะไรขึ้นกับว่า process เป็นตัวเดิมหรือไม่

Process C คือความล้มเหลว event ถูกสร้างแล้วแต่ไม่อยู่ตรงนั้น — เพราะ toy server เก็บ EVENTS ไว้ใน module-level array และ module-level array คือ connection state note ของ specification เรียกความผิดพลาดนี้อย่างแม่นยำ:

an open connection, such as a STDIO process, is not a conversation or session: clients may interleave unrelated requests on the same transport, and a server must not treat connection or process identity as a proxy for conversation or session continuity.²

วิธีแก้ที่กำหนดไม่ใช่ session แต่คือ explicit handle: creation tool return opaque identifier และทุก call ภายหลังรับมันเป็น argument ธรรมดา protocol ไม่มี concept ของมันเลย — “from the wire's perspective a handle is an ordinary string in a tool result and an ordinary argument to subsequent tool calls”⁹ ซึ่งทำให้ model เป็นฝ่ายถือมัน และทำให้ server เป็นฝ่าย validate ว่า caller นี้ได้รับอนุญาตให้ใช้มันในทุก call เพราะ handle คือชื่อ ไม่ใช่ permission

ทุก tool ที่ server expose คือ schema ที่เข้าไปใน prompt ของคุณทุก request และบทที่ 24 วัดไว้แล้วว่าสิ่งนั้นทำอะไรกับ window MCP เพิ่ม line item ที่สองซึ่งมองข้ามง่าย ดังนั้นทั้งสองอย่างควรถูกนับบน reference server ข้างบน

13 tool definitions (name + description + inputSchema):  1,307 tokens
  cheapest tool, get-tiny-image                              52
  costliest tool, gzip-file-as-resource                     235
server `instructions`, returned by discovery:               312 tokens
                                                          ------
one server, connected, before it is used:                 1,619 tokens

ข้อสังเกตสองอย่าง อย่างแรกคือเลขคณิต: เชื่อม server ขนาดนี้ห้าตัว แล้วประมาณแปดพัน tokens ของ window จะถูกจับจองทุก turn ตลอดไป ไม่ว่า model จะใช้มันหรือไม่ — ซึ่งเป็นกลไกเบื้องหลังการลดจาก 150,000 เหลือ 2,000 ที่บทที่ 24 quote และเป็นเหตุผลที่ just-in-time tool discovery มีอยู่

อย่างที่สองคือ security note ที่สวมชุดบัญชี instructions คือ natural-language text ที่ server author เขียน ซึ่งลงไปอยู่ใน prompt ของ host และ tool descriptions ข้าง ๆ ก็เหมือนกัน specification บอกว่าควรทำอย่างไรกับสิ่งนี้ใน security principles ของตัวเอง: tool annotations และ descriptions “should be considered untrusted, unless obtained from a trusted server” และ hosts “must obtain explicit user consent before invoking any tool”¹ การเชื่อม MCP server ไม่ใช่การเพิ่ม dependency แต่คือการให้คนแปลกหน้า 1,619 tokens ใน system prompt ของคุณ และสิทธิ์ที่จะถูก call บทที่ 30 คือสิ่งที่เกิดขึ้นเมื่อคนแปลกหน้านั้นเป็นศัตรู

ทุกอย่างในส่วนนี้เป็นจริงสำหรับ protocol revision 2026-07-28 ซึ่งเป็น version ปัจจุบัน อ่านเมื่อ 7 กันยายน 2026 revision ลงวันที่เป็น YYYY-MM-DD และวันที่คือครั้งล่าสุดที่มี backwards-incompatible change¹⁰ normative document คือ TypeScript file ชื่อ schema/2026-07-28/schema.ts; JSON Schema ข้าง ๆ generated จากมัน นั่นคือเหตุผลที่ specification ในที่นี้ถูกอ่านเป็น TypeScript และเหตุผลที่การสอน MCP จากอย่างอื่นคือการสอนคำแปล

governance change ที่อยู่ใต้ตารางนั้นสำคัญกว่าแต่ละแถว revision นี้รับ feature lifecycle and deprecation policy: features มีสถานะ Active, Deprecated หรือ Removed, feature ที่ deprecated จะ document migration path ของตัวเองและอยู่ใน specification อย่างน้อยสิบสองเดือนก่อนมีสิทธิ์ถูก remove และมี registry ที่ list ทุกอย่างที่ตอนนี้อยู่ในสถานะ Deprecated⁸ ก่อน policy นี้ “deprecated” ใน AI protocol หมายถึงอะไรก็ตามที่ blog post ล่าสุดพูด ตอนนี้มันหมายถึงวันที่

นี่คือคำศัพท์ของทั้ง block ในที่เดียว

สองรายการในนั้นควรมีประโยคของตัวเอง เพราะเป็นจุดที่ความสับสนอยู่จริง

MCP เทียบกับ A2A ไม่ใช่ rivalry และทั้งสอง specification ก็พูดแบบนั้น A2A documentation ขีดเส้นด้วยสิ่งที่อยู่ปลายทางอีกฝั่ง: MCP “defines how an AI agent interacts with and utilizes individual tools and resources, such as a database or an API” โดย tool ทำ “specific, often stateless, functions”; A2A address agents ซึ่งเป็น “more autonomous systems” ที่ “reason, plan, use multiple tools, maintain state over longer interactions, and engage in complex, often multi-turn dialogues” summary ของมันเองคือประโยคที่ควรจำ: “A2A is about agents partnering on tasks, while MCP is more about agents using capabilities.”¹¹ ทั้งสองซ้อนกันได้ — application ใช้ A2A เพื่อไปถึง agents อื่น และ agent แต่ละตัวใช้ MCP เพื่อไปถึง tools ของตัวเอง บทที่ 25 ขีดเส้นนั้นใน process เดียว ระหว่างการถาม sub-agent กับการส่ง conversation ให้มัน; A2A ขีดเส้นนั้นระหว่างองค์กร

MCP เทียบกับ ACP คือ comparison ที่ premise เก่าแล้ว ซึ่งเป็นเหตุผลที่ควรตอบ Agent Communication Protocol เคยเป็น open standard แยกสำหรับ agent-to-agent messaging documentation ของมันเองตอนนี้เปิดด้วย notice: “ACP is now part of A2A under the Linux Foundation!”¹² คำตอบตรงไปตรงมาสำหรับ “MCP or ACP?” ในเดือนกันยายน 2026 คือคำถามนี้มี option น้อยกว่าที่หน้าที่ติดอันดับแนะนำอยู่หนึ่งตัว

และ comparison ที่คนถามมากที่สุด mcp vs api มีคำตอบที่น่าสนใจน้อยที่สุด: MCP คือ API สิ่งที่มันเพิ่มไม่ใช่พลัง แต่คือ conventions — ชุด method names คงที่, discovery call, control hierarchy เหนือ primitives และ isolation model คุณยอมเสียเสรีภาพในการออกแบบ interface เอง และได้ทุก host ที่พูด protocol นี้กลับมา ซึ่งเป็น trade ที่ทุก protocol เคยเสนอมาเสมอ

ตอนนี้คุณอ่าน specification ได้โดยไม่ต้องมีคนแปล แยก resource จาก tool จาก prompt ได้ด้วยการดูว่าใครคุมมัน พิมพ์ request เองได้เมื่อ client library โกหกคุณ และลงวันที่บทความ MCP ใด ๆ ที่อ่านได้จาก deprecated features ที่มันยังสอนว่าเป็นของปัจจุบัน

สิ่งที่คุณยังไม่ได้ทำคือ ship server หนึ่งตัว บทที่ 27 เขียน server เดียวกันสองครั้ง — TypeScript และ Python วางคู่กัน เพราะ MCP เป็นพื้นที่ที่ bilingual จริง ๆ หนึ่งเดียวในคอร์สนี้ และตัวเลขบอกเช่นนั้นทั้งสองทาง บทนั้นครอบคลุม live transports ทั้งสองอย่างให้ถูกต้อง, inspector, packaging และอีกครึ่งของ protocol ที่บทนี้ตั้งใจเว้นไว้: authorization เพราะทันทีที่ server ของคุณเป็น remote แทนที่จะเป็น subprocess บน laptop ของคุณเอง client ของคนแปลกหน้าจะยื่น token มา และกฎของ specification ว่าคุณทำอะไรกับมันได้บ้างนั้นเข้มผิดปกติ

ซึ่งนำไปสู่คำถามที่บทถัดไปต้องตอบ และมันไม่ใช่คำถามที่เป็นมิตร: หาก token มาถึง server ของคุณ และมันถูก issue ให้ audience ของคนอื่น อะไรกันแน่ที่หยุดคุณไม่ให้ forward มันต่อ

ทุก quotation, method name, error code และ rule ในบทนี้อ่านจาก Model Context Protocol specification, revision 2026-07-28, เมื่อ 7 กันยายน 2026 ทุก trace ผลิตขึ้น locally บน Node 22: toy calendar server ยาว 101 บรรทัด ไม่มี dependency และ reference server คือ npm package ที่เผยแพร่ตามชื่อด้านล่าง ไม่มี paid API ถูก call เพื่อเขียนบทนี้ — ไม่มีอะไรในนี้ต้องใช้ model ซึ่งในตัวมันเองก็คือประเด็น

Measurements: @modelcontextprotocol/server-everything@2026.8.31, เผยแพร่ 31 สิงหาคม 2026, built on @modelcontextprotocol/sdk@1.30.0, เผยแพร่ 27 กรกฎาคม 2026 — หนึ่งวันก่อน revision ที่บทนี้อธิบาย มันตอบ server/discover ด้วย -32601, negotiate 2025-11-25 เมื่อถูกขอ 2026-07-28 และ serve tools/list โดยไม่มี handshake เลย catalogue ของมันคือ 13 tools ใน 7,663 bytes; token counts คือ o200k_base ผ่าน tiktoken บน name, description และ inputSchema ของแต่ละ definition ซึ่งเป็นสิ่งที่ provider render เข้า prompt ของคุณ ไม่ใช่น้ำหนักของ JSON-RPC frame

Anthropic, Code execution with MCP: building more efficient agents, 4 November 2025, คือแหล่งที่มาของตัวเลข 150,000-to-2,000 ที่ quote และใช้ในบทที่ 24 และเพียง reference ที่นี่