If you have spent years maintaining business logic inside PHP applications, watching Model Context Protocol tutorials can feel like standing outside a locked door. Nearly every guide assumes TypeScript or Python. They walk through official SDKs, npm installs, and pip packages. That leaves an enormous amount of business data—customer records, order histories, inventory systems—sitting in PHP codebases that look invisible to the current wave of AI tooling.

The good news is that nothing about MCP requires those SDKs. MCP is not a library. It is a wire protocol. If your runtime can read a line of text from standard input, parse JSON, and write JSON back out, it can speak the protocol. PHP has been doing exactly that since long before LLMs existed.

What MCP Actually Is

MCP stands for Model Context Protocol. At its core, it is an open standard for connecting AI assistants to data, tools, and external APIs. Instead of building a custom integration for every assistant or model, you build one compliant interface. Any client that understands MCP can then talk to your server without knowing anything about PHP, Laravel, or your specific database schema.

Underneath, MCP uses JSON-RPC 2.0. That means every request is a simple JSON object containing a method name, parameters, and an ID. The server responds with another JSON object carrying either a result or an error.

A server exposes three primitives:

  • Tools: Actions the model can invoke. A tool might query a database, update a status, or call a third-party API.
  • Resources: Static or semi-static data the model can reference through a URI. Think of files, configuration documents, or reference datasets.
  • Prompts: Predefined templates that help the user interact with the system.

There is an important control distinction to remember. Tools are model-controlled. The assistant decides when to call one. Resources are application-controlled. The server decides what data is available and the model simply reads what is offered. Getting this right keeps your architecture predictable. You do not want a model hunting for resources that should have been tools, or vice versa.

How the Transport Works

MCP defines two transport methods, and your choice shapes how you write the PHP side.

stdio is the simplest. The MCP client launches your PHP script as a subprocess. The client writes JSON-RPC messages to your script’s standard input, and your script writes responses to standard output. There are no sockets to manage, no ports to open, and no authentication headers to parse. If your tool and your client live on the same machine, this is usually the right place to start.

Running over stdio imposes two strict rules on your PHP process. First, your application must never write non-protocol data to stdout. If you echo a debug statement or let a PHP notice leak through, you will break the client’s parser. Route all logging and diagnostics to stderr. Second, disable output buffering entirely. PHP likes to buffer stdout, especially in CGI or web contexts, but even CLI scripts can hold data. Flush every response immediately. If you are using streams, set stream_set_write_buffer(STDOUT, 0) or turn off implicit buffering so the client receives the newline the instant you send it.

Streamable HTTP works differently. Your PHP application runs as a persistent HTTP endpoint, usually reached via POST requests. This is useful when the server lives on a different host, or when you want a long-running daemon that multiple clients can reach. In PHP, this typically means running under RoadRunner, FrankenPHP, or a similar process manager rather than the traditional request-response cycle that dies after every call.

Building It in PHP

You do not need a framework to start. A minimal MCP server in PHP is a loop reading from STDIN, decoding JSON, dispatching to a handler, and encoding the result.

while ($line = fgets(STDIN)) {
    $request = json_decode($line, true);
    // route to tool or resource handler
    // write JSON-RPC response to STDOUT
}

Inside that loop, the real work is building interfaces that make sense to a model.

สร้าง schema ของเครื่องมือจากโค้ด หนึ่งในวิธีที่ทำให้เกิดปัญหาได้เร็วที่สุดคือการเขียน JSON Schemas สำหรับพารามิเตอร์ของเครื่องมือด้วยมือ ซึ่งอาจทำให้ข้อมูลไม่ตรงกับตรรกะการตรวจสอบ (validation logic) ที่ใช้งานจริง PHP มีความสามารถด้าน reflection ที่หลากหลาย คุณสามารถตรวจสอบ method signatures, อ่านกฎการตรวจสอบที่มีอยู่จากฟอร์มหรือ command objects และสร้าง schema จากข้อกำหนดเหล่านั้นได้ หากโค้ดภายในของคุณต้องการรูปแบบอีเมลที่ถูกต้อง MCP schema ของคุณก็ควรระบุเช่นเดียวกัน เมื่อกฎการตรวจสอบเปลี่ยนไป schema ก็จะอัปเดตโดยอัตโนมัติ ไม่มีการคลาดเคลื่อน ไม่มีการล้มเหลวแบบเงียบๆ

แยกข้อผิดพลาดของโปรโตคอลออกจากข้อผิดพลาดของเครื่องมือ JSON-RPC มีพื้นที่สำหรับข้อผิดพลาด (error space) ของตัวเอง จงใช้มันสำหรับโปรโตคอลที่ผิดพลาด เช่น JSON ที่รูปแบบไม่ถูกต้อง, method ที่ไม่รู้จัก หรือ request ID ที่หายไป เมื่อเครื่องมือทำงานได้อย่างถูกต้องแต่พบปัญหาทางธุรกิจ ให้ส่งผลลัพธ์ปกติพร้อมกับ error flag ภายใน payload หากเครื่องมือค้นหาลูกค้าไม่พบข้อมูลที่ตรงกัน นั่นไม่ใช่การพังของโปรโตคอล การส่งผลลัพธ์ที่มีโครงสร้างอย่าง {"found": false} ช่วยให้โมเดลเข้าใจสิ่งที่เกิดขึ้นและเลือกขั้นตอนต่อไปได้ เช่น โมเดลอาจลองค้นหาในขอบเขตที่กว้างขึ้น หรืออาจถามข้อมูลเพิ่มเติมจากผู้ใช้ แต่หากคุณโยน (throw) ข้อผิดพลาด JSON-RPC แทน โมเดลมักจะสูญเสียบริบท (context)

วางแผนสำหรับงานที่ใช้เวลานาน PHP ถูกสร้างมาเพื่อการร้องขอ (request) ระยะสั้น Web request อาจหมดเวลา (time out) ภายใน 30 วินาที และแม้แต่สคริปต์ CLI ก็อาจทำให้หน่วยความจำเต็มหรือทำให้ผู้ใช้หมดความอดทนได้ หากเครื่องมือต้องใช้เวลาหลายนาทีในการทำงานให้เสร็จ—เช่น การรวบรวมรายงานขนาดใหญ่หรือการซิงค์ข้อมูลข้ามระบบ—อย่าทำให้โมเดลต้องรอ ให้ส่ง job identifier กลับไปทันที จากนั้นจึงเปิดเครื่องมือที่สองสำหรับตรวจสอบสถานะด้วย ID นั้น คุณสามารถเก็บความคืบหน้าไว้ใน Redis, ตารางฐานข้อมูล หรือแม้แต่ไฟล์ธรรมดา (flat file) หากมีปริมาณข้อมูลน้อย โมเดลจะได้รับ ID, กลับมาตรวจสอบภายหลัง และรับผลลัพธ์ที่เสร็จสมบูรณ์ในที่สุด

ความปลอดภัยเมื่อโมเดลมีคีย์ (Keys)

การให้โมเดล AI เข้าถึงเครื่องมือไม่เหมือนกับการให้ผู้ใช้ที่เป็นมนุษย์ โมเดลทำงานเร็วมาก (ตามความหมายตรงตัว) และอาจตีความคำอธิบายผิดพลาดได้ จงปฏิบัติกับเครื่องมือที่เปิดเผยทุกตัวเสมือนเป็นความเสี่ยงในการยกระดับสิทธิ์ (privilege escalation risk)

จำกัดขอบเขตอย่างเข้มงวด อย่าเปิดเผยเครื่องมือแบบทั่วไปอย่าง run_sql ให้สร้างเครื่องมือที่เฉพาะเจาะจงและแคบลง เช่น find_customer_by_email หรือ update_order_status โมเดลควรทำได้เฉพาะสิ่งที่ระบุชื่อไว้เท่านั้น พร้อมกับพารามิเตอร์ที่คุณกำหนดไว้

แยกเส้นทางการอ่าน (read) และการเขียน (write) ออกจากกัน เครื่องมือแบบอ่านอย่างเดียว (read-only) มีความเสี่ยงต่ำกว่า ให้ใส่การดำเนินการที่ทำลายข้อมูล (destructive action) ไว้ภายใต้กลไกการยืนยันที่ชัดเจน หรือจำกัดไว้ที่เซิร์ฟเวอร์ที่สองไปเลย หากไคลเอนต์ของคุณรองรับ ให้กำหนดขั้นตอนการอนุมัติโดยมนุษย์ก่อนที่เครื่องมือการเขียนจะทำงาน

เขียนคำอธิบายเครื่องมือเสมือนว่าเป็นคำแนะนำเพิ่มเติม เพราะมันเป็นเช่นนั้นจริงๆ จงระบุให้ชัดเจนว่าเมื่อใดที่โมเดลควรเรียกใช้เครื่องมือ หากเครื่องมือใช้สำหรับค้นหาราคา ก็ให้บอกไปตรงๆ หากควรใช้หลังจากตรวจสอบ ID ลูกค้าแล้วเท่านั้น ก็ให้ระบุให้ชัดเจน คำอธิบายที่คลุมเครือจะนำไปสู่พฤติกรรมที่คลุมเครือ

กรองข้อมูลขาออกของคุณ อย่าทำ serialization ของ Eloquent model หรือ Doctrine entity ทั้งหมดแล้วเทลงในผลลัพธ์ ให้ส่งคืนเฉพาะฟิลด์ที่โมเดลจำเป็นต้องใช้จริงๆ ฟิลด์ภายใน—เช่น ราคาทุน, บันทึกพนักงาน, ID ฐานข้อมูลที่ควรเก็บไว้ภายใน—ไม่ควรถูกส่งผ่านเครือข่าย จงระบุรูปแบบการส่งคืน (return shape) ให้ชัดเจน

สุดท้าย จงบันทึก (log) ทุกอย่าง บันทึกชื่อเครื่องมือ, อาร์กิวเมนต์ที่ส่งมา และผลลัพธ์ หากโมเดลเริ่มทำงานวนลูปในคิวรีที่ใช้ทรัพยากรสูง หรือพยายามทดสอบเครื่องมือในลำดับที่ไม่คาดคิด ล็อกของคุณจะเป็นวิธีเดียวที่คุณจะมองเห็นมัน

เริ่มต้นที่ไหนดี

คุณไม่จำเป็นต้องขออนุญาตจากผู้ดูแล SDK เพื่อเชื่อมต่อแอปพลิเคชัน PHP ของคุณกับผู้ช่วย AI คุณแค่ต้องการ JSON-RPC, loop และระเบียบวินัยในการจัดการ stdout

อย่าเพิ่งรีบสร้าง API ทั้งหมดของคุณใหม่เป็นเครื่องมือ MCP ตั้งแต่วันแรก ให้เลือกการทำงานแบบอ่านอย่างเดียวมา 3 อย่างที่คนในองค์กรของคุณถามถึงบ่อยๆ เช่น การตรวจสอบสถานะคำสั่งซื้อ, การดึงข้อมูลสรุปของลูกค้า หรือการแสดงรายการใบแจ้งหนี้ล่าสุด ให้ห่อหุ้ม (wrap) สิ่งเหล่านั้นเป็นเครื่องมือ, ส่งผ่าน stdio และให้เพื่อนร่วมงานลองใช้งานดู สังเกตว่าโมเดลทำอะไรได้ดีและติดขัดตรงไหน คุณจะเรียนรู้จากเครื่องมือ 3 อย่างนั้นได้มากกว่าการวางแผนทำ 30 อย่างเสียอีก

MCP คือสะพาน ไม่ใช่สิ่งที่จะมาแทนที่แอปพลิเคชันของคุณ โค้ด PHP ของคุณรู้จักธุรกิจของคุณดีอยู่แล้ว โปรโตคอลนี้เพียงแค่ช่วยให้โมเดลข้ามฝั่งมาเพื่อถามคำถามกับมันเท่านั้น