Apa itu server MCP? Cara kerja MCP dan MCP UI di 2026

Pada 1 April 2025, Invariant Labs menerbitkan sebuah tool bernama add. Tool itu menerima dua angka dan mengembalikan jumlahnya. Deskripsinya juga memuat blok bertanda IMPORTANT, tidak terlihat di antarmuka klien, yang menyuruh model membaca ~/.cursor/mcp.json dan ~/.ssh/id_rsa lalu mengirim kedua file itu keluar melalui parameter cadangan. Model menurut. Pengguna hanya melihat penjumlahan.

Demonstrasi itu adalah pengantar paling berguna tentang server MCP yang saya tahu, karena memperlihatkan dua sisinya sekaligus. Protokolnya bekerja persis seperti yang dirancang: klien AI menemukan sebuah tool, membaca deskripsinya, lalu memanggilnya. Model kepercayaannya adalah bagian yang belum dibangun siapa pun.

Apa itu server MCP

Server MCP adalah program yang menyediakan tool, data, dan prompt bagi aplikasi AI melalui Model Context Protocol (MCP). Dokumentasi resminya mendefinisikan MCP sebagai “standar open source untuk menghubungkan aplikasi AI ke sistem eksternal.” Klien AI seperti Claude, ChatGPT, Visual Studio Code, atau Cursor terhubung ke server, menanyakan apa yang ditawarkannya, lalu memanggil kemampuan itu atas nama pengguna.

Anthropic mengumumkan MCP pada 25 November 2024 bersama enam server siap pakai: Google Drive, Slack, GitHub, Git, Postgres, dan Puppeteer. OpenAI mengadopsinya pada Maret 2025. Google DeepMind menyusul pada April. Pada Desember 2025, Anthropic menyerahkan protokol ini ke Agentic AI Foundation, sebuah dana terarah di bawah Linux Foundation yang didirikan bersama oleh Anthropic, Block, dan OpenAI.

Masalahnya adalah jumlah koneksi yang berlipat. Dahulu setiap aplikasi AI yang ingin mengakses GitHub membuat konektornya sendiri, dan setiap penyedia membuat koneksi untuk tiap aplikasi AI. Sepuluh model dan sepuluh alat dapat berarti seratus integrasi. MCP menguranginya menjadi dua puluh: tiap klien menerapkan protokol sekali, dan tiap sistem menyediakan satu server.

Anggap saja MCP sebagai peti kemas untuk integrasi AI. Sebelum ada peti kemas, setiap pelabuhan memuat setiap kargo dengan tangan, dengan derek dan awaknya sendiri. Peti kemas menstandarkan kotaknya, sehingga kapal, derek, dan truk mana pun bisa memindahkan kargo apa pun. Peti kemas tidak menstandarkan isi kotak, dan tidak pernah memeriksa isinya. MCP menawarkan tawar-menawar yang sama. Ingat baik-baik paruh kedua ini; ia akan muncul lagi di bagian keamanan.

Cara kerja server MCP

Spesifikasi saat ini, versi 2026-07-28, menggunakan pesan JSON-RPC 2.0 di antara tiga peran. Deskripsinya sendiri hanya tiga baris: host adalah “aplikasi LLM yang memulai koneksi”, klien adalah “konektor di dalam aplikasi host”, dan server adalah “layanan yang menyediakan konteks dan kemampuan.”

Host, klien, server

Host adalah aplikasi tempat Anda mengetik: Claude Desktop, sebuah IDE, atau agen buatan Anda sendiri. Di dalamnya, satu klien berjalan untuk setiap koneksi server. Server berada di sisi seberang dan berbicara dengan sistem yang sebenarnya, entah itu database Postgres, GitHub API, atau folder di disk Anda. Host menentukan apa yang dilihat model dan apa yang harus disetujui pengguna. Server menentukan apa yang akan dilakukan sistem di belakangnya.

1. Host Claude Desktop · sebuah IDE · agen Anda sendiri

   menampilkan tool ke model, meminta persetujuan pengguna

2. Klien satu per koneksi server

   berbicara JSON-RPC lewat stdio atau Streamable HTTP

3. Server MCP tool · resource · prompt

   menjelaskan apa yang ditawarkan dan menjalankan panggilan

