Cara Kami Membangun Server MCP Real-Time untuk Godot

Mengapa “Real-Time” Penting untuk Server MCP di Godot

Kebanyakan demo MCP bekerja dengan dunia berbentuk REST: model mengajukan pertanyaan, alat mengembalikan JSON, dan tidak ada yang peduli jika perjalanan pulang-pergi memakan waktu dua detik. Godot berbeda. Editor memiliki scene tree langsung, impor sumber daya, dan loop mode play. Jika server MCP Anda memblokir utas utama—atau hanya melihat dump proyek yang basi—klien AI berhenti terasa seperti co-pilot dan mulai terasa seperti editor file jarak jauh dengan langkah ekstra.

Saat kami merancang Godot MCP untuk VberAI, briefnya jelas:

• Asisten AI (Cursor, Claude, Windsurf, dan klien MCP serupa) harus mengoperasikan editor, bukan hanya membaca file .gd dari disk
• Tindakan seperti membuat node, mengganti nama, melampirkan skrip, dan kueri seleksi harus selesai sementara editor tetap responsif
• Konteks mode play dan mode edit harus tetap jujur—alat harus gagal dengan lantang saat operasi tidak aman di tengah play

Postingan ini adalah kisah rekayasa: bagaimana kami membangun server MCP real-time yang berada di samping Godot, bukan berpura-pura bahwa proyek adalah repositori statis.

Masalah dengan MCP “Hanya File” untuk Mesin

Pendekatan naif menggoda:

1. Arahkan server MCP ke folder proyek
2. Ekspos read_file / write_file / list_dir
3. Biarkan model menciptakan GDScript dan berharap editor memuat ulang dengan baik

Itu berhasil untuk situs dokumentasi. Itu gagal untuk pekerjaan mesin karena:

• Kepemilikan scene hidup di memori — perbedaan .tscn yang belum disimpan, scene yang terbuka, dan seleksi editor tidak terlihat di disk
• Pipeline impor bersifat stateful — menulis PNG tidak sama dengan “sumber daya siap dengan pengaturan impor yang benar”
• Sinyal dan jalur node adalah data grafik — edit string merusak koneksi secara diam-diam
• Latensi bertambah — setiap konfirmasi “apakah node muncul?” menjadi pemindaian sistem file penuh lagi

Kami membutuhkan permukaan MCP yang mencerminkan apa yang sudah dilihat manusia di dock Godot: hierarki, properti berbentuk inspector, dan pegangan sumber daya—bukan hanya string jalur.

Tinjauan Arsitektur

Pada tingkat tinggi, Godot MCP adalah tiga lapisan yang bekerja sama:

Klien MCP (Cursor / Claude / …)
        │  JSON-RPC melalui stdio atau transport lokal
        ▼
Server MCP (proses jembatan VberAI Godot)
        │  antrian perintah + amplop hasil
        ▼
Plugin Editor Godot (GDExtension / plugin editor)
        │  panggilan tertunda di utas utama
        ▼
Scene Tree Editor / ResourceDB / Editor Skrip

Lapisan 1 — Permukaan alat MCP

Alat sengaja dibuat kecil dan berbentuk kata kerja:

• godot_get_scene_tree — snapshot scene yang diedit dengan tipe node dan jalur
• godot_create_node / godot_set_property
• godot_attach_script / godot_run_script_snippet (dijaga)
• godot_list_resources / godot_get_selection

Kami menghindari satu alat raksasa do_anything. Alat yang lebih kecil lebih mudah divalidasi, lebih mudah dicatat, dan lebih sulit disalahgunakan model menjadi tambalan tanpa batas.

Lapisan 2 — Jembatan real-time

Jembatan adalah tempat “real-time” sebenarnya hidup:

• Saluran dua arah antara proses MCP dan plugin editor (socket lokal atau named pipe dalam pengembangan; build produk dapat membungkus ini di belakang helper desktop VberAI)
• Antrian perintah yang menserialkan mutasi sehingga dua panggilan alat yang tumpang tindih tidak dapat berlomba dengan scene tree
• ID permintaan + pengakuan sehingga klien MCP dapat menunggu “diterapkan” tanpa polling sistem file
• Detak jantung / kelangsungan editor sehingga klien tahu kapan Godot keluar di tengah sesi

Lapisan 3 — Keamanan utas utama di Godot

API UI dan scene Godot tidak bebas utas. Plugin tidak pernah memutasi node pada utas I/O MCP. Sebagai gantinya:

1. Perintah MCP tiba di utas jembatan
2. Muatan diantrekan
3. Panggilan balik editor yang ditunda berjalan di utas utama (call_deferred / kait bingkai idle)
4. Amplop hasil mengembalikan sukses, kesalahan terstruktur, atau “coba lagi setelah mode play berakhir”

Pola itu membosankan secara desain. Membosankan adalah yang menjaga “real-time” agar tidak menjadi “pembekuan editor acak.”

Membuatnya Terasa Real-Time (Tanpa Berbohong Tentang Latensi)

“Real-time” di sini tidak berarti latensi nol yang ajaib. Itu berarti lingkaran umpan balik cocok dengan cara manusia bekerja di editor.

Snapshot vs aliran

Prototipe awal mengembalikan seluruh scene tree pada setiap panggilan. Itu runtuh pada pengaturan open-world yang besar. Kami beralih ke:

