MCP vs A2A: Tool Access dan Agent Collaboration Itu Beda Masalah

Di whiteboard sebuah tim AI, dua kotak sering digambar berdekatan: MCP dan A2A.

Lalu muncul pertanyaan yang kelihatannya sederhana.

“Kalau kita sudah pakai MCP, buat apa A2A?”

Atau kebalikannya.

“Kalau agent bisa bicara lewat A2A, kenapa masih perlu MCP?”

Masalahnya, pertanyaan itu menganggap MCP dan A2A mencoba menyelesaikan problem yang sama. Padahal dokumentasi resmi A2A v1.0 justru menegaskan bahwa keduanya complementary.

MCP berfokus pada bagaimana AI application atau agent mengakses tool, API, data source, dan resource eksternal secara terstruktur.

A2A berfokus pada bagaimana agent yang independen berkomunikasi dan berkolaborasi sebagai peer, termasuk discovery, delegation, task management, dan pertukaran context atau result.

Versi singkatnya:

MCP membantu agent memakai capability.

A2A membantu agent bekerja dengan agent lain.

Kelihatannya mirip karena dua-duanya hidup di dunia agentic system. Tetapi unit abstraksinya berbeda.

Tool bukan agent kecil

Mari mulai dari jebakan paling umum.

Sebuah tool MCP punya nama, deskripsi, input schema, dan output. Model atau host dapat memanggil tool itu untuk melakukan sesuatu seperti mencari record CRM, membuat ticket, membaca database, atau menghitung angka.

Tool bisa sangat powerful. Tool bahkan bisa membungkus workflow yang kompleks.

Tetapi tool tetap bukan otomatis sebuah independent agent.

Tool umumnya tidak perlu punya identity sebagai collaborator, tidak perlu mengiklankan Agent Card, tidak perlu menerima delegated task sebagai peer, tidak perlu mempertahankan task lifecycle ala A2A, dan tidak perlu melakukan negotiation seperti agent yang berdiri sendiri.

Contoh paling gampang: fungsi “get_customer_balance”.

Agent finance memanggil tool itu, mengirim customer ID, lalu menerima balance.

Tidak ada alasan natural untuk memperlakukan balance lookup sebagai agent independen yang perlu ditemukan, diajak berkolaborasi, dan diberi task.

Kalau setiap function dijadikan agent, arsitektur justru bisa berubah menjadi drama organisasi digital. Semua hal punya identity, semua perlu discovery, semua punya protocol lifecycle, padahal sebagian hanya function call.

Agent bukan tool besar

Sekarang kebalikannya.

Bayangkan agent procurement independen milik vendor A. Agent itu bisa menerima request kompleks seperti:

“Carikan tiga supplier yang memenuhi policy ini, minta quotation, bandingkan lead time, lalu kembalikan shortlist dengan alasan.”

Agent tersebut mungkin perlu beberapa langkah internal. Ia bisa punya reasoning sendiri, policy sendiri, data source sendiri, bahkan manusia yang harus approve sebagian action.

Dari perspektif agent peminta, kita tidak selalu ingin tahu tool internal apa yang dipakai agent procurement tersebut.

Kita ingin mendelegasikan outcome.

Di situlah A2A lebih natural.

A2A memungkinkan agent berkomunikasi sebagai sistem independen. Client agent menemukan Agent Card, memahami capability, memilih interface yang compatible, lalu berinteraksi melalui operasi protocol untuk message dan task.

Internal implementation bisa opaque.

Agent server mungkin memakai lima MCP server, tiga API proprietary, database internal, dan workflow manusia. Client tidak harus melihat semua detail itu.

Ini beda dengan MCP, di mana capability tool memang diekspos agar host atau model dapat memanggilnya.

Satu skenario, dua protocol

Sekarang gabungkan keduanya.

Sebuah perusahaan punya “Travel Coordinator Agent”. User bilang:

“Susun perjalanan tim ke Singapura bulan depan, cari penerbangan sesuai policy, hotel dekat lokasi meeting, lalu siapkan approval.”

Travel Coordinator Agent bisa menggunakan A2A untuk mendelegasikan bagian tertentu ke external Travel Booking Agent milik partner.

Travel Booking Agent menerima task sebagai agent lain.

Di dalam sistemnya sendiri, ia bisa menggunakan MCP untuk:

mengakses database policy perjalanan,
memanggil search tool penerbangan,
membaca availability hotel,
menulis draft itinerary,
dan mengirim request approval ke sistem internal.

Dari luar, A2A menangani relationship agent-to-agent.

Di dalam, MCP membantu agent mengakses capability dan resource.

Inilah alasan kalimat “MCP vs A2A” sering menyesatkan. Secara arsitektural, banyak sistem justru akan memakai “MCP plus A2A”.

Pilih berdasarkan boundary

Cara paling praktis membedakan keduanya adalah melihat boundary yang ingin distandardisasi.

Kalau boundary-nya:

AI host ke database,
AI host ke business API,
agent ke search tool,
agent ke internal workflow,
agent ke resource,

MCP sering menjadi kandidat yang masuk akal.

Kalau boundary-nya:

agent perusahaan A ke agent perusahaan B,
manager agent ke specialist agent yang independen,
agent yang mendelegasikan task ke remote agent,
agent yang perlu discovery capability agent lain,

A2A lebih dekat dengan problem tersebut.

Tentu ini bukan hukum alam. API biasa juga bisa dipakai. Custom messaging juga bisa dipakai. Yang kita nilai adalah apakah standard protocol memberi value yang cukup dibanding complexity tambahannya.

MCP memberikan standard tool surface

Salah satu kekuatan MCP adalah standardisasi cara AI application melihat external system.

Server dapat mengekspos tool, resource, prompt, dan capability lain dalam kontrak yang dipahami MCP client. Pada spec 2026-07-28, core juga bergerak ke model stateless yang lebih cocok dengan ordinary HTTP infrastructure, sementara capability tambahan dapat berkembang sebagai extension.

Dari perspektif perusahaan, manfaatnya bukan “AI jadi lebih pintar secara otomatis”.

Manfaatnya adalah integration surface menjadi lebih konsisten.

Daripada setiap AI host membutuhkan adapter proprietary untuk sistem yang sama, MCP menawarkan satu bahasa integrasi yang bisa didukung banyak host.

Namun ada batasnya.

MCP tidak otomatis memberi semantics bahwa remote system adalah autonomous peer yang punya own task lifecycle dan collaboration model.

A2A memberikan standard collaboration surface

A2A mengambil level abstraksi lebih tinggi.

Agent Card menyatakan capability dan interface agent. Client kemudian dapat mengirim message, mengelola task, menerima update, menangani streaming atau push notification bila didukung, dan bekerja dengan hasil yang lebih kompleks daripada function return sederhana.

A2A v1.0 juga makin serius soal versioning, interface selection, signature, security scheme, dan multi-binding.

Ini cocok ketika dua sistem ingin saling memperlakukan sebagai agent, bukan sekadar caller dan function.

Perbedaannya terasa pada ownership.

Tool biasanya berada di bawah orchestration agent atau host yang memanggilnya.

Remote agent bisa punya autonomy dan policy sendiri.

Ia boleh memutuskan bagaimana task dikerjakan, capability internal apa yang digunakan, dan bagaimana hasil disusun, selama tetap mematuhi kontrak protocol dan policy yang berlaku.

Jangan pakai A2A hanya karena architecture diagram terlihat futuristic

Di sebuah meeting product, seorang engineer bisa berkata:

“Kita pecah semua service jadi agent dan hubungkan A2A.”

Pertanyaan berikutnya harus: kenapa?

Kalau service sebenarnya deterministic, request-response sederhana, dimiliki satu tim, dan sudah punya API stabil, memaksanya menjadi A2A agent bisa menambah discovery, auth, lifecycle, observability, dan governance tanpa benefit yang jelas.

Agentic architecture bukan lomba siapa paling banyak punya agent.

Begitu juga MCP.

Kalau ada satu aplikasi internal yang memanggil satu API internal dengan integration stabil, membangun MCP server hanya demi mengatakan “sudah MCP” bisa menjadi architecture cosplay.

Protocol ada untuk mengurangi integration cost atau membuka interoperability, bukan menambah stiker teknologi.

Tiga pertanyaan untuk memilih

Pertanyaan pertama: siapa yang mengontrol workflow?

Jika satu host atau agent mengontrol workflow dan hanya membutuhkan capability eksternal, MCP biasanya natural.

Jika satu agent mendelegasikan outcome ke agent independen yang punya workflow sendiri, A2A mulai relevan.

Pertanyaan kedua: apa yang ingin ditemukan?