4. Sistem di belakangnya database · API SaaS · file lokal

   mengerjakan tugasnya

Tool, resource, dan prompt

Sebuah server bisa menawarkan tiga jenis hal:

• Tool adalah fungsi yang bisa dijalankan model: create_issue, query_orders, send_email. Masing-masing punya nama, deskripsi, dan JSON Schema untuk input-nya.
• Resource adalah konteks dan data untuk dibaca pengguna atau model: sebuah file, skema database, atau sebuah record.
• Prompt adalah pesan dan alur kerja bertemplat yang bisa dipilih pengguna, misalnya “ringkas pull request ini”.

Tool mendapat perhatian paling besar karena tool bertindak. Karena itu pula tool membawa risiko paling besar.

Satu panggilan tool, langkah demi langkah

Revisi 2026-07-28 membuat MCP menjadi stateless. Tidak ada lagi handshake initialize; setiap permintaan membawa versi protokol dan kemampuan klien di field _meta, dan server wajib mengimplementasikan metode server/discover agar klien bisa bertanya sejak awal apa yang didukung server. Satu panggilan tool kini berjalan seperti ini:

1. Pengguna meminta: buat tiket untuk bug ini

2. Langkah 1

   Penemuan

   • Klien dapat memanggil server/discover untuk versi dan kemampuan
3. Langkah 2

   Daftar tool

   • tools/list mengembalikan nama, deskripsi, dan skema input
4. Langkah 3

   Model memilih tool

   • Host meneruskan definisi tool ke model
5. Langkah 4

   Persetujuan pengguna

   • Spesifikasi menyatakan host wajib mendapat persetujuan eksplisit sebelum memanggil tool apa pun
6. Langkah 5

   Panggilan

   • tools/call dengan argumen, versi protokol di _meta

7. Input kurang? Server mengembalikan input_required; klien mencoba lagi dengan jawabannya

   Langkah 6

   Hasil

8. Hasil kembali ke model sebagai konteks

Langkah 6 adalah hal baru di revisi ini. Server yang butuh informasi tambahan tidak lagi mengirim permintaannya sendiri balik ke klien. Server mengembalikan hasil bertanda input_required, klien mengumpulkan jawabannya, lalu klien mengulang panggilan semula. Spesifikasi menyebutnya pola Multi Round-Trip Request.

Transport: stdio dan Streamable HTTP

Spesifikasi mendefinisikan dua transport standar:

• stdio: klien menjalankan server sebagai subproses dan bertukar pesan JSON-RPC yang dipisahkan baris baru melalui standard input dan output. Begitulah cara sebagian besar server lokal berjalan, dan artinya server berjalan di mesin Anda dengan hak akses Anda.
• Streamable HTTP: setiap pesan adalah HTTP POST ke satu endpoint, dan balasannya kembali sebagai objek JSON atau aliran event yang terikat pada permintaan itu. Begitulah cara server jarak jauh yang di-hosting berjalan.

Transport lama HTTP+SSE secara resmi sudah deprecated. Revisi 2026-07-28 juga menghapus sesi di tingkat protokol beserta header Mcp-Session-Id; server yang butuh state lintas panggilan kini membuat handle sendiri dan menerimanya kembali sebagai argumen tool biasa.

Otorisasi

Otorisasi di MCP bersifat opsional, dan hanya berlaku untuk HTTP. Untuk stdio, spesifikasi mengatakan server sebaiknya mengambil kredensial dari environment. Untuk HTTP, server MCP yang dilindungi bertindak sebagai resource server OAuth 2.1. Server wajib menerbitkan OAuth Protected Resource Metadata (RFC 9728) agar klien bisa menemukan authorization server-nya. Klien wajib menyebut server mana tepatnya yang dituju sebuah token (resource indicator RFC 8707). Server wajib menolak token apa pun yang tidak diterbitkan untuknya, dan panduan keamanannya menyebut “token passthrough”, yaitu meneruskan token klien tanpa diubah ke API hilir, sebagai hal yang dilarang secara eksplisit.

Aturan terakhir itu lebih penting daripada kelihatannya. Server yang meneruskan token apa pun yang diterimanya berubah menjadi proxy bagi siapa saja yang memegang token.

