HeadlinesBriefing favicon HeadlinesBriefing.com

Mengapa MCP Selalu Ide Buruk

Hacker News •
×

Mengapa MCP Selalu Ide Buruk

Baru-baru ini saya menghadiri acara seharian yang berfokus pada hal terbaru dan terbaik di dunia MCP. Meskipun semua pembicara luar biasa dan tampak penuh semangat dengan pekerjaan mereka, saya jujur sudah muak dengan MCP. Ini adalah protokol yang mengerikan yang dibangun untuk masa ketika LLM tidak secerdas itu, dan kita sudah melewatinya.

Sejarah Singkat

MCP dirilis pada November 2024 oleh tim Anthropic sebagai protokol yang dirancang untuk membantu agen terhubung ke layanan dan sumber data eksternal. Model saat itu masih relatif primitif, setidaknya dibandingkan dengan yang kita miliki sekarang. Kita bahkan belum memiliki Claude Code saat itu, dan alur kerja agen tujuan umum jauh kurang andal. Pengguna mulai melihat kegunaan memberi model AI mereka akses ke layanan eksternal. Hal ini memungkinkan tingkat produktivitas yang belum pernah kita lihat sebelumnya. Kita melihat ledakan adopsi MCP, bertepatan dengan pertumbuhan serupa, jika tidak lebih ledakan, dalam adopsi LLM di seluruh ekonomi. Seiring waktu, MCP terus berkembang di bawah pengelolaan Anthropic sebelum akhirnya disumbangkan ke Agentic AI Foundation, di bawah Linux Foundation, pada 2025.

Kompleks Industri MCP

Dengan pertumbuhan adopsi yang masif, pengguna mulai menambahkan banyak server MCP ke pengaturan mereka, dan mereka mulai mengalami masalah pembengkakan konteks. Setiap server akan datang dengan banyak alat, masing-masing dengan skemanya sendiri, yang mulai membebani konteks semua model ini. Pengembang Harness menemukan banyak trik di sekitar ini, termasuk pola pencarian/eksekusi generik yang sekarang ditawarkan oleh platform seperti Composio, Mint MCP, dan Pipedream. Semuanya secara efektif memecahkan masalah memiliki satu tempat untuk meletakkan kredensial Anda untuk berbagai layanan eksternal dan memberi agen Anda seperangkat alat minimal (untuk mengurangi pembengkakan konteks) yang dapat digunakan untuk mengaksesnya. Saya ingin menjelaskan bahwa ini adalah hal yang baik, untuk jangka pendek.

Dengan semua hal yang kita bangun di sekitar MCP, yang tidak kita pertimbangkan, atau mungkin kita abaikan, adalah model menjadi lebih baik. Kita sekarang memiliki seluruh sistem yang didedikasikan untuk memantau server MCP, memastikan responsnya baik, memastikan agen dapat dengan mudah mengakses alat, mengetahui skema, dan menentukan apa yang perlu kita berikan kepada agen agar mereka dapat membuat panggilan yang tepat pada waktu yang tepat.

Kejutan, Kejutan, Lab Besar Benar

Model menjadi lebih baik. Sekarang mereka mampu mengeksekusi kode di komputer, beralasan tentang codebase besar, dan secara umum bertindak jauh lebih otonom dari sebelumnya. Bagian besar dari pekerjaan itu adalah menulis/menjalankan skrip untuk tujuan coding. Efek samping (apakah itu?) adalah sekarang mereka jago memanggil API secara langsung. Mereka bisa menulis skrip, mengkomposiskan banyak layanan berbeda, dan memanggil API yang belum pernah mereka lihat sebelumnya, semuanya dalam alur kerja yang berguna dengan intervensi minimal dari sisi pengguna.

LLM menjadi sangat jago di hal ini, Cloudflare bahkan meluncurkan Code Mode, cara yang lebih baik untuk menggunakan MCP dengan membuat LLM mengkomposiskan berbagai panggilan ke dalam skrip yang dapat dieksekusi di sandbox. Tapi bahkan lebih baik dari itu, LLM sudah menemukan cara menggunakan perintah --help untuk menemukan CLI, jadi mereka tidak lagi butuh server MCP untuk mengakses banyak layanan yang tersedia melalui API terdokumentasi atau CLI. Sebagian besar server MCP layanan remote pada akhirnya membungkus API yang sudah ada.

Lalu Apa Lagi?

Kita hapus sebagian besar server MCP kita. Itu saja. Agen dengan akses terminal bisa menggantikan sebagian besar server MCP dan seringkali lebih mampu.

Masih ada beberapa masalah, seperti CLI mengembalikan respons yang bisa dibaca mesin (JSON/XML, dll.), yang cenderung sangat verbose dan berat pada penggunaan token, tapi kita punya cara untuk memperbaikinya. Sebagian besar alternatif sudah ada: API HTTP terdokumentasi, negosiasi konten standar, dan mekanisme autentikasi yang matang. Kita harus mulai menstandarisasikan bagaimana agen menggunakan API HTTP secara langsung. Misalnya, klien agen bisa menambahkan header untuk mengidentifikasi diri mereka sebagai agen, dan server bisa otomatis mengirimkan data respons kepada mereka sebagai Markdown atau teks alih-alih HTML atau....