Protocol Conformance Testing: Kenapa Dokumentasi Saja Tidak Cukup

“Di dokumentasi sudah jelas kok.”

Kalimat ini sering terdengar tepat sebelum dua sistem yang sama-sama merasa mengikuti standar ternyata tidak bisa ngobrol.

Tim A membaca spesifikasi dengan satu interpretasi. Tim B membaca kalimat yang sama dengan interpretasi sedikit berbeda. SDK C punya bug edge case. Server D menerima field yang seharusnya ditolak. Client E mengirim version header dengan format yang keliru tetapi tetap bekerja di environment internal.

Semua merasa compliant.

Begitu dipertemukan, baru kelihatan retaknya.

Itulah kenapa protocol conformance testing penting.

Dokumentasi menjelaskan apa yang seharusnya terjadi.

Conformance testing memeriksa apakah implementasi benar-benar melakukan itu.

Di dunia agentic 2026, perbedaannya tidak akademis. MCP dan A2A dipakai untuk menghubungkan model, tools, agents, data, dan workflow yang dapat menjalankan action. Kesalahan interoperability bukan lagi cuma “fitur gagal loading”. Ia bisa berarti task hilang, status salah dibaca, permission tidak dihormati, atau sistem jatuh ke fallback yang tidak direncanakan.

Spesifikasi bukan executable proof

Sebuah protocol specification biasanya memakai bahasa normatif seperti MUST, MUST NOT, SHOULD, atau MAY.

Bahasa itu penting karena mendefinisikan obligation.

Tetapi dokumen tetap perlu diterjemahkan ke code.

Begitu diterjemahkan, ada peluang deviation.

Misalnya server wajib mengembalikan struktur tertentu. Engineer salah memberi nama field.

Client harus mengirim versi tertentu. Library lama masih memakai format sebelumnya.

Transport mendukung streaming. Implementasi berhenti sebelum event akhir.

Schema valid, tetapi semantics-nya salah.

Authorization terlihat jalan, tetapi edge case tertentu membiarkan request lolos.

Sebuah README yang menulis “supports MCP” atau “A2A compatible” tidak cukup membuktikan semua behavior tersebut.

Conformance testing memberi test case dengan expected behavior, lalu membandingkan implementasi terhadap requirement protocol.

Bahasa sederhananya: jangan cuma percaya pengakuan. Jalankan uji.

MCP sudah bergerak ke testing yang lebih serius

Ekosistem MCP pada 2026 secara eksplisit menempatkan conformance sebagai bagian dari maturity.

Roadmap resmi MCP mencantumkan conformance test suites untuk memverifikasi clients, servers, dan SDKs terhadap specification. SDK tiering juga menggunakan conformance testing sebagai sinyal seberapa baik implementasi mengikuti protokol.

Bahkan aturan Specification Enhancement Proposal atau SEP menambahkan disiplin yang menarik: perubahan standards-track yang mengubah observable protocol behavior perlu memiliki conformance scenario sebelum bisa mencapai status Final.

Ini healthy signal.

Standar yang berkembang cepat rawan memiliki jarak antara prose dan implementation.

Kalau setiap perubahan hanya menghasilkan paragraf baru di spec, ecosystem dapat drift.

Kalau perubahan juga menghasilkan test scenario, ada artefak executable yang bisa dijalankan berulang kali.

MCP Inspector memperkuat workflow itu. Versi 2026 menyediakan web, CLI, dan terminal interface untuk testing serta debugging MCP servers. CLI membuat pengujian lebih mudah dibawa ke CI pipeline, bukan hanya dilakukan manual saat developer sedang debug.

Tetapi Inspector dan conformance suite bukan hal identik.

Inspector membantu melihat dan mencoba behavior.

Conformance suite menguji apakah behavior memenuhi requirement yang sudah didefinisikan.

Keduanya saling melengkapi.

A2A juga punya TCK

Di sisi A2A, project resmi menyediakan Technology Compatibility Kit atau TCK.

Tujuannya adalah memvalidasi implementasi A2A across transports, termasuk gRPC, JSON-RPC, dan HTTP+JSON.

Kenapa transport diversity ini penting?

Karena dua implementasi bisa sama-sama mengklaim A2A tetapi bertemu lewat transport yang berbeda atau punya variasi detail framing.

A2A v1.0 sendiri menekankan interoperability lintas technology stack, multi-protocol bindings, dan version negotiation. Klaim itu baru punya nilai praktis kalau implementasi benar-benar bisa dipertemukan.

TCK mengubah “seharusnya interoperable” menjadi sesuatu yang bisa diuji.

Bayangkan procurement software membeli agent platform.

Vendor berkata, “Kami support A2A v1.0.”

CTO bertanya, “Sudah dites dengan implementation lain?”

Jawabannya jangan berhenti di demo milik vendor sendiri.

Demo yang client dan server-nya dibangun oleh tim yang sama sering memberi rasa aman palsu. Dua sisi dapat memiliki bug yang saling cocok. Mereka salah dengan cara yang sama, sehingga test terlihat sukses.

Cross-implementation testing jauh lebih berharga.

Conformance tidak sama dengan security

Ini perlu dibedakan secara tegas.

Sistem yang conform terhadap protokol belum tentu aman.

Ia bisa mengimplementasikan semua message dengan benar tetapi memiliki authorization policy buruk.

Ia bisa lolos schema test tetapi menyimpan credential secara tidak aman.

Ia bisa mengembalikan Agent Card valid tetapi informasi yang diumumkan misleading.

Ia bisa memenuhi protocol handshake tetapi rentan prompt injection pada layer aplikasi.

Conformance menjawab pertanyaan: apakah implementation sesuai requirement protocol?

Security testing menjawab pertanyaan lain: apakah implementation tahan terhadap threat dan abuse?

Functional testing bertanya: apakah fitur bekerja untuk use case kita?

Performance testing bertanya: apakah sistem bertahan pada load?

Resilience testing bertanya: apa yang terjadi ketika dependency gagal?

Jangan menempelkan satu badge “tested” lalu menganggap semuanya beres.

Dina dari security team mungkin bilang, “Oke, TCK lulus. Sekarang gue mau tahu kalau Agent Card dipalsukan, sistem kita ngapain.”

Itu bukan cerewet. Itu boundary yang sehat.

Conformance adalah baseline interoperability, bukan sertifikat bahwa seluruh sistem trustworthy.

Kenapa dokumentasi sering gagal menangkap edge case

Dokumentasi ditulis untuk manusia.

Manusia mengisi gap.

Kita membaca kalimat ambigu lalu menginterpretasikan berdasarkan pengalaman.

Mesin tidak punya kemewahan yang sama.

Perbedaan kecil seperti null versus absent field, urutan status, casing header, version mismatch, retry behavior, atau error code dapat membuat sistem bertindak berbeda.

Di sistem internal, engineer bisa cepat koordinasi.

“Eh, endpoint lo ternyata kirim null ya?”

“Oh iya, gue ubah.”

Selesai.

Di ecosystem protocol, pihak yang berinteraksi mungkin beda perusahaan, beda negara, beda framework, dan tidak pernah berbicara langsung.

Standar hanya berguna kalau implementation behavior cukup predictable.

Conformance tests mengurangi ketergantungan pada interpretasi informal.

Itu alasan dokumentasi saja tidak cukup.

Test harus ikut versioning

Protocol hidup berubah.

MCP 2026-07-28 membawa perubahan besar dibanding revision sebelumnya. A2A v1.0 juga membawa perubahan interaction protocol dan enterprise-oriented behavior.

Kalau test suite tidak mengikuti versi, ia bisa memberi false confidence.

Server baru dites dengan scenario lama lalu diberi label “pass”.

Client mengklaim v1.0 tetapi hanya diuji untuk behavior v0.x.

Library menerima payload legacy karena backward compatibility, sehingga bug v1.0 tidak terlihat.

Karena itu test artifact harus punya version context yang jelas.

Apa spec version yang diuji?

Capability apa yang diuji?

Transport apa?

Extension apa?

Apakah test mandatory core atau optional feature?

Tanggal suite-nya kapan?

Commit atau release mana?

Hasil pass tanpa konteks itu lemah.

Untuk organisasi besar, informasi tersebut sebaiknya masuk ke evidence record. Bukan untuk pamer, tetapi supaya enam bulan kemudian orang tahu apa yang sebenarnya diuji.

Conformance di CI, bukan menjelang launch saja

Kesalahan umum adalah conformance test dijalankan sekali.

Tim ingin launch. Mereka tes. Pass. Screenshot hasil. Masuk dokumen compliance.

Lalu tiga bulan berikutnya code berubah 40 kali.

SDK di-upgrade.

Auth middleware diganti.

Gateway diperbarui.

Protocol version naik.

Extension baru aktif.

Badge pass lama masih terpajang.

Praktik yang lebih matang adalah memasukkan conformance scenarios relevan ke continuous integration.

Setiap perubahan yang menyentuh protocol layer memicu pengujian lagi.

Untuk MCP, tooling CLI membuat pola seperti ini makin realistis. Untuk A2A, TCK dapat menjadi bagian dari validation workflow.

Tidak semua test harus dijalankan di setiap commit jika berat. Tim dapat memisahkan smoke test, core conformance, full compatibility, dan release certification.

Yang penting, conformance bukan ritual tahunan.

Ia bagian dari software lifecycle.

Negative tests sama pentingnya

Tim biasanya senang menguji happy path.

Request valid masuk.

Response valid keluar.

Pass.

Padahal protocol robustness sering terlihat ketika input salah.

Apa yang terjadi jika version tidak didukung?

Apa yang terjadi jika mandatory field hilang?

Bagaimana response terhadap capability yang tidak tersedia?

Apa yang terjadi jika request dibatalkan?

Bagaimana server menangani malformed message?

Apakah unauthorized call benar-benar ditolak?

Apakah client salah menafsirkan error sebagai success?

Negative testing adalah tempat banyak bug interoperability muncul.

Agentic systems perlu ini karena model dan orchestration layer dapat menghasilkan kombinasi request yang tidak selalu diprediksi manusia.

Kalau protocol implementation hanya stabil ketika semua pihak berperilaku sempurna, berarti ia belum siap untuk dunia nyata.

Testing juga bagian dari procurement

Conformance testing tidak hanya urusan developer.

Procurement dan risk team bisa memakai konsep ini untuk memperbaiki pertanyaan ke vendor.

Daripada hanya bertanya, “Support MCP?”

Tanyakan:

Versi MCP mana?

Core feature apa yang conform?

Extension apa yang didukung?

Ada hasil conformance suite?

SDK apa?

Bagaimana regression testing dilakukan setelah upgrade?

Untuk A2A:

Versi mana?

Transport apa yang diuji?

Sudah diuji dengan TCK?

Sudah diuji cross-implementation?

Version negotiation bagaimana?

Agent Card validation bagaimana?

Pertanyaan seperti ini mengubah conversation dari marketing claim ke engineering evidence.

Tidak semua vendor harus membuka seluruh internal report. Tetapi capability penting seharusnya bisa dijelaskan lebih konkret daripada logo protocol di slide.

Interoperability adalah pengalaman, bukan logo

Ada pelajaran lama dari dunia standard.

Dua produk bisa sama-sama menampilkan logo teknologi yang sama tetapi tetap gagal bekerja bersama.

Agent ecosystem berisiko mengulang hal tersebut jika adoption tumbuh lebih cepat daripada testing culture.

MCP Registry, Agent Cards, tool descriptions, protocol bindings, dan SDK memberi kita vocabulary.

Conformance testing memastikan vocabulary itu dipakai dengan grammar yang sama.

Tanpa testing, fragmentasi bisa muncul diam-diam.

Setiap vendor punya “MCP-compatible” versinya sendiri.

Setiap agent platform punya interpretasi A2A sendiri.

Client menambahkan workaround khusus vendor.

Server menambahkan behavior non-standard karena client populer meminta.

Beberapa tahun kemudian, protocol yang seharusnya mengurangi custom integration malah dipenuhi compatibility patch.

Conformance adalah salah satu rem untuk mencegah itu.

Bukan dokumentasi versus testing

Kita tidak perlu memilih.

Dokumentasi tetap fundamental.

Spec menjelaskan requirement, rationale, terminology, security considerations, dan design contract.

Testing tidak menggantikan penjelasan.

Ia menambahkan verification.

Analogi paling gampang: resep dan hasil masakan.

Resep menjelaskan apa yang harus dilakukan. Taste test memberi evidence apakah hasilnya sesuai.

Di protocol engineering, kita butuh keduanya.

Spec yang bagus tanpa test dapat menghasilkan interpretasi yang pecah.

Test yang bagus tanpa spec membuat orang tidak mengerti apa yang sedang dibuktikan.

Maturity muncul ketika requirement, implementation, test, dan evidence saling terhubung.

Pada akhirnya, nilai sebuah protocol bukan karena dokumennya rapi atau GitHub repo-nya ramai.

Nilainya muncul ketika dua pihak yang tidak pernah koordinasi sebelumnya bisa bertemu dan sistem mereka tetap memahami satu sama lain.

Kalau targetnya interoperability, “kami sudah baca dokumentasi” bukan garis finish.

Itu baru mulai.