Apa yang ditambahkan MCP UI: server yang mengembalikan antarmuka

Jawaban berupa teks berhenti berguna begitu pengguna perlu membandingkan empat puluh baris, mengubah formulir dengan dua belas field, atau menyetujui sekumpulan perubahan satu per satu. “MCP UI” adalah nama yang dicari orang untuk solusinya: server mengembalikan antarmuka interaktif yang tampil di dalam klien AI, di samping percakapan.

Statusnya perlu dijelaskan dengan tepat. Gagasan ini bermula sebagai proyek komunitas MCP-UI. OpenAI membangun mekanisme serupa dalam Apps SDK. Proyek MCP mengusulkan standar bersama dengan keduanya pada 21 November 2025, lalu menerbitkan MCP Apps pada 26 Januari 2026 sebagai ekstensi resmi MCP yang pertama. Paket MCP-UI kini menerapkan spesifikasi itu dan menjadi tempat komunitas menguji pengembangan berikutnya.

Jadi MCP UI hari ini berarti MCP Apps. Ia resmi, dan ia adalah ekstensi, bukan protokol inti. Ekstensi bersifat opsional: klien dan server sama-sama harus mendukungnya, dan dokumentasinya terus terang menyatakan bahwa “dukungan host berbeda-beda di tiap klien.” Dokumentasi MCP Apps mencantumkan Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam, dan Archestra.AI sebagai host yang mendukung. Server yang tool-nya mengembalikan UI tetap harus berfungsi untuk klien yang hanya menampilkan teks.

Secara mekanis, MCP Apps memakai ulang bagian-bagian MCP sendiri:

1. Deskripsi tool menyertakan _meta.ui.resourceUri yang menunjuk ke sebuah resource ui://.
2. Host mengambil resource itu, yaitu halaman HTML beserta skripnya, dan bisa memuatnya lebih dulu sebelum tool dipanggil.
3. Host menampilkannya di iframe ber-sandbox yang tidak bisa membaca halaman induk, cookie-nya, maupun penyimpanannya.
4. Aplikasi dan host berkomunikasi lewat postMessage dalam dialek JSON-RPC milik MCP. Aplikasi bisa meminta panggilan tool, dan host yang memutuskan mana yang diizinkan.

Biayanya nyata. Anda kini mengirimkan front end web di dalam aplikasi milik orang lain, dengan content security policy yang harus Anda deklarasikan, aturan rendering yang tidak Anda kendalikan, dan fallback teks untuk setiap host yang mengabaikannya. Keuntungannya, pekerjaan persetujuan tidak lagi berupa transkrip chat. Daftar contoh yang cocok dalam dokumentasinya sendiri diakhiri dengan “menyetujui laporan pengeluaran, meninjau perubahan kode, atau memilah issue”, dan itulah inti jujurnya: MCP UI paling bagus untuk keputusan, bukan untuk hiasan.

Contoh Tajo yang hanya membaca

Permukaan Alto MCP milik Tajo menyediakan query_contacts untuk mencari kontak yang tersimpan di ruang kerja terhubung. Cari satu kontak yang sudah ada berdasarkan email, lalu periksa ID, status persetujuan email, dan waktu terakhir terlihat. Alat terpisah get_contact_topic_status membaca langganan topik kontak tersebut.

Ini adalah pembacaan dari ruang kerja. Alat-alat ini tidak mengambil data terbaru langsung dari penyedia, memulai sinkronisasi, atau mengirim pesan. Hasilnya juga tidak membuktikan semua konektor penyedia aktif. Selidiki data yang hilang atau usang pada sumbernya. Hasil kosong bukan bukti bahwa orang itu tidak ada di Brevo.

Gunakan dokumentasi Tajo MCP untuk menghubungkan klien yang didukung dan memeriksa alat yang benar-benar tersedia bagi ruang kerja resmi Anda. Panel interaktif dapat membantu bila host mendukung MCP Apps; hasil teks tetap harus menjelaskan hasilnya.

Pemanggilan alat bukan sinkronisasi berkelanjutan

Sinkronisasi berulang juga membutuhkan jadwal, identitas catatan yang stabil, kemajuan tersimpan, keputusan pengulangan, dan catatan penulisan yang selesai. Aplikasi pelaksana bertanggung jawab atas semua itu. MCP menstandarkan akses alat; daftar alat tidak otomatis menyediakan aturan bisnis tersebut.

