MCP mengabaikan pelajaran berharga dari sistem terdistribusi

• MCP (Model Context Protocol) mengusung standardisasi integrasi alat AI, tetapi mengabaikan 40 tahun praktik terbaik sistem terdistribusi dan RPC
• Akibatnya di lingkungan enterprise, fitur inti seperti keandalan operasi, type safety, keamanan, observabilitas, dan manajemen biaya hilang
• MCP tidak hanya bergantung pada pustaka eksternal untuk fitur penting, tetapi juga memicu fragmentasi protokol, kompleksitas integrasi, dan beban pengelolaan audit serta keamanan
• Pelacakan terdistribusi, pengelolaan versi skema, service discovery, optimasi performa, dan kebutuhan operasional lain yang penting tetap belum terpenuhi
• Adopsi dini MCP berisiko menimbulkan kegagalan serius di enterprise: risiko operasi, pengembangan ganda, dan biaya tidak perlu, dengan euforia AI sebagai pendorong

---

Risiko yang Ditimbulkan oleh Kesederhanaan MCP

MCP (Model Context Protocol) memosisikan diri sebagai ‘USB-C untuk bidang AI’ dalam integrasi alat AI, dan menekankan kesederhanaan yang menurunkan hambatan adopsi. Namun kesederhanaan itu justru mengabaikan pelajaran yang dikumpulkan selama 40 tahun dari sistem terdistribusi, sehingga di lingkungan operasi nyata menimbulkan cacat fungsional yang fatal. Perusahaan yang saat ini mengadopsinya pada dasarnya membangun sistem di atas landasan yang menghilangkan fitur fundamental sistem RPC yang esensial.

Kesenjangan Berbahaya antara Realitas dan Harapan

Pelopor MCP memperkenalkannya sebagai infrastruktur yang production-ready, tetapi filosofi desainnya condong pada kemudahan pengembangan dan kurang kuat dalam ketangguhan operasi. AI bisa dihubungkan dalam waktu singkat, namun ketika digunakan dalam skala jutaan permintaan di bisnis nyata, kelemahan fatal akan terlihat. Ekspektasi berlebihan pasar terhadap AI menyebabkan adopsi dipercepat tanpa kematangan arsitektur, sehingga risiko kegagalan operasi meningkat.

Kesalahan Berulang dalam Sejarah 40 Tahun

• UNIX RPC (1982) memperkenalkan XDR (External Data Representation) dan IDL (Interface Definition Language) agar data antar sistem heterogen seperti integer 32-bit kompatibel dan mendeteksi kesalahan ketidaksesuaian tipe saat build-time
  MCP mengabaikan pengalaman ini, dan hanya menyediakan JSON tanpa skema serta hint non-mandatori. Error tipe muncul di runtime, AI dapat membuat tanggal yang salah, dan hal itu dapat menyebabkan kesalahan konversi data dan masalah kualitas yang fatal di keuangan, kesehatan, manufaktur, serta penggunaan operasional nyata lainnya

• CORBA (1991) menggunakan OMG IDL untuk menjamin antarmuka yang sama lintas banyak bahasa. MCP diimplementasikan terpisah per bahasa, sehingga serialisasi, penanganan error, dan detail lain tidak konsisten antar bahasa atau pustaka, memicu mimpi buruk integrasi

• REST (2000) mendapatkan skalabilitas dan keandalan besar melalui arsitektur stateless, kejelasan makna berbasis verb, dan cache header
  MCP memiliki batasan stateful/stateless yang kabur, tidak ada dukungan caching, diferensiasi makna request standar, maupun idempotency. Skalabilitas server, retry, dan load balancing menjadi sangat sulit

• SOAP/WSDL menawarkan kontrak yang mudah dibaca mesin, kemampuan otomatisasi, dan ekstensibilitas keamanan
  MCP hanya menyediakan skema JSON sederhana, tanpa kontrak machine-readable, auto-generation, type safety, dan audit keamanan. OAuth 2.1 baru ditambahkan terlambat hanya pada transport HTTP, sementara stdio bergantung pada variabel lingkungan, sehingga kontrol keamanan pun minim

• gRPC (2016) menyertakan observabilitas, pelacakan terdistribusi, streaming dua arah, deadline, dan error code terstruktur
  MCP hanya mendukung streaming satu arah berbentuk event dan menjadi tidak efisien untuk interaksi kompleks. Trace context, deadline, dan klasifikasi error yang esensial tidak memadai