• Snapshot dangkal secara default (root + satu level, atau fokus seleksi)
• Pembacaan terbatas jalur saat model sudah mengetahui subpohon
• Token perubahan opsional sehingga panggilan berikutnya dapat bertanya “apa yang berubah sejak X?” alih-alih menserialisasi ulang semuanya

Hasil yang ramah perbedaan

Hasil alat menyertakan:

• String NodePath kanonik
• Nama tipe (CharacterBody2D, Control, …)
• Kunci properti yang memetakan dengan bersih ke bidang inspector
• Peringatan eksplisit saat penulisan diterapkan tetapi scene masih kotor / belum disimpan

Model beriterasi lebih cepat ketika hasil terlihat seperti status UI, bukan seperti postingan blog teks bebas.

Perilaku mode play yang terbatas

Mode play adalah tempat setengah dari tiket “AI merusak proyek saya” dimulai. Aturan kami:

Mode	Diizinkan	Diblokir atau dijaga
Edit	Mutasi scene, kueri sumber daya	Penghapusan proyek yang merusak tanpa konfirmasi
Play	Sebagian besar baca / kueri node runtime	Edit struktural ke scene yang diedit
Transisi	Petunjuk tunggu / coba lagi	No-op diam-diam

Kesalahan yang jelas mengalahkan kecerdasan. Jika model tidak dapat mengedit selama play, respons MCP mengatakannya dalam bentuk terstruktur—sehingga klien dapat memberi tahu pengguna untuk menghentikan play, lalu coba lagi.

Masalah Sulit yang Kami Hadapi (dan Pertahankan)

1. Editor bukan database

Urutan node, hubungan pemilik, dan scene yang dikemas berinteraksi dengan cara yang terlihat sederhana di GIF dan berantakan di .tscn. Kami mengandalkan API Godot sendiri (Node, EditorInterface, pemuat sumber daya) daripada menciptakan model scene paralel yang akan melenceng.

2. Skrip vs scene sebagai dua sumber kebenaran

Melampirkan skrip tidak sama dengan memastikan skrip dikompilasi dan nama kelas terselesaikan. Server melaporkan hasil kompilasi/lampiran secara terpisah. Itu menghentikan kelas kegagalan “alat bilang sukses, Inspector tidak menunjukkan apa-apa.”

3. Sesi multi-jendela / multi-proyek

Pengembang membuka lebih dari satu instance Godot. Jembatan terikat ke ID sesi editor eksplisit sehingga panggilan alat tidak mendarat di proyek yang salah setelah akhir pekan tidur + buka ulang.

4. Batas keamanan

Server MCP yang dapat menulis ulang scene sangat kuat. Transport lokal-pertama, daftar izin alat eksplisit, dan tanpa eksfiltrasi cloud diam-diam dari pohon proyek penuh adalah non-negosiasi. “Asisten AI” dan “shell jarak jauh atas game Anda” harus tetap menjadi kategori produk yang berbeda.

Bagaimana Ini Cocok dengan AI Studio dan VberAI Lainnya

Godot MCP adalah operator mesin. Bagian pelengkap:

• VberAI Studio (AI Studio) — struktur desain-ke-mesin untuk Figma/PSD → hierarki Control; MCP kemudian menghubungkan tombol dan mengganti nama node setelah impor
• Unity MCP / Cocos MCP — ide MCP yang sama, host editor dan aturan keamanan yang berbeda
• AI Super Matting — membersihkan alpha sebelum tekstur menjadi sumber daya mesin yang kemudian ditetapkan MCP

Tesis bersama: AI harus menyentuh permukaan produksi langsung (editor, aset, scene), bukan hanya repositori sebagai teks.

Tips Praktis Jika Anda Membangun MCP Mesin Sendiri

1. Antrekan mutasi di utas utama mesin — jangan pernah berpura-pura mesin game adalah server tanpa berbagi
2. Pilih alat kecil dengan skema — validasi mengalahkan puisi prompt
3. Kembalikan NodePath dan tipe, bukan prosa — model membutuhkan pegangan yang dapat dioperasikan
4. Sertakan mode play/edit dalam setiap respons — ambiguitas di sini menghancurkan kepercayaan
5. Ukur perjalanan pulang-pergi hingga “terlihat di dock” — bukan hanya waktu encode JSON

Jika Anda hanya mengoptimalkan proses MCP dan mengabaikan jembatan editor, Anda akan mengirim loop halusinasi cepat.

Kesimpulan

Membangun server MCP real-time untuk Godot berarti memperlakukan editor sebagai kolaborator langsung: jembatan yang diantrekan, aman untuk utas utama; alat yang berbentuk seperti tindakan editor; dan kejujuran tentang batas mode play. MCP hanya file lebih mudah—dan tidak lengkap untuk pekerjaan asli scene.

Ingin jalur yang sudah dikirim alih-alih prototipe akhir pekan? Mulai dengan VberAI Godot MCP, hubungkan klien MCP pilihan Anda, dan coba panggilan alat pertama yang sepele: daftarkan scene tree saat ini, lalu buat satu node di bawah seleksi. Loop tunggal itu—kueri → mutasi → lihat di dock—adalah produknya. Segala sesuatu yang lain adalah rekayasa keandalan di sekitarnya.