Setelah batas waktu habis, pembacaan biasanya dapat diulang. Pengiriman atau pembayaran mungkin sudah terjadi. Simpan catatan eksekusinya dan cocokkan hasil sebelum mencoba lagi. Tingkat keyakinan model tidak memberi izin atau menjadikan pengulangan aman.

Untuk penulisan kontak di tujuan, lihat panduan API Brevo. Untuk menentukan kapan kolom hasil perhitungan memerlukan sinkronisasi tersendiri, baca reverse ETL.

Tagihan keamanan datang bersama protokolnya

Keberatannya layak disampaikan secara utuh: “MCP menyerahkan daftar fungsi yang bisa menghapus data dan mengirim email kepada model probabilistik, lalu memercayai teks tulisan orang asing untuk mendeskripsikannya. Itu bukan standar integrasi. Itu serangan rantai pasok yang punya spesifikasi.” Sebagian besar keberatan itu benar. Spesifikasinya pun setuju dengan premisnya. Bagian keamanannya menyatakan bahwa tool “mewakili eksekusi kode sembarang dan harus diperlakukan dengan kehati-hatian yang sepatutnya,” bahwa deskripsi tool “harus dianggap tidak tepercaya, kecuali diperoleh dari server tepercaya,” dan bahwa MCP “tidak dapat menegakkan prinsip-prinsip keamanan ini di tingkat protokol.”

Inilah catatannya sejauh ini:

• Tool poisoning. Pengungkapan Invariant Labs pada April 2025, yaitu tool add di atas. Tulisan yang sama menjelaskan rug pull, ketika server mengubah deskripsi tool setelah Anda menyetujuinya, dan shadowing, ketika satu server jahat menulis ulang perilaku model terhadap server tepercaya.
• Server lokal yang dibobol. Pada Juli 2025, JFrog mengungkap CVE-2025-6514 di mcp-remote versi 0.0.5 sampai 0.1.15, yang memungkinkan server jahat menjalankan perintah di mesin pengguna. Pada musim panas yang sama, CVE-2025-49596 menimpa MCP Inspector milik Anthropic sendiri, yang dirilis tanpa autentikasi secara default.
• Pembengkakan scope. Praktik terbaik keamanan resmi menyebut polanya: token diberi files:* atau admin:* sejak awal karena server mencantumkan semua scope dan klien memintanya sekaligus.
• Kekhawatiran resmi. Pada Mei 2026, National Security Agency Amerika Serikat menyatakan bahwa “penyebaran pesat” MCP “telah melampaui perkembangan model keamanannya.”

Keberatan itu keliru di bagian kesimpulannya. Solusinya tidak pernah berupa berhenti menghubungkan model ke sistem; tim-tim sudah melakukannya dengan API key mentah yang ditempel ke prompt dan skrip, tanpa jejak audit sama sekali. Solusinya adalah memperlakukan server MCP seperti dependensi berhak istimewa lainnya:

• Instal server hanya dari sumber yang juga akan Anda percayai memegang kredensial yang sama di luar MCP.
• Utamakan server jarak jauh dengan OAuth dan scope sempit dibanding binary lokal yang menyimpan key berumur panjang.
• Wajibkan persetujuan manusia untuk setiap operasi tulis, dan catat siapa menyetujui apa.
• Kunci versi server, dan tinjau ulang ketika deskripsi sebuah tool berubah.
• Buka tool yang dibentuk sesuai tugas, bukan seluruh API; model tidak bisa menyalahgunakan endpoint hapus yang tidak pernah dibuka.

Protokolnya menstandarkan kotak. Memeriksa kargo tetap tugas Anda.

Bangun server MCP atau pakai yang sudah ada

Direktori publik seperti mcp.so mengatalogkan server buatan komunitas, dan banyak vendor SaaS menerbitkan server mereka sendiri. Brevo, misalnya, menyediakan server MCP yang juga dipecah menjadi server-server terpisah, sehingga agen bisa diberi akses kontak tanpa kampanye. Keputusannya bukan soal usaha, melainkan soal siapa yang seharusnya memegang bentuk tool-nya.

