Spesifikasi MCP – Perubahan versi 2025-06-18

• Pembaruan baru spesifikasi MCP berfokus pada metadata terstruktur dan manajemen konteks. Tujuannya adalah meningkatkan ekstensibilitas serta memperkuat interoperabilitas antar berbagai sistem
• Field data baru ditambahkan, dan field wajib yang sudah ada didefinisikan dengan lebih spesifik. Berkat hierarki dalam struktur metadata, kini dimungkinkan mendukung cara ekstensi terpisah untuk tiap sistem
• Aturan yang jelas disajikan untuk pelacakan konteks dan pembaruan properti, dengan penekanan pada kemampuan pengelolaan informasi status yang konsisten dibanding sebelumnya
• Prosedur manajemen izin dan validasi data dinyatakan dalam spesifikasi protokol. Beberapa field yang baru ditambahkan juga dirancang dengan mempertimbangkan kompatibilitas dengan versi protokol di masa mendatang
• Dukungan integrasi lintas platform: menyediakan landasan agar data konteks dapat dipertukarkan secara konsisten di berbagai platform AI dan lingkungan layanan cloud

---

• MCP(Model Context Protocol) adalah protokol untuk pertukaran metadata konteks antar berbagai sistem AI seperti model machine learning atau large language model

Major changes