Risiko ‘Cukup Pakai Pustaka Ini’

Saat pengajuan kritik terhadap cacat kritis MCP, jawabannya selalu menambah pustaka pihak ketiga (mis. mcp-oauth-wrapper, mcp-tracing-extension, mcp-schema-generator). Namun itu justru titik kegagalan protokolnya. Semakin fitur penting dipush keluar, semakin parah fragmentasi, inkonsistensi, serta perpanjangan beban pemeliharaan, keamanan, dan tanggung jawab integrasi.
Di enterprise, dalam hitungan bulan standar, audit, dan beban integrasi makin berat, sementara kebutuhan pelatihan developer dan ketergantungan eksternal menjadi tidak normal.

Penambal Darurat yang Semakin Ditumpuk

Rilis MCP 2025–03–26 seperti catatan patch untuk menambal cacat yang ditemukan terlambat di production. OAuth, manajemen sesi, atribut alat (annotation), dan notifikasi progress hanyalah fitur yang seharusnya ada sejak awal tetapi baru ditambahkan belakangan.
Pembedaan atribut alat pun awalnya tidak ada, dan autentikasi keamanan juga semula dianggap tidak perlu. Ini membuktikan kurangnya pemahaman esensial terhadap kebutuhan enterprise.

Mimpi Buruk Debugging dan Ketidakmampuan Menelusuri Operasi

di lingkungan gRPC, distributed tracing dan trace ID memungkinkan debugging cepat dan konsisten
sedangkan MCP tidak memiliki ID korelasi antarpesanan, format log yang konsisten, dan membutuhkan implementasi custom, sehingga debugging serta pelacakan error dapat memakan waktu berhari-hari
Pada sisi operasi dan bisnis pun, alokasi biaya dan pengelolaan penggunaan (header, token counting, kuota, dan sebagainya) tidak bisa dilakukan.
Dalam lingkungan cloud, fitur-fitur dasar yang seharusnya ada sama sekali tidak disediakan MCP, sehingga biaya penggunaan AI dan pelacakan tanggung jawab hampir tidak mungkin.

Masih Ada Masalah Operasional Utama yang Tersisa

• Tidak adanya service discovery membuat ketersediaan, ekspansi multi-region, dan pembaruan tanpa henti (zero downtime) tidak mungkin
• Tidak adanya pengelolaan versi skema per alat membuat risiko seluruh klien runtuh tanpa pemberitahuan saat alat diperbarui tetap mengintai
• Batas performa: overhead JSON, tidak ada connection pooling, protokol biner dan kompresi yang belum memadai, serta komunikasi berbasis proses mengulang pola usang

Risiko Serius Ketika Diterapkan di Enterprise

Saat AI mulai masuk ke area yang bertanggung jawab langsung atas pendapatan, keselamatan, dan kualitas (keuangan, medis, manufaktur, layanan pelanggan), risiko MCP meningkat.
Alih-alih mempertahankan pola integrasi enterprise yang telah matang, perusahaan menggantikannya dengan tambalan keamanan, audit, type safety, dan stabilitas operasi setelah sistem berjalan.
Strategi “cepat dibuat lalu rusak” yang bisa diterima untuk prototipe, akan berdampak fatal pada layanan penting

Arah Perbaikan dan Kebutuhan Jangka Panjang

• Jangka pendek: type safety, pelacakan terdistribusi (ID korelasi), otorisasi, format audit standar, dan pengelolaan versi skema per alat yang berdiri sendiri harus menjadi bagian inti protokol
• Operasional: service discovery, connection pooling, transfer biner, deadline, serta kebijakan error/retry yang terstandarisasi sangat dibutuhkan
• Jangka panjang: streaming dua arah, manajemen kuota dan biaya bawaan, penegakan SLA, dan orkestrasi workflow sebagai fitur enterprise-grade

Kesimpulan