Server MCP mana yang sebaiknya dipakai agen Anda?

1. Vendor menerbitkan server yang mencakup tugasnya

   Pakai server dari vendor

   Server itu mengikuti API dan dipelihara oleh vendor.

2. Satu sistem, tetapi Anda butuh tindakan yang lebih sedikit atau lebih aman

   Pakai dengan scope yang dipersempit

   Berikan scope minimal dan buka hanya grup tool yang dibutuhkan agen.

3. Data internal atau sistem tanpa server

   Bangun server kecil

   Beberapa tool yang dibentuk sesuai tugas di atas API Anda sendiri, dengan autentikasi Anda sendiri.

4. Tugasnya mencakup dua sistem atau lebih

   Bangun atau adopsi lapisan yang terkelola

   Satu set tool, aturan persetujuan, dan riwayat audit untuk semuanya.

Membangun server dasar adalah bagian yang mudah. Dengan SDK resmi, server stdio yang berfungsi dengan satu tool bisa selesai dalam satu sore. Biayanya datang belakangan: OAuth untuk versi HTTP, deprecation (revisi 2026-07-28 menghentikan Roots, Sampling, dan Logging, serta Dynamic Client Registration), dan pekerjaan berkelanjutan menulis deskripsi tool yang dibaca model dengan benar. Membungkus API dengan satu tool per endpoint adalah kesalahan paling umum. Setiap deskripsi tool adalah teks yang harus dibaca dan ditimbang model, jadi daftar pendek tool yang dibentuk sesuai tugas mengalahkan seluruh permukaan API.

MCP, API, integrasi, dan iPaaS

MCP tidak menggantikan API. Hampir setiap server MCP adalah pembungkus untuk sebuah API. API tetap menjadi tempat pekerjaan dilakukan, dengan rate limit, model data, dan keanehannya sendiri. Yang diubah MCP adalah siapa yang bisa memanggilnya: model, saat runtime, memilih panggilan berdasarkan deskripsi, alih-alih developer yang menuliskannya di kode sejak awal.

Perbedaan itu menarik garis tegas terhadap dua hal lain yang sering tertukar dengannya:

• Integrasi dan iPaaS (platform utamanya dibandingkan di sini) memindahkan data sesuai jadwal atau pemicu, secara deterministik, entah ada orang di dalam chat atau tidak. Sinkronisasi malam hari untuk 40.000 pesanan ke CRM tidak boleh bergantung pada model yang memutuskan untuk melakukan 40.000 panggilan tool.
• Reverse ETL mendorong data yang sudah dimodelkan dari warehouse kembali ke tool operasional. Apa itu reverse ETL dan kapan cocok dipakai adalah topik tersendiri, dan ia adalah pipeline, bukan percakapan.
• MCP untuk momen ketika seseorang atau sebuah agen perlu bertanya, memeriksa, atau bertindak di seluruh sistem itu, sesuai kebutuhan.

Kesalahannya terjadi ke dua arah. Ada tim yang membangun server MCP untuk sinkronisasi massal, dan hasilnya pipeline yang lambat, mahal, dan tidak bisa diulang. Tim lain membangun integrasi dengan cermat lalu menyerahkan API key mentah kepada asisten AI mereka untuk menanyainya, dan hasilnya pintu samping tanpa tata kelola.

Dalam integrasi yang didukung, tugas berkelanjutan dan alat untuk memeriksanya sebaiknya memiliki batas izin yang jelas dan sama. Periksa konektor, tindakan yang diizinkan, dan hasil yang tercatat untuk alur tertentu. Dokumentasi integrasi membedakan panduan penyiapan dari alur yang masih memerlukan bukti produksi. MCP dapat menyediakan alat terpisah yang disetujui; daftar alat tidak membuktikan sinkronisasi berulang atau semua kontrol yang diperlukan sudah aktif.

Dalam 22 bulan, MCP berkembang dari enam server referensi menjadi proyek Linux Foundation yang dipakai Claude, ChatGPT, VS Code, dan Cursor. Menghubungkan model ke sebuah sistem kini menjadi bagian yang murah. Menentukan apa yang boleh dilakukannya di sana, itulah pekerjaannya.