MCP tool discovery berfokus pada capability yang dapat dipanggil.

A2A discovery berfokus pada agent yang dapat diajak bekerja sama.

Keduanya sama-sama discovery, tetapi objek yang ditemukan berbeda.

Pertanyaan ketiga: seberapa opaque pihak di seberang boundary?

Untuk tool call, caller biasanya tahu kontrak input-output dan mengontrol kapan capability digunakan.

Untuk agent collaboration, caller bisa lebih fokus pada outcome dan memberi ruang kepada remote agent untuk menentukan proses internalnya.

Semakin tinggi autonomy dan independence di sisi remote, semakin masuk akal mempertimbangkan A2A.

Security juga berbeda bentuk

MCP dan A2A sama-sama perlu authentication, authorization, least privilege, logging, dan policy. Tetapi threat model praktisnya dapat berbeda karena bentuk interaksinya berbeda.

Tool yang bisa “delete customer” punya risiko action authorization yang sangat konkret. Scope dan confirmation harus ketat.

Remote agent yang menerima task kompleks punya risiko tambahan seperti delegated authority, context leakage, task scope ambiguity, atau capability misrepresentation.

Jadi jangan menyamakan security hanya karena keduanya memakai OAuth atau HTTP.

Yang harus diamankan adalah semantics dari action dan delegation.

Buat tim governance, pertanyaan pentingnya bukan hanya “protocol apa yang dipakai?” tetapi “siapa boleh meminta apa kepada siapa, dalam scope apa, dan siapa yang bertanggung jawab ketika hasilnya salah?”

MCP dan A2A di stack perusahaan

Sistem enterprise yang matang kemungkinan tidak punya satu protocol tunggal untuk semua hal.

API biasa tetap ada.

Event bus tetap ada.

MCP bisa menjadi AI-facing integration layer untuk tool dan data.

A2A bisa menjadi collaboration layer untuk agent yang memang perlu bekerja sebagai peer.

Web tetap menjadi surface untuk manusia dan machine discovery.

OAuth, identity provider, policy engine, observability, dan audit log tetap bekerja di bawahnya.

Artinya, protocol baru tidak menghapus arsitektur lama. Ia menambah layer yang lebih sesuai dengan pola interaction baru.

Dari perspektif GEO, ini juga punya implikasi menarik.

Selama ini visibility sering dipikirkan sebagai apakah halaman dan entity sebuah brand dapat ditemukan AI. Dalam agentic ecosystem, discovery bisa terjadi pada level capability dan agent relationship.

Brand mungkin punya website yang sangat jelas untuk manusia, tetapi kalau business capability tertentu hanya tersedia melalui integration proprietary yang tidak dapat ditemukan atau dinegosiasikan agent, ada gap baru antara “understood” dan “actionable”.

Namun jangan langsung menyimpulkan bahwa semua brand perlu Agent Card atau MCP server.

Yang perlu dilakukan pertama justru memetakan machine-facing capability.

Apa yang hanya perlu dibaca?

Apa yang perlu dipanggil sebagai tool?

Apa yang layak didelegasikan ke agent independen?

Apa yang harus tetap melalui manusia?

Setelah boundary itu jelas, pilihan protocol jauh lebih waras.

Bukan pertandingan protocol

MCP dan A2A terlihat seperti dua singkatan yang sedang berebut panggung. Dalam praktiknya, mereka lebih mirip dua lapisan kerja yang berbeda.

MCP menjawab: bagaimana agent memakai dunia di sekitarnya?

A2A menjawab: bagaimana agent bekerja dengan agent lain?

Satu agent bahkan bisa melakukan keduanya dalam satu task: berkolaborasi dengan remote agent melalui A2A, lalu memakai tool internal lewat MCP untuk menyelesaikan bagiannya.

Kalau tim masih debat “mana yang menang”, mungkin pertanyaannya belum tepat.

Ganti dengan pertanyaan yang lebih engineering-minded:

Boundary mana yang ingin kita standardisasi?

Kalau jawabannya tool access, lihat MCP.

Kalau jawabannya independent agent collaboration, lihat A2A.

Kalau dua-duanya ada, tidak perlu memilih satu hanya demi kesederhanaan slide.

Arsitektur yang bagus bukan yang paling sedikit singkatannya. Arsitektur yang bagus adalah yang setiap layer-nya menyelesaikan problem yang memang ada.