Desain yang menekankan kesederhanaan MCP cocok untuk integrasi alat AI yang eksperimental dan siklus cepat, namun di lingkungan operasi enterprise dapat berujung pada risiko operasi dan biaya operasional yang fatal.
Adopsi dipercepat karena mengikuti euforia AI, dan praktik menambahkan keamanan, observabilitas, serta stabilitas operasi sebagai tambalan sesudahnya terus berulang.
Akhirnya, fragmentasi dan pengembangan ganda yang ingin dihindari protokol ini justru berpotensi muncul kembali di atas MCP.
Industri AI kini berada di persimpangan antara mengulang masalah yang selama 40 tahun telah diselesaikan dalam evolusi sistem terdistribusi, atau belajar darinya.
Jika dibiarkan, yang berulang adalah kegagalan adopsi, celah keamanan, dan mimpi buruk operasional, dengan biaya yang akan ditanggung sepenuhnya oleh enterprise

[GN⁺]

Komentar Hacker News

• Awalnya, dari judulnya saja saya kira ini hanya kisah tentang security theater yang biasa-biasa saja. Tapi setelah dibaca, saya merasa memang punya wawasan yang penting. Bagian yang paling menonjol adalah: MCP mengabaikan pelajaran ini dan memakai petunjuk non-paksaan pada JSON tanpa skema, dengan validasi tipe yang dilakukan saat runtime atau bahkan tidak dilakukan sama sekali. Misalnya, jika tool AI mengharapkan timestamp ISO-8601 tetapi menerima nilai epoch Unix, model bisa menghasilkan tanggal apa pun tanpa gagal dengan benar. Kasus semacam ini di layanan keuangan bisa membuat AI trading salah menafsirkan angka lalu melakukan transaksi dengan presisi desimal yang salah; di bidang kesehatan bisa terjadi rekomendasi dosis obat yang salah karena data pasien dengan tipe yang keliru dikonversi. Di manufaktur, presisi data sensor bisa hilang saat serialisasi JSON dan berujung masalah kontrol kualitas. Dari sudut orang yang berurusan dengan LLM setiap hari, saya memang sering melihat problem seperti ini. Saya bisa membayangkan suatu sistem yang memakai MCP akhirnya mengalami insiden besar: kalau ditelusuri rekam jejaknya, server MCP mengeluarkan data aneh, LLM menerima lalu memunculkan output halusinasi, dan hasilnya beruntun menjadi masalah yang makin besar. Jika dikombinasikan dengan kesalahan manusia, sifat LLM yang tidak punya mekanisme pengecualian (yang memicu halusinasi), dan budaya startup yang gegabah meluncurkan layanan baru, akan muncul varian bug baru. Dan jika hal ini jadi ledakan, pengguna Twitter pasti tak henti-henti berteriak bahwa AGI meretas kode peluncur nuklir—pemandangan yang tentu sangat menarik.

  • Jujur, sebelum 2023 saya menganggap bug teknis di Star Trek itu terlalu fiksi sampai mustahil terjadi. Tapi sejak LLM hadir, saya merasa hal itu memang akan benar-benar terjadi. Integrasi LLM terasa makin tidak jelas hubungannya dengan engineering, dan saya mempertanyakan rasionalitas menyerahkan seluruh infrastruktur perusahaan ke kontrol pihak eksternal. Lagi pula, dengan masalah reprodusibilitas yang ada, mengatakan “yang penting jalan” tidak bisa disebut engineering.
  • Kritik penulis sulit saya pahami. MCP memang mendukung JSON Schema, jadi respons server wajib mengikuti schema itu. Jika schema menuntut ISO-8601 tetapi server mengirim epoch Unix, itu jelas pelanggaran protokol. Di tulisan, meskipun disebut MCP mendukung JSON Schema, penulis mengklaim klien type-safe tidak bisa dibuat, padahal sudah banyak generator kode JSON Schema yang membuat klaim itu tidak akurat.
  • PEBKAC (kesalahan pengguna) sudah ada, dan LLM berada pada level yang mengotomatiskannya.
  • Soal poin bahwa salah tipe data bisa menyebabkan rekomendasi dosis obat yang keliru di healthcare, saya memang merasakan sendiri pentingnya parsing timestamp yang benar ketika dulu bekerja di telemetri medis. Mungkin ini juga alasan mengapa saya mulai menulis unit test. Saya juga pernah mengoreksi ulang timestamp header saat kondisi tanpa NTP. Semua tindakan itu dilakukan karena pertimbangan tinjauan insiden dan tanggung jawab malpraktik medis. Misalnya, selisih waktu antara saat pasien mendapat obat menjelang henti jantung dan waktu setelahnya bisa menentukan hidup-matinya. Seperti kasus Royal Mail di Inggris baru-baru ini, satu kesalahan data bisa menghancurkan hidup seseorang, dan di data medis selisih satu menit bisa mengubah segalanya.
  • MCP bertujuan untuk transportasi dan manajemen konteks. Artinya, tanggung jawab implementasi antarmuka yang masuk akal—seperti definisi dan validasi skema—berada di pihak pengguna. Ini mirip dengan kritik “HTTP tidak mendukung validasi JSON” yang memang wajar.

• MCP memang ingin jadi “USB-C dunia AI”, tapi ironisnya ini justru lebih menunjukkan masalah USB-C ketimbang prestasi MCP. USB-C memang dapat menghubungkan hampir semua hal, namun kepatuhan standarnya berantakan sama seperti parsing JSON MCP yang tidak konsisten atau ketidakpatuhan protokol. Mirip kondisi ada banyak jenis kabel USB-C, kelihatan serbaguna di permukaan tapi sebenarnya menyembunyikan realitas yang sangat kompleks. Menurut saya, API/protokol yang dipisah-pisahkan dengan jelas akan lebih baik.

  • Kegagalan paling nyata dari USB-C terlihat saat Apple memulai tren menghapus port USB-A di Mac mini M4 terbaru. Port yang bentuknya sama ternyata memberi performa yang sangat berbeda, dan pengguna baru menyadarinya jauh setelah peluncuran. Dulu, semua USB-C di desktop/laptop Apple Silicon bisa diandalkan sebagai Thunderbolt 40Gbps, sekarang beberapa hanya USB3 10Gbps. Untuk tahu mana yang mana, Anda harus mengecek spesifikasi atau melihat ikon kecil. Kalau Apple menyisakan beberapa port USB-A, batas 10Gbps akan terlihat jelas, tetapi malah itu hanya mengencerkan branding USB-C. Akhirnya, hampir semua perangkat USB-C pun tetap dipasang ke USB-A melalui adaptor, sementara varian USB-C justru lebih mahal, lebih jarang, dan kualitasnya pun terasa lebih buruk. Tapi ini dunia di mana hype dan fandom mengalahkan kegunaan dan praktik.
  • Saya tertawa terbahak-bahak membaca narasi “USB-C itu serbaguna tapi tidak transparan”. Anggap saja target tercapai, semacam begitu.

• Soal SOAP, ada pendapat bahwa “meski bertele-tele, ia mengerti sesuatu yang tak dipahami MCP”, tetapi kenyataannya saya pun tak begitu pernah benar-benar “memahami” SOAP. Saya bahkan pernah memelihara sistem SOAP warisan dan tidak punya hal positif untuk dipuji tentang SOAP. Bagi saya, SOAP tak bisa jadi role model siapa pun.

  • SOAP memang sebuah bencana besar. Menakjubkan bagaimana konsep yang seharusnya sederhana bisa dibuat begitu rumit. XML-nya kompleks, kriterianya pun tidak jelas pada WSDL maupun multipart HTTP, sampai interoperabilitas antar bahasa pun tidak terjamin (contohnya pengalaman SOAP dengan server .NET dan client Java). Begitu tren mereda, orang cenderung mengingat sisi baiknya; saya pribadi lebih memilih mengerjakan JSON API tanpa schema selama 50 tahun daripada menggunakan SOAP selama satu bulan. Secara pribadi, saya merasa protobuf dan capnp jauh lebih baik.
  • Saya melihat REST (yang secara praktis JSON-RPC) dan GraphQL tetap berusaha mengejar fitur yang pernah ditawarkan SOAP dan SOA. Sayang setiap teknologi baru datang dan kita seolah membuang semua yang baik di teknologi sebelumnya.
  • Protokol yang memuat kata “Simple” ternyata tak pernah benar-benar simple. Saya punya firasat kita akan segera melihat protokol semacam SMCP.
  • Saya suka berbagi tautan ini karena menjelaskan SOAP dengan akurat sekaligus lucu: https://harmful.cat-v.org/software/xml/soap/simple. Saya menyukai teknologi berbasis XML, terutama kemampuan komposisi tipe dan validasi XML Schema yang tetap luar biasa. Tapi SOAP terasa seperti monster yang tak perlu; padahal yang dibutuhkan dulu cuma spesifikasi panggilan remote yang sederhana, dan akhirnya jadi spesifikasi yang mendefinisikan segalanya tetapi gagal menangani apa pun dengan baik. SOAP mengklaim mendukung banyak protokol transport (sampai SOAP over email), berbagai jenis RPC, UDDI, bahkan Self-Describing RPC, namun implementasi inti seperti autentikasi, caching, dan kode respons HTTP tetap di tangan pengguna.
  • Ironisnya, hal yang membuat saya selamanya menolak SOAP adalah demo SOAP yang pernah saya tonton saat itu. Antar bahasa yang sama mungkin cukup berjalan, tapi antar bahasa jadi bencana. Saya rasa ini juga alasan Microsoft sangat menyukai SOAP.

• CORBA muncul pada 1991 dengan wawasan bahwa pada lingkungan heterogen tidak cukup hanya mengimplementasikan protokol per bahasa. Poin bahwa OMG IDL membuat binding yang sama di berbagai bahasa untuk mencegah inkonsistensi interface dan masalah serialisasi memang benar. Tapi saya bertanya-tanya apakah itu benar-benar contoh sukses.

  • Lingkungan API berbasis JSON sekarang tampaknya merupakan reaksi terhadap kegagalan CORBA dan SOAP. Bukan karena pelajaran CORBA dilupakan, tapi karena secara sadar ditolak.
  • Saya pernah bekerja di tempat yang sangat baik memanfaatkan CORBA. Menurut saya, itu sukses karena ada insinyur senior berpengalaman CORBA yang kuat di tim.
  • Tahun 1998 saya sempat melamar ke kantor AT&T yang memakai CORBA, dan itu jadi pengalaman terakhir saya (dan setelah itu yang saya lihat dari sana hanya unduhan JDK yang berjalan lambat). Saat wawancara, pewawancara bilang kode konkurensi yang saya tulis tidak dia suka, dan meski saya menunjuk potensi race condition, saya gagal meyakinkannya. Namun kemudian kesimpulannya justru bahwa jawaban saya benar karena masalahnya ada di Java Memory Model.
  • CORBA memang melakukan banyak hal dengan baik, tetapi ia lahir dari jaringan telekomunikasi tradisional akhir 1990-an dan gelombang OOP. Karena itu, ia mengasumsikan jaringan transparan, dapat dipercaya, dan simetris—yang tentu tidak sesuai realitas dengan timeout, retry, kemacetan jaringan, crash sistem, dan sebagainya. Terutama, binding CORBA C++ sebelum era STL sangat mengerikan; pada akhirnya bahasa-bahasa lain justru terlihat lebih baik.
  • Saya bisa tetap mengakui keunggulannya dalam proyek yang sukses secara teknis namun gagal secara komersial.

• Yang terlewat dalam diskusi MCP—atau “pelajaran inti yang benar-benar dipelajari MCP”—justru bahwa semua fitur canggih memunculkan kompleksitas, sehingga kebanyakan kasus di lapangan memilih yang sederhana. Inilah mengapa JSON over HTTP jadi arus utama. Bahkan perusahaan besar pun butuh bertahun-tahun untuk bermigrasi ke protokol serialisasi berfitur tinggi seperti gRPC, dan bisa gagal berkali-kali di tengah jalan. Peran MCP sebenarnya adalah menstandardisasi kontrak JSON API yang sederhana, sehingga pembuatan token untuk LLM dan gaya pemanggilan tool jadi lebih mudah.

  • Saya penasaran apa itu HTTP blobs. Sepertinya ini upaya menyatakan kenapa JSON mengalahkan XML.

• MCP memang tidak sempurna, tetapi saya pikir dia sudah belajar pelajaran utama dari puluhan tahun sejarah RPC bahwa kompleksitaslah yang paling menghambat adopsi dan penggunaan (mirip naiknya JSON atas XML). SOAP terlalu kompleks untuk interoperabilitas antar sistem, dan XML beserta skema terlalu verbose. CORBA kompleks karena library/frameworknya, sehingga di bahasa modern saat itu justru dihindari. gRPC memang cepat tapi bacaannya sulit dan butuh pemetaan. Kerangka kerja RPC sekarang berinti REST dan JSON. Standar yang disebut tadi bergeser menjauh, atau tersisa gRPC untuk kebutuhan performa ekstrem saja. REST dan JSON jadi arus utama karena kesederhanaan tersebut, dan MCP juga merupakan desain yang mengikuti arus itu.

• Banyak pendapat bagus. Saya rasa kita sedang keliru memahami MCP. Yang lebih penting adalah salah paham dan ketidaksesuaian arah di industri secara luas tentang apa itu agent dan kemana arahnya. Banyak platform web percaya agen akan tertanam ke infrastruktur terdistribusi jaringan, sehingga tujuannya membuat semua agen dalam container menyambung ke MCP lewat service mesh. Menurut saya, anggapan bahwa “agen web-native dan SDK/framework web harus di-deploy seperti aplikasi server” itu salah; itu bukan agen dan bahkan bukan bentuk awal dari agen di tahap evolusinya. Harness agen sejati pada akhirnya hanya bisa dibuat oleh sedikit penyedia seperti Frontier labs, dan makin mengarah ke arah personal (misalnya satu MCP server untuk Claude Desktop di desktop saya). Server MCP pada dasarnya untuk kasus single-instance dan harness seperti ini.

  • Masalah MCP bukanlah dirancang tidak cocok untuk enterprise, tapi menyalahgunakan LLM di konteks yang salah. Contohnya, AI melakukan transaksi dengan kesalahan presisi desimal di layanan keuangan adalah masalah bukan protokol, melainkan menyerahkan trading ke LLM tanpa batasan apa pun. Demikian juga ketika LLM salah memahami format tanggal lalu mengeluarkan output halusinatif, itu karena kita menempatkan LLM di lingkungan kritikal.

• Akan sangat bagus kalau ada yang menjelaskan secara jelas kenapa MCP dibutuhkan dibanding Swagger atau proto.

  • OpenAPI (Swagger) dan Proto (protobuf) masing-masing tidak mencakup seluruh peran MCP. Secara teori MCP bisa diletakkan di atas keduanya, tapi untuk kasus penggunaan lokal MCP, asumsi komunikasi Swagger tidak cocok, dan protobuf memang tidak mencakup protokol komunikasi sehingga butuh desain tambahan. Bahkan kalau menggantikan JSON-RPC pun, pada akhirnya spesifikasi MCP hampir seluruhnya tetap dipertahankan, malah jadi lebih rumit.
  • MCP adalah teknologi baru.
  • MCP mendukung respon streaming. Polling atau state sesi juga bisa dipakai untuk mengatasinya, tapi itu hanyalah trik yang tidak efisien.

• Jika dikatakan bahwa OpenAI menagih biaya $50,000 dari penggunaan API bulan lalu, tak mudah membedakan tool MCP bagian dari divisi mana yang memicu biaya tersebut, panggilan alat per-event, pengguna, atau kasus pakai apa yang terjadi. Di hampir semua teknologi AI, masalah biasanya baru disusul belakangan. Tapi sama seperti framework web atau blockchain, ketika teknologinya terlalu besar, di awal kita tak bisa memahami semuanya dengan sempurna. Kesenjangan itu memang akan menyusut perlahan. Saya setuju bahwa di AI kita harus terus berbagi ide dan rasa waspada. Zaman ini memang benar-benar menarik.

• Saat harus memilih antara desain yang lebih baik dan desain yang cukup memadai, saya selalu berpikir pilihan “cukup memadai” yang menang. Contoh bisa terus disebut: Multics vs Unix, SOAP berbasis XML vs REST berbasis JSON, kegagalan XHTML, bahkan JavaScript itu sendiri. Jadi manusia akhirnya terus-menerus mengimplementasikan ulang yang “cukup memadai” dan ketika masalah terlihat, bertahan dengan tambalan darurat.

  • Ini hanyalah pengulangan fenomena Worse is Better yang sangat dikenal: https://en.m.wikipedia.org/wiki/Worse_is_better. Ini telah dibuktikan berulang kali dari waktu ke waktu. Saya memang cenderung selalu tertarik ke solusi “yang lebih baik”, tetapi kenyataan tidak selalu begitu.
  • Dunia membutuhkan jeda satu menit untuk xforms 2.0. Dunia yang mungkin bisa kita jalani: validasi form web yang benar-benar bekerja, microdata...