1. Dukungan JSON-RPC batching dihapus (PR #416)
2. Dukungan structured tool output ditambahkan (PR #371)
3. Server MCP diklasifikasikan sebagai OAuth resource server, dan metadata resource terlindungi ditambahkan agar lebih mudah menemukan Authorization server yang terhubung (PR #338)
4. Klien MCP wajib mengimplementasikan Resource Indicator dari RFC 8707 (untuk mencegah server berbahaya memperoleh access token) (PR #734)
5. Security considerations dan best practice dalam spesifikasi Authorization diperjelas, serta ditambahkan halaman terpisah panduan keamanan
6. Fitur Elicitation (permintaan pertanyaan) ditambahkan, sehingga server dapat meminta informasi tambahan kepada pengguna (PR #382)
7. Dukungan Resource Links ditambahkan, sehingga hasil pemanggilan tool dapat menyertakan tautan resource (PR #603)
8. Saat negosiasi versi protokol, header MCP-Protocol-Version wajib di HTTP (PR #548)
9. SHOULD pada Lifecycle Operation diubah menjadi MUST (referensi)

---

Other schema changes

1. Field _meta ditambahkan ke lebih banyak tipe antarmuka (PR #710), beserta penjelasan penggunaan yang tepat
2. Field context ditambahkan ke CompletionRequest, sehingga dapat menyertakan variabel yang sebelumnya sudah diinterpretasikan (PR #598)
3. Field title ditambahkan untuk tampilan yang ramah pengguna dan terpisah dari identifier program (name digunakan untuk identifier kode, title untuk tampilan) (PR #663)

[kernel00]

Komentar di Hacker News agak mengecewakan. Sepertinya mereka cuma melihat stdio, padahal sekarang remote MCP server maupun registry yang menjadi perantara untuk itu bermunculan di mana-mana....

[GN⁺]

Komentar Hacker News

• Hal terbesar yang kupelajari dari ikut gelombang hype MCP (Machine Context Protocol) adalah bahwa untuk pengembangan perangkat lunak backend, sebenarnya tidak perlu memakai MCP. Ada bagian yang secara arsitektural memang tidak cocok. Terutama di lingkungan seperti Elixir, menurutku lebih tidak masuk akal lagi. Jika setiap API punya server terpisah, artinya kamu menjalankan 500 microservice untuk 500 API. Aku baru sadar setelah benar-benar mencoba 20 macam server MCP, dan ujung-ujungnya MCP itu cuma bungkus untuk function call. Setiap API cukup dibuat sebagai modul terpisah, bukan server. Tidak perlu repot mengikuti spesifikasi MCP terbaru, atau memperbarui ratusan microservice setiap kali spesifikasinya berubah. Kesimpulanku: ini cuma kompleksitas yang tidak perlu
  • Kecuali klien terhubung langsung ke tiap microservice tanpa lewat gateway atau BFF, ya tinggal taruh MCP di depan seluruh layanan dan ekspos fungsinya seperti API, GraphQL, RPC, dan pendekatan lama lainnya. Rasanya pada dasarnya ini antarmuka yang dioptimalkan untuk LLM. Tool call berbasis spesifikasi OpenAPI juga sudah cukup bisa dipakai. Bagaimanapun, membayangkan semua microservice hanya saling berkomunikasi lewat MCP itu terlalu berlebihan
  • Aku melihat MCP hanya sebagai solusi integrasi bergaya plugin yang memungkinkan function call seperti Claude tanpa biaya API. Kalau kamu sudah memakai API dan tidak sedang terburu-buru, ini bukan pilihan yang benar-benar diperlukan
  • Sebenarnya menurutku MCP adalah protokol standar yang menghubungkan klien dan model. Bukan sekadar wadah yang membungkus tool call
  • Benar, menaruh satu server MCP untuk tiap API memang tidak akan bisa diskalakan. Jika memakai sesuatu seperti nango.dev, satu server bisa mencakup lebih dari 400 API. Ia juga menangani autentikasi, memberi visibilitas, dan menyediakan berbagai antarmuka untuk tool call langsung. (Sebagai catatan, aku pendirinya)
  • Aku bahkan melangkah lebih jauh dan menganggap budaya memaksa LLM mengeluarkan JSON itu sendiri bodoh. Terlalu banyak waktu dan usaha terbuang untuk menyesuaikan diri dengan format rewel yang pada dasarnya tidak disukai LLM. DSL berbasis teks yang jauh lebih ketat justru terbukti jadi alternatif yang lebih baik. Dulu di era GPT 3.5, cukup memberi beberapa contoh sederhana di prompt saja sudah cukup untuk membuatnya mengeluarkan DSL berbasis bahasa Inggris secara andal. Tapi bahkan pada model terbaru pun masih ada catatan bahwa sebagian JSON schema kadang diabaikan. Rasanya seperti memaksa pasak bulat ke lubang persegi; semoga orang-orang berhenti memaksakannya
• Aku benar-benar senang sekarang ada jalur sederhana menuju server MCP yang terautentikasi. Aku ingin menyampaikan terima kasih yang tulus kepada komunitas MCP dan tim Anthropic
  • Aku kurang paham kenapa server MCP diperlukan. Kalau agen ingin melakukan RPC, bukankah cukup pakai RPC saja?
• Menarik sekali bahwa spesifikasi intinya ditulis dalam TypeScript, bukan OpenAPI atau yang lain. Pasti ada alasan yang masuk akal, tapi tetap terasa tidak terduga
  • Aku penasaran kenapa itu terasa mengejutkan. Aku juga banyak memakai TypeScript, tapi belum pernah memikirkannya dari sudut pandang seperti ini, jadi aku ingin tahu keputusan desain bahasa seperti apa yang ada di baliknya
• Aku sangat senang dengan diperkenalkannya challenge WWW-Authenticate. Sekarang jadi jelas bahwa server MCP bisa mengarahkan klien ke alur OAuth milik penyedia resource, lalu cukup menerima header Authorization: Bearer ...
• Menurutku ini memang <i>sebagian besar</i> adalah kompleksitas yang tidak perlu, tapi sayang sekali fitur batch execution hilang. Seru juga waktu mengimplementasikan pola “selesaikan semua pekerjaan ini, lalu kirim hasilnya sekaligus”. Memang klien bisa saja menggabungkan respons batch sendiri, tapi tetap saja itu menyenangkan
  • Setuju. Fitur batch di JSON-RPC benar-benar sempat terasa seperti, “wah, ini keren juga.” Sayang hilang dari spesifikasi, tapi aku paham karena pada akhirnya memang menambah kompleksitas juga
• Menurutku elicitation (pemrosesan prompt berbasis penalaran) adalah hasil terbesar. Salah satu server MCP favoritku adalah server SSH buatanku sendiri. Dengan itu, 90% pekerjaan pengelolaan server bisa diotomatisasi. Autentikasinya kuatur lewat file konfigurasi, tapi jadi agak merepotkan karena setiap kali harus terhubung ke server baru, aku perlu mengubahnya manual
  • Untuk kasus seperti ini, menurutku kamu juga bisa memakai sesuatu seperti fabfile.org. Kalau percakapannya memang tidak butuh LLM, rasanya lebih baik tetap dijaga privat
• Selama beberapa hari terakhir aku bermain-main membuat wrapper dataset dengan MCP

1. Menurutku ini salah satu eksperimen paling menarik di ranah LLM. Memang hal serupa bisa dilakukan juga dengan API & tool call yang sudah ada, tapi sangat mengesankan bisa sekadar melempar URL MCP untuk Claude ke teman yang tidak terlalu teknis, lalu mereka bisa mencobanya hanya dengan beberapa klik
2. Aku memakai SDK csharp, dan fitur autentikasinya masih hanya ada di branch, jadi masih sangat awal. 95% waktuku selama integrasi MCP habis untuk mengimplementasikan autentikasi (wajib kalau bukan build lokal). Mungkin akan membaik setelah dokumentasinya lebih lengkap, tapi untuk sekarang prosesnya masih cukup merepotkan
3. Ada juga masalah kurangnya ekspos log untuk developer. Aku berharap Claude, di web (bukan desktop), bisa menampilkan log request/response di mode developer agar terlihat apa yang sedang dikirim-terima dan di mana error terjadi. Aku lama kebingungan gara-gara masalah refresh autentikasi, lalu baru sadar belakangan bahwa aku ternyata mencatat endpoint yang salah. Kalau logging MCP lebih baik, mestinya itu bisa selesai dalam hitungan menit. Di desktop dan MCP inspector justru berjalan baik
4. Kekhawatiran terbesarku adalah penanganan pekerjaan berdurasi panjang. Dataset yang kuungkap berisi banyak dokumen PDF. Claude sendiri tampaknya tidak bisa menangani PDF (kalau ada yang tahu caranya, tolong beri tahu!) jadi untuk sekarang aku melewatkannya dulu ke gemini untuk diubah jadi teks lalu mengirimkannya lewat MCP. Dokumen sederhana berjalan baik, tapi dokumen panjang butuh waktu pemrosesan lama. Saat ini aku hanya mengirim pesan “sedang diproses, silakan coba lagi nanti”. Memang ada progress API, tapi karena harus mempertahankan koneksi terus ke server (dan di Cloudflare koneksinya akan terputus setelah jangka waktu tertentu), rasanya ada batas kepraktisannya. Akan sangat bagus kalau ada cara membuat LLM memeriksa lagi setelah x detik, mengerjakan hal lain dulu sebelum itu, lalu “menangguhkan eksekusi sementara” sampai timernya habis. Saat ini, kalau koneksi dipertahankan, LLM jadi tidak bisa melakukan apa-apa dan hanya menunggu; kalau kuberi job ID lalu dikembalikan, sering kali responsnya jadi tidak lengkap dan konteks keseluruhannya hilang. Menurutku ini bisa menjadi hambatan besar untuk pekerjaan yang memang perlu lebih dari 10 menit

• Pekerjaan yang berjalan lama masih merupakan topik yang sedang dibahas secara terbuka. Setahuku MCP memang berniat menyelesaikan hal ini ke depannya. Ada berbagai usulan yang sedang dibicarakan, dan karena kita tidak selalu tahu apakah suatu pekerjaan akan memakan waktu lama, memisahkan API untuk pekerjaan panjang saja bukan solusi yang cukup. Aku juga punya usulan untuk menyelesaikan ini secara terpadu tautan diskusi
• Aku sangat senang melihat spesifikasi MCP membaik dengan cepat. Di setiap rilis baru, aku bisa melihat satu per satu kekurangan yang kurasakan saat integrasi MCP mulai ditutup
• Menarik bahwa perubahan spesifikasi cukup butuh satu persetujuan saja untuk bisa di-merge
• Aku masih tidak paham MCP ini sebenarnya menyelesaikan masalah apa. Secara pribadi, yang terpikir hanya peran saat ingin membuat prototipe cepat di laptop. Kalau aku membuat program lokal, aku justru ingin punya kendali jauh lebih rinci atas toolset yang bisa diakses LLM. Misalnya kalau memikirkan server MCP untuk Google Calendar pun, MCP tidak terlalu menghemat waktu. Aku bisa langsung memakai API yang sama, dan aku juga harus menjelaskan secara eksplisit ke LLM kapan dan bagaimana memanggil Google Calendar, jadi rasanya tidak ingin mendelegasikan itu ke pihak ketiga. Selain itu, terlepas dari bahasa apa yang dipakai untuk menulis MCP, agak berat juga kalau harus sembarang menjalankan proses di lingkunganku. Kalau di sisiku semuanya Python tapi aku harus meminta pengguna memasang runtime TypeScript tambahan, itu bisa jadi masalah. Kalau wrapper MCP punya kerentanan, isu keamanan juga mengkhawatirkan. Di lingkungan server, pembenarannya bahkan lebih sulit lagi. Untuk memanggil sesuatu di mesin berbeda tanpa perlu tahu detail implementasinya, RPC sudah merupakan cara yang sangat bagus. MCP terasa seperti hanya menambahkan middleware yang opinionated dan masalah keamanan di atasnya
  • Yang tidak kupahami, kenapa semua MCP yang kulihat sejauh ini berbasis command dan tidak memakai antarmuka HTTP. Kalau berbasis HTTP, cukup jalankan satu server dan seluruh organisasi bisa memakainya bersama, tanpa semua orang harus mengatur toolchain masing-masing
  • Berbeda dari pendekatan lama di mana backend memaksakan alur tetap, keuntungan memakai MCP adalah LLM sendiri bisa langsung melakukan orkestrasi. Misalnya saat melakukan pencarian web, ia bisa merevisi query dan mencoba lagi sampai menemukan informasi yang diinginkan. Saat memecahkan masalah khusus lewat CLI pun, ia bisa memakai berbagai tool dalam urutan yang tepat. Ini adalah bentuk pengorganisasian yang tidak mungkin dilakukan dengan alur tetap
  • Bagian yang diselesaikan MCP adalah menstandardisasi cara agen yang berpusat pada LLM terhubung ke berbagai kemampuan seperti tool lewat satu protokol standar
  • Ada bagian yang sangat kurasakan juga. Saat dipakai langsung, rasanya memang sangat lambat. Aku bahkan keluar dari pekerjaanku 2 tahun lalu untuk membuat klien LLM, tapi sampai sekarang belum juga berhasil mengintegrasikan Google Calendar. Setidaknya dari sudut pandang pengguna, kegunaan MCP adalah menutup celah-celah sementara seperti ini. Aku teringat bagaimana dulu tiga baris teratas di layar utama iPhone terlihat mirip, tapi baris paling bawah selalu sangat berbeda pada tiap orang. Aku merasa ke depannya tim IT dan tim pengembang akan terus membuat server MCP masing-masing sesuai kebutuhan kerja mereka sendiri