Interoperabilitas Alat Pengkodean dengan MCP dan A2A

Beranda » Ular sanca » Interoperabilitas Alat Pengkodean dengan MCP dan A2A

Agen AI bukan lagi sekadar chatbot canggih yang menjawab pertanyaan dalam satu jendela. Mereka berubah menjadi sistem terdistribusi yang dapat membaca dan menulis kode, memanggil API, berkoordinasi dengan layanan lain, dan bahkan bernegosiasi dengan agen lain untuk menyelesaikan pekerjaan. Begitu Anda beralih dari "satu asisten pintar" ke "jaringan agen", masalah yang berat muncul: bagaimana semua bagian ini saling berkomunikasi tanpa menimbulkan kekacauan?

Itulah tepatnya celah yang coba diisi oleh MCP (Model Context Protocol) dan A2A (Agent-to-Agent Protocol). MCP berfokus pada bagaimana agen terhubung ke alat, data, dan konteks, sementara A2A berfokus pada bagaimana agen berkomunikasi dan berkolaborasi satu sama lain. Keduanya memiliki kesamaan prinsip tetapi beroperasi pada lapisan yang berbeda. Dalam artikel ini, kita akan membahas secara mendalam apa yang dilakukan masing-masing, bagaimana keduanya saling melengkapi, bagaimana keduanya sudah digunakan dalam sistem nyata, dan apa artinya ini bagi masa depan alat pengkodean dan arsitektur multi-agen.

Apa sebenarnya MCP dalam praktiknya?

Pada intinya, MCP adalah cara standar untuk mengekspos alat, sumber daya, dan perintah kepada agen AI sehingga agen tersebut dapat memanggilnya dengan aman dan konsisten. Alih-alih menghubungkan setiap alat secara langsung ke setiap agen dengan kode penghubung khusus, Anda mengekspos alat-alat tersebut di balik server MCP, dan membiarkan klien MCP (para agen) menemukan dan memanggilnya melalui protokol terpadu.

MCP mengikuti arsitektur klien-server yang jelas: Aplikasi host (seperti editor, CLI, atau runtime agen) menyematkan klien MCP, dan klien tersebut membuka koneksi satu-ke-satu ke satu atau lebih server MCP. Setiap server hanyalah proses ringan yang mengekspos sejumlah kemampuan – biasanya berupa alat, sumber daya hanya baca, dan perintah yang dapat digunakan kembali.

Inspirasinya sangat mirip dengan Language Server Protocol (LSP). LSP mengabstraksikan masalah “editor ↔ fitur bahasa” sehingga kita tidak perlu menulis integrasi khusus antara setiap editor dan setiap bahasa pemrograman. Jika Anda mengimplementasikan server bahasa sekali, editor yang kompatibel dengan LSP mana pun dapat berkomunikasi dengannya. MCP mengambil ide yang sama dan menerapkannya pada alat dan konteks untuk LLM: implementasikan alat sekali sebagai server MCP, dan setiap agen yang memahami MCP dapat menggunakannya.

Dari sudut pandang transportasi, MCP fleksibel namun cukup tegas untuk dapat diterapkan secara praktis. Protokol ini menggunakan JSON-RPC 2.0 sebagai format pesan dan mendukung beberapa transport: stdio untuk proses lokal (sangat cocok untuk aplikasi desktop dan pengembangan lokal) dan HTTP atau SSE untuk server jarak jauh (sempurna untuk Cloud Run atau penerapan berbasis kontainer). Protokol ini juga mendefinisikan bagaimana klien menemukan kemampuan dan bagaimana alat-alat dijelaskan menggunakan JSON Schema sehingga LLM dapat memutuskan kapan dan bagaimana memanggilnya.

Yang terpenting, MCP tidak mencoba mengatur penalaran agen Anda. Itu tidak memutuskan ketika Suatu alat harus diaktifkan, atau bagaimana alat-alat tersebut harus dirantai. MCP adalah lapisan penghubung: ia menyediakan alat, sumber daya, dan perintah secara terstruktur dan mudah ditemukan, menyerahkan pengambilan keputusan kepada kerangka kerja agen, perencana, atau rekayasa perintah Anda.

Elemen dasar MCP: alat, sumber daya, dan panduan.

Server MCP berputar di sekitar tiga elemen dasar utama: alat, sumber daya, dan perintah. Ketiga konsep ini sudah cukup untuk memenuhi sebagian besar kebutuhan agen di dunia nyata tanpa mengubah protokol menjadi kerangka kerja orkestrasi yang lengkap.

Alat adalah tindakan-tindakan spesifik yang dapat dipicu oleh seorang agen. Memikirkan "get_weather","search_inventory","book_flight","run_sql_query" atau "get_exchange_rateSetiap alat dideklarasikan dengan nama, deskripsi yang mudah dibaca manusia, dan skema input. Skema itulah yang memungkinkan LLM memahami parameter apa yang harus dilewatkan, dan juga melindungi backend Anda dengan memvalidasi argumen sebelum dieksekusi.

Sumber daya mewakili data hanya baca yang dapat disajikan oleh server sesuai permintaan. Berkas, log, baris basis data, cuplikan dokumentasi, berkas konfigurasi – setiap informasi yang lebih baik dimodelkan sebagai "ambil hal ini" daripada "jalankan fungsi ini". Sumber daya bisa berukuran besar, jadi MCP mendefinisikan cara untuk melakukan paging dan streaming, yang sangat penting saat memasukkan konteks ke dalam model dengan jendela yang terbatas.

Prompt adalah templat yang dapat digunakan kembali yang dapat ditampilkan server kepada klien. Alih-alih memasukkan string perintah yang panjang dan rentan secara manual di dalam agen Anda, Anda dapat memusatkannya sebagai perintah MCP. Server mengeksposnya dengan nama, deskripsi, dan slot parameter, dan klien mengisi slot tersebut saat runtime. Ini sangat ampuh ketika beberapa agen perlu berbagi pola yang sama tentang cara berkomunikasi dengan alat tertentu atau mengikuti aturan keselamatan dan kepatuhan di seluruh perusahaan.

Ketika klien terhubung ke server, klien tersebut melakukan langkah penemuan kemampuan. Server merespons dengan katalog alat, sumber daya, dan perintah, masing-masing dengan metadata terperinci. Katalog tersebut kemudian dimasukkan ke dalam LLM (biasanya dalam bentuk ringkasan) sehingga model dapat bernalar: “Saya dapat menggunakan get_exchange_rate untuk menjawab pertanyaan tentang konversi mata uang ini, dan saya tidak seharusnya mencoba mengarang jawabannya.”

Karena semuanya bersifat deklaratif, kemampuan baru dapat ditambahkan atau dihapus tanpa menyentuh logika inti agen. Tambahkan alat baru ke server, sebarkan ulang, dan setiap klien MCP yang terhubung akan melihatnya pada negosiasi kemampuan berikutnya. Ini adalah momen "colokkan satu perangkat USB lagi" untuk perangkat AI.

Contoh konkret MCP: alat konversi mata uang

Demo agen mata uang dari Google Agent Development Kit (ADK) adalah ilustrasi sempurna dari MCP yang sedang beraksi. Proses ini dimulai dengan membangun server MCP kecil yang mengekspos satu alat tunggal, get_exchange_rate, didukung oleh API Frankfurter publik. Di disk, itu hanya skrip Python kecil yang menggunakan fastmcp.

Server mendefinisikan alat tersebut dengan argumen bertipe untuk currency_from, currency_to ke currency_date, ditambah dengan pencatatan log dan penanganan kesalahan yang andal. Ketika agen memanggilnya, server akan mengakses Frankfurter melalui HTTP, memvalidasi respons, dan mengembalikan muatan JSON yang berisi nilai tukar atau objek kesalahan. Tidak ada yang spesifik untuk AI dalam hal ini; MCP hanya menstandarisasi bagaimana fungsi ini dijelaskan dan dipanggil.

Secara lokal, Anda menjalankan server dengan perintah sederhana dan server tersebut akan mendengarkan pada http://localhost:8080. Klien pengujian terpisah, yang juga menggunakan MCP, terhubung, dan melakukan penemuan. get_exchange_rate dan memicu panggilan untuk USD → EUR. Log menunjukkan pemanggilan alat, permintaan HTTP keluar, respons yang berhasil, dan JSON yang dikembalikan. Dari sudut pandang agen Anda, itu hanya menanyakan "alat apa yang saya miliki?" dan kemudian "silakan panggil yang ini".

Menerapkan server yang sama ke Cloud Run hampir tidak mengubah apa pun. Anda mengemas server MCP ke dalam kontainer, lalu melakukan deployment dengan --no-allow-unauthenticated Jadi, ini memerlukan otentikasi yang didukung IAM, dan kemudian membuka terowongan aman dari mesin lokal Anda menggunakan perintah proxy Cloud Run. Secara lokal, klien MCP Anda masih mengira sedang berkomunikasi dengan http://127.0.0.1:8080; proxy menangani otentikasi dan lompatan jaringan secara transparan.

Pola ini sangat ampuh dalam tim: Anda dapat menjalankan server MCP terpusat untuk alat bersama seperti kurs mata uang, API internal, atau basis data milik perusahaan. Setiap agen pengembang di organisasi dapat terhubung ke server tersebut melalui transportasi yang aman, alih-alih mengirimkan pembungkusnya sendiri yang sedikit berbeda dan setengah terpelihara di sekitar API yang sama.

Membangun agen di atas MCP: dari alat tunggal hingga alur kerja lengkap

MCP menjadi sangat menarik ketika Anda menyematkannya ke dalam kerangka kerja agen seperti ADK milik Google. Dalam contoh agen mata uang, ADK digunakan untuk membuat agen LLM khusus yang tugasnya hanya menjawab pertanyaan tentang nilai tukar menggunakan alat MCP. Instruksi sistem agen tersebut secara harfiah mengatakan: “tujuan Anda satu-satunya adalah menggunakan get_exchange_rate alat".

ADK menghubungkan instruksi ini, model yang dipilih (misalnya gemini-2.5-flash) dan MCPToolset contoh yang mengarah ke URL server MCP. Sejak saat itu, ketika pengguna bertanya "Berapa 250 CAD dalam USD?", agen akan mempertimbangkan apakah perlu memanggil alat bantu, mengisi parameter alat bantu, mengirimkan permintaan melalui MCP, dan kemudian menulis respons yang mudah dipahami pengguna menggunakan JSON yang dikembalikan.

Pola yang sama berlaku untuk agen yang jauh lebih kompleks. Alih-alih API mata uang tunggal, Anda dapat menghubungkan beberapa server: satu untuk basis data internal, satu lagi untuk SaaS pihak ketiga, satu lagi untuk pencarian dokumen, ditambah server yang mengekspos prompt yang dapat digunakan kembali atau pipeline RAG. MCP tidak mempermasalahkan apakah server-server tersebut berjalan secara lokal, di Cloud Run, di Kubernetes, atau di balik VPN, selama transport didukung dan otentikasi dikonfigurasi dengan benar.

ADK juga menambahkan perspektif yang mengutamakan agen, yang sengaja dihindari oleh MCP. Pendekatan ini memperlakukan agen sebagai komponen perangkat lunak yang dapat disusun: Anda dapat mendefinisikan agen berbasis LLM, agen yang kaya akan alat, agen evaluasi, dan orkestrator, yang semuanya mampu berkomunikasi dengan MCP secara langsung. Hasilnya adalah "membangun agen" mulai terlihat jauh lebih seperti "membangun layanan mikro" dan jauh lebih sedikit seperti "mengutak-atik perintah tanpa akhir di buku catatan".

Apa itu A2A – dan mengapa MCP saja tidak cukup

Jika MCP adalah tentang menghubungkan agen dengan alat, maka A2A adalah tentang menghubungkan agen dengan agen lainnya. Begitu Anda memiliki banyak agen yang masing-masing ahli dalam melakukan sesuatu, Anda membutuhkan cara agar mereka dapat saling menemukan, bertukar tugas, dan tetap sinkron saat pekerjaan sedang berlangsung. Itulah ruang lingkup masalah yang dirancang untuk diatasi oleh A2A.

A2A, yang diprakarsai oleh Google Cloud dan sekarang berada di bawah naungan Linux Foundation, adalah standar terbuka untuk interoperabilitas antar agen. Sistem ini menggunakan teknologi yang sudah dikenal (HTTP(S), JSON-RPC 2.0, dan SSE untuk streaming) tetapi membungkusnya dalam model domain yang memahami agen, keterampilan, tugas, artefak, dan kemampuan. Alih-alih "panggilan alat", Anda mendapatkan bahasa kolaborasi tingkat tinggi.

Dua ide inti dalam A2A adalah Kartu Agen dan Tugas. Kartu Agen adalah dokumen JSON – biasanya dapat ditemukan di /.well-known/agent.json – yang menjelaskan apa yang dapat dilakukan agen, bagaimana cara menghubunginya, otentikasi apa yang diharapkannya, dan mode input/output apa yang didukungnya. Tugas adalah unit kerja yang dapat dikirim satu agen ke agen lain, dengan siklus hidup yang terdefinisi dengan baik dan hasil yang terstruktur.

Dalam interaksi A2A, satu agen berperan sebagai "agen klien" dan agen lainnya bertindak sebagai "agen jarak jauh". Klien menemukan kartu agen jarak jauh, memutuskan apakah ini mitra yang tepat untuk pekerjaan tersebut, dan kemudian membuat permintaan tugas. Agen jarak jauh menerima tugas tersebut, menggunakan LLM dan alat internalnya sendiri (seringkali melalui MCP) untuk mengeksekusinya, dan kemudian mengirimkan kembali pembaruan kemajuan dan artefak akhir.

Desain ini membuat A2A secara bawaan bersifat point-to-point, asinkron, dan ramah jaringan. Secara internal, implementasi Python dibangun di atas kerangka kerja ASGI seperti Starlette (melalui A2AStarletteApplication) dan uvicorn, dengan artefak dan pembaruan tugas yang mengalir melalui JSON-RPC dan SSE. Itu berarti tugas dapat berjalan selama beberapa detik atau jam tanpa memblokir satu pun permintaan HTTP, yang sangat penting untuk alur kerja multi-agen di dunia nyata.

Contoh A2A: mengekspos agen "Hello" dan seterusnya

Contoh standar A2A “HelloWorldAgent” menunjukkan mekanismenya dalam bentuk yang disederhanakan. Anda mendefinisikan sebuah AgentExecutor subkelas yang mengimplementasikan sebuah execute Metode ini dilakukan dengan memasukkan satu pesan teks – “Halo dari A2A!” – ke dalam antrian peristiwa sebagai hasil dari tugas tersebut. Pembatalan menjadi tidak berpengaruh untuk kasus sederhana ini, tetapi mekanisme ini tersedia untuk beban kerja yang sebenarnya.

Selanjutnya Anda membuat sebuah AgentSkill menjelaskan apa yang dapat dilakukan agen ini. Dalam contoh tersebut, keterampilan hello membawa nama, deskripsi, serangkaian tag, dan contoh kueri pengguna. Keterampilan tersebut kemudian dikelompokkan ke dalam sebuah AgentCard beserta nama agen, versi, URL, kemampuan, dan mode input/output yang didukung.

Terakhir, Anda menyambungkan semuanya ke dalam sebuah A2AStarletteApplication dengan DefaultRequestHandler dan jalankan di bawah uvicorn. Sejauh yang diketahui dunia luar, Anda sekarang memiliki agen A2A yang sepenuhnya terlatih yang sedang mendengarkan. http://localhost:9000Klien mana pun yang mendukung A2A dapat mengambil data. /.well-known/agent.jsonPahami apa yang ditawarkan agen ini, dan kirimkan tugas kepadanya.

Dalam implementasi yang lebih realistis, pola yang sama dapat diterapkan pada skenario orkestrasi seperti pemesanan perjalanan, orientasi karyawan baru, atau otomatisasi dukungan pelanggan. Seorang “Agen Perjalanan” mungkin menemukan dan berkomunikasi dengan “Agen Penerbangan”, “Agen Hotel”, dan “Agen Sewa Mobil”, yang masing-masing beroperasi di balik titik akhir A2A-nya sendiri dan menyembunyikan perangkat internal serta kontrak API khusus vendornya. Agen Perjalanan hanya melihat tugas, keterampilan, dan artefak.

Di sinilah prinsip pemisahan tanggung jawab A2A terlihat jelas. Setiap agen hilir dapat memilih model, kerangka kerja, dan alatnya sendiri – agen hotel yang dibangun dengan ADK dan MCP, agen maskapai penerbangan yang dibangun dengan tumpukan teknologi lain, agen penyewaan mobil yang berada di infrastruktur mitra – dan semuanya tetap berkolaborasi dengan lancar melalui antarmuka A2A.

Menggabungkan MCP dan A2A dalam satu arsitektur.

Secara teori, pemisahan ini terdengar rapi – MCP untuk alat, A2A untuk agen – tetapi dalam praktiknya, batasannya cepat kabur. Sistem nyata seringkali ingin menyembunyikan A2A di balik MCP, melapisi MCP di dalam A2A, atau mencampur keduanya dalam proses yang sama. Contoh A2A resmi bahkan membungkus komunikasi A2A sebagai alat MCP yang diekspos dari satu server, sehingga LLM melihat "satu set alat MCP" alih-alih dua tumpukan protokol paralel.

Salah satu pola umum adalah memperlakukan MCP sebagai jaringan internal setiap agen dan A2A sebagai jaringan eksternal antar agen. Di dalam agen, LLM Anda memanggil alat MCP untuk mengakses basis data, API, atau penyimpanan dokumen. Di luar, orchestrator Anda berkomunikasi dengan agen tersebut melalui A2A, menyerahkan tugas dan membaca kembali artefak. Dari perspektif orchestrator, agen adalah layanan kotak hitam dengan antarmuka yang bersih dan bertipe.

Pola sebaliknya – menampilkan A2A sebagai alat MCP – menarik dari sudut pandang integrasi. Banyak penyedia LLM sudah memiliki perangkat bantu yang mumpuni seputar MCP: alat pengembangan, demo UI, SDK, dan panduan keamanan. Dengan mengekspos "hubungi agen jarak jauh X" sebagai satu alat MCP, Anda memungkinkan LLM untuk memicu interaksi A2A dengan pengaturan minimal. Anda hanya perlu mendaftarkan satu server MCP, tetapi di balik layar, server tersebut dapat menjadi perantara tugas di seluruh jaringan A2A.

Inilah yang ditunjukkan oleh beberapa contoh repositori: alih-alih menghubungkan setiap agen A2A jarak jauh langsung ke dalam model, server MCP menawarkan serangkaian alat ringkas yang berkomunikasi melalui A2A. Hal itu mematahkan model mental yang naif (“MCP dan A2A harus benar-benar terpisah”) tetapi sangat menyederhanakan integrasi praktis dan menjaga antarmuka LLM Anda tetap kecil dan terkelola dengan baik.

Tidak ada juga yang menghalangi Anda untuk menggunakan MCP dan A2A secara terpisah jika memang masuk akal. Banyak proyek hanya membutuhkan MCP untuk menghubungkan satu agen ke beberapa alat. Yang lain, terutama saat menggabungkan vendor atau tim internal, akan sangat bergantung pada A2A untuk koordinasi lintas organisasi sambil menggunakan koneksi internal mereka sendiri alih-alih MCP. Poin pentingnya adalah protokol-protokol tersebut tidak bersaing – melainkan saling melengkapi.

Interoperabilitas, kerangka kerja, dan "struktur besar" yang hilang

Protokol saja tidak menjamin interoperabilitas jika setiap orang menyematkannya ke dalam arsitektur tingkat tinggi yang sangat berbeda. Anda bisa berbicara dengan sempurna tentang MCP dan A2A, namun tetap saja akan berakhir dengan beragam pola agen yang saling tidak kompatibel, yang masing-masing menciptakan kembali perencanaan, memori, penanganan kesalahan, dan tata kelola.

Langkah selanjutnya yang mungkin terjadi dalam ekosistem ini adalah lapisan kerangka kerja yang dibangun di atas MCP dan A2A yang menstandarisasi tidak hanya kabel, tetapi juga struktur yang lebih besar. Bayangkan bagaimana kerangka kerja web muncul di atas HTTP atau bagaimana ORM dibangun di atas SQL. Kita mulai melihat hal ini dengan ADK, orchestrator seperti LangGraph, platform terkelola seperti Vertex AI Agent Engine, dan gateway AI yang memahami kedua protokol tersebut.

Begitu industri ini menyepakati beberapa pola pragmatis – “beginilah cara Anda menyusun alur kerja multi-agen melalui A2A dan MCP”, “beginilah cara Anda mengekspos alat bantu tim di balik MCP” – kekhawatiran tentang apakah sesuatu “seharusnya berada di balik MCP atau A2A” akan mulai memudar. Sebagian besar pengembang hanya akan memilih kerangka kerja, memasang satu atau dua server, dan mendapatkan pengaturan default yang wajar.

Masalah yang lebih rumit dan memakan waktu lebih lama adalah rekayasa yang cepat dan interoperabilitas yang cepat. Bahkan dengan protokol yang sempurna, ketika Anda menghubungkan sistem melalui MCP dan A2A, Anda secara efektif mengizinkan perintah sembarangan – instruksi sistem, deskripsi alat, pengaman – untuk bocor dan berinteraksi melintasi batas. Jika perintah tersebut tidak selaras, berlebihan, atau bahkan saling bertentangan, kinerja Anda akan menurun jauh sebelum masalah keamanan muncul.

Dalam praktiknya, perintah dan instruksi yang dirancang buruk di seluruh tumpukan MCP + A2A dapat menghasilkan latensi besar, halusinasi, dan ketidakstabilan. Setiap agen mungkin "diberi petunjuk dengan baik" secara lokal, tetapi ketika Anda menggabungkannya, alur kerja dapat menjadi rapuh: alat-alat salah diprioritaskan, jendela konteks terbuang sia-sia, dan harapan pengguna tidak terpenuhi. A2A dapat mengkoordinasikan tugas, MCP dapat mengekspos alat-alat, tetapi keduanya tidak memaksa Anda untuk menjaga agar petunjuk tetap koheren.

Inilah mengapa tim yang benar-benar telah meluncurkan produk LLM dalam skala besar cenderung memperlakukan rekayasa yang cepat sebagai perhatian rekayasa kelas satu, bukan penyesuaian di menit-menit terakhir. Para pemangku kepentingan bisnis sering melihat prompt sebagai cara ajaib untuk memperbaiki segalanya; para insinyur terkadang menganggap prompt sebagai detail sekunder dibandingkan dengan kode. Realitasnya berada di tengah-tengah: prompt tidak akan membuat sistem yang buruk menjadi baik, tetapi prompt yang ceroboh benar-benar dapat merusak arsitektur yang seharusnya solid.

Keamanan, identitas, dan tata kelola di seluruh MCP dan A2A

Begitu Anda mulai mengizinkan agen untuk bertindak atas nama manusia melintasi batasan MCP dan A2A, identitas dan otorisasi dengan cepat menjadi masalah utama. Satu permintaan tunggal mungkin melewati beberapa lapisan delegasi: pengguna berkomunikasi dengan agen pengatur, yang memanggil alat melalui MCP, yang secara internal memanggil server MCP lain atau agen A2A yang memerlukan kredensial terpisah.

Skenario konkret muncul di mana-mana: Aplikasi SaaS mengekspos server MCP yang membutuhkan token OAuth; agen SDM internal di balik A2A menggunakan identitas LDAP perusahaan; alat analitik pihak ketiga menggunakan SSO-nya sendiri. Pengguna mengharapkan "masuk sekali dan selesaikan semuanya", tetapi di balik layar, beberapa sistem identitas harus diintegrasikan.

Dokumen A2A Google secara eksplisit menyebutkan federasi multi-identitas sebagai tantangan utama. Seorang pengguna U mungkin berinteraksi dengan Agen A yang membutuhkan identitas sistem A (misalnya, LDAP perusahaan), sementara Agen A secara internal perlu mendelegasikan tugas ke Agen B yang membutuhkan identitas sistem B (misalnya, penyedia SaaS eksternal). Protokol harus mendukung pengiriman dan cakupan identitas ini tanpa memaksa pengguna untuk melakukan autentikasi ulang secara manual untuk setiap tahapan.

Penyedia identitas dan platform OAuth/OIDC dengan cepat beradaptasi dengan realitas baru ini. Infrastruktur seperti Logto, Auth0, atau penyedia identitas internal sudah dapat menerbitkan token yang dibawa agen melalui panggilan MCP dan A2A. Pertanyaan yang masih terbuka bukanlah apakah ini mungkin – jelas ini mungkin – tetapi bagaimana kita menstandarisasi pola sehingga alat yang dibangun hari ini tidak menjadi beban keamanan atau tata kelola di masa mendatang.

Selain otentikasi, pengamatan dan penegakan kebijakan kemungkinan akan dipindahkan ke "gerbang agen" bersama. Gateway tersebut dapat menghentikan lalu lintas MCP dan A2A, memusatkan pencatatan, memberlakukan batasan laju, melampirkan identitas pengguna dan agen, dan bahkan memfilter alat atau agen mana yang dapat diakses dalam konteks tertentu. Ini mulai terlihat sangat mirip dengan gateway API – hanya saja disesuaikan untuk lalu lintas AI, bukan HTTP biasa.

Jika dilihat dari perspektif yang lebih luas, MCP dan A2A secara diam-diam sedang membentuk kembali cara kita berpikir tentang integrasi perangkat lunak dan alat pengkodean. Bagi pengembang, asisten pengkodean yang terhubung ke MCP dan ACP (Protokol Klien Agen untuk IDE) dapat menemukan alat, memanggil server bahasa, berintegrasi dengan kontrol versi, dan berkomunikasi dengan agen pengembang lain – semuanya melalui protokol standar. Bagi perusahaan, sistem multi-agen dapat beroperasi lintas tim dan vendor tanpa perlu mengubah semua pengaturan untuk setiap kasus penggunaan baru.

Pergeseran jangka panjangnya adalah dari "aplikasi yang terintegrasi secara permanen" ke "ekosistem agen". Sama seperti USB dan HTTP yang memungkinkan untuk menghubungkan perangkat dan layanan apa pun, MCP dan A2A bertujuan untuk membuat alat dan agen dapat dipasang dan dilepas. Pemenangnya adalah tim yang memperlakukan protokol ini bukan hanya sebagai logo yang menarik, tetapi sebagai infrastruktur dasar tentang bagaimana sistem mereka berkomunikasi, berkolaborasi, dan berkembang dari waktu ke waktu.