Pengendalian Ralat Pelayan MCP: Apa yang Saya Pelajari

Saya fikir saya sudah selesai selepas pelayan MCP saya berjalan buat kali pertama. Ia memulangkan senarai alatan. Ia memanggil satu alatan. Saya rasa berjaya.

Saya silap.

Menjalankan pelayan MCP dalam persekitaran produksi mengajar saya bahawa tutorial biasanya hanya fokus pada "happy path" (laluan lancar). Ia mengabaikan apa yang berlaku apabila sesuatu rosak. Berikut adalah apa yang saya pelajari semasa membina pelayan untuk pangkalan pengetahuan saya yang berdurasi 1,800 jam.

  • Sentiasa pulangkan kandungan untuk keputusan kosong Kebanyakan klien akan tergantung apabila menerima respons kosong. Jika carian anda tidak menemui apa-apa, jangan pulangkan kosong. Pulangkan mesej teks. Beritahu pengguna mengapa tiada keputusan dan berapa banyak item yang wujud dalam pangkalan data anda.

  • Uruskan permulaan sambungan yang perlahan Saya menggunakan pelan percuma yang akan "tidur" (sleep). Apabila ia bangun, ia mengambil masa 15 saat. Banyak klien MCP mengalami "timeout" sebelum itu. • Hantar pengepala (headers) awal untuk memastikan sambungan kekal aktif. • Tetapkan had keras pada saiz respons. Potong (truncate) keputusan yang besar supaya anda tidak mencapai had timeout.

  • Berhenti membina JSON secara manual Satu tanda petikan berganda yang tidak di-"escape" dalam tajuk telah merosakkan keseluruhan respons JSON saya. Klien terputus sambungan tanpa sebarang ralat. Gunakan rangka kerja seperti Jackson untuk mengendalikan penserialan (serialization). Biarkan perpustakaan (library) menguruskan proses "escaping" untuk anda.

  • Jangkakan pengesahan (authentication) yang tidak konsisten Klien yang berbeza mengendalikan kunci API dengan cara yang berbeza. Ada yang menggunakan pengepala (headers). Ada yang menggunakan parameter pertanyaan (query parameters). Ada yang tidak menggunakan kedua-duanya. • Sokong pelbagai cara untuk menghantar kunci. • Sentiasa pulangkan badan ralat JSON yang betul jika pengesahan gagal.

  • Tetapkan Content-Length secara eksplisit Sesetengah klien sukar dengan "chunked encoding". Jika respons anda terpotong, berhenti menggunakan pemampatan (compression). Kira saiz respons anda terlebih dahulu dan tetapkan pengepala Content-Length secara eksplisit.

Kelebihan: • Privasi: Hanya petikan (snippets) yang relevan dihantar kepada AI. • Kebolehoperasian (Interoperability): Pelayan berfungsi merentasi pelbagai klien yang berbeza. • Kesederhanaan: Pelayan saya hanya mempunyai 150 baris kod.

Kekurangan: • Ekosistem yang masih muda: Dokumentasi tidak merangkumi banyak kes terpencil (edge cases). • Hos: Anda mesti menguruskan titik akhir (endpoints) dan "cold starts" anda sendiri. • Evolusi: Protokol sering berubah.

MCP telah menukarkan nota-nota saya yang tidak digunakan menjadi alat yang berguna. Ia menjadikan data saya tersedia supaya AI boleh melakukan kerja-kerja berat.

Pernahkah anda membina pelayan MCP? Apakah ralat yang anda hadapi? Beritahu saya di ruangan komen.

Sumber: https://dev.to/kevinten10/mcp-server-error-handling-what-i-learned-building-a-production-mcp-server-for-my-1800-hour-1pha

Komuniti pembelajaran pilihan: https://t.me/GyaanSetuAi