MCP (Model Context Protocol): Standar Baru yang Menghubungkan AI ke Dunia Nyata

Bayangkan kamu punya asisten paling pintar di dunia. Dia paham semua bahasa pemrograman, bisa menjelaskan arsitektur microservices sambil merem, dan menulis kode lebih cepat dari kamu mengetik. Tapi ada satu masalah kecil: dia tidak bisa membuka email kamu. Tidak bisa membaca database. Tidak bisa mengecek kenapa server production tiba-tiba 500. Dia pintar, tapi buta dan lumpuh — seperti otak brilian yang dikurung di dalam toples kaca.

Itulah kondisi large language model (LLM) selama bertahun-tahun. Model seperti Claude, ChatGPT, dan Gemini memang luar biasa dalam memahami bahasa, tapi secara default mereka tidak punya akses ke dunia nyata: tidak ke file di laptop kamu, tidak ke API perusahaanmu, tidak ke CMS tempat blog kamu tersimpan. Supaya AI bisa melakukan sesuatu — bukan sekadar menjawab sesuatu — developer harus membangun jembatan custom, satu per satu, untuk setiap kombinasi model dan tools. Mau Claude bisa baca Google Drive? Bikin integrasi khusus. Mau ChatGPT juga bisa? Bikin lagi dari nol. Mau Gemini juga? Ya, bikin lagi.

Model Context Protocol, atau MCP, lahir untuk memutus lingkaran setan itu. Diperkenalkan oleh Anthropic pada November 2024 sebagai standar terbuka, MCP adalah protokol universal yang memungkinkan aplikasi AI terhubung ke sumber data dan tools eksternal lewat satu antarmuka yang sama. Julukannya di industri: "USB-C untuk AI". Dan per Oktober 2026, julukan itu tidak lagi sekadar jargon marketing — adopsinya sudah mencapai skala yang sulit diabaikan.

Artikel ini akan mengupas tuntas MCP: apa itu sebenarnya, kenapa ia muncul, bagaimana cara kerjanya di balik layar, siapa saja yang sudah mengadopsinya, bagaimana ia dibandingkan dengan function calling biasa, contoh implementasi nyatanya (termasuk untuk CMS blog dan portfolio seperti Vechcode), tantangan keamanannya yang serius, dan ke mana protokol ini akan pergi selanjutnya. Semua dibahas dengan fakta terkini per Oktober 2026.

Masalah yang Ingin Diselesaikan MCP: Neraka Integrasi N × M

Sebelum memahami solusinya, pahami dulu betapa menyakitkannya masalahnya. Katakanlah perusahaanmu ingin menghubungkan tiga model AI — Claude, ChatGPT, dan Gemini — ke tiga sistem internal: Slack, Google Drive, dan Salesforce. Tanpa standar bersama, kamu harus membangun dan merawat sembilan integrasi terpisah (3 × 3). Setiap integrasi berarti logika autentikasi sendiri, transformasi format data sendiri, error handling sendiri, audit keamanan sendiri, dan maintenance sendiri setiap kali ada API yang berubah.

Inilah yang disebut masalah N × M: N aplikasi AI dikali M tools sama dengan N × M integrasi custom. Setiap tools baru yang ingin didukung AI harus diintegrasikan satu per satu ke setiap aplikasi AI. Setiap aplikasi AI baru yang muncul harus membangun konektor ke setiap tools dari nol. Kompleksitasnya tumbuh secara kuadratik, dan inilah yang selama ini menjadi penghambat terbesar adopsi AI di enterprise — bukan kemampuan modelnya, melainkan kerapuhan integrasinya.

MCP memangkas masalah ini menjadi N + M. Kamu membangun satu MCP server untuk tools-mu — sekali saja — dan seketika itu juga setiap aplikasi AI yang kompatibel dengan MCP (Claude, ChatGPT, Gemini, Cursor, VS Code, dan lain-lain) bisa langsung menggunakannya. Tidak perlu menulis ulang, tidak perlu shim khusus per platform. Perubahan dari kompleksitas kuadratik ke linear inilah yang mengubah MCP dari sekadar kemudahan developer menjadi fondasi ekonomi agen AI.

Analoginya memang pas dengan USB-C. Sebelum USB-C, setiap produsen gadget punya colokan charger sendiri-sendiri; laci kita penuh kabel yang tidak saling kompatibel. USB-C tidak membuat gadget-nya lebih pintar — ia membuat koneksinya standar sehingga inovasi bisa terjadi di kedua sisi tanpa friction. MCP melakukan hal yang sama untuk AI: ia tidak membuat model lebih pintar, ia membuat koneksi antara model dan dunia luar menjadi standar.

Apa Itu MCP, Sebenarnya?

Secara definisi, Model Context Protocol adalah protokol terbuka yang menstandarkan cara aplikasi AI (seperti LLM dan agen AI) terhubung ke sumber data dan tools eksternal. Kata kuncinya ada tiga: terbuka (open standard, bukan milik satu vendor), terstandar (satu cara untuk semua), dan konteks (soal memberi model akses ke konteks dunia nyata).

Beberapa hal penting yang perlu diluruskan sejak awal:

Pertama, MCP itu model-agnostic. Ia tidak terikat ke Claude, ChatGPT, atau model tertentu. Aplikasi AI apa pun yang mengimplementasikan sisi klien dari protokol ini bisa terhubung ke MCP server mana pun. Per Oktober 2026, Claude, ChatGPT, Gemini, dan Microsoft Copilot semuanya sudah mendukungnya.

Kedua, MCP berbasis JSON-RPC 2.0. Bagi developer, ini kabar baik: protokolnya menggunakan format messaging yang sudah familiar — request/response JSON-RPC yang berjalan di atas transport stdio (untuk proses lokal) atau Streamable HTTP (untuk server remote). Tidak ada format binary eksotis, tidak ada IDL baru yang harus dipelajari.

Ketiga, MCP kini dikelola secara vendor-neutral. Pada Desember 2025, Anthropic mendonasikan MCP ke Agentic AI Foundation (AAIF) di bawah Linux Foundation. Langkah ini krusial: ia mengubah MCP dari "standar milik Anthropic" menjadi infrastruktur milik bersama. Para kompetitor yang jarang akur — OpenAI, Google, Microsoft, AWS, Cloudflare, GitHub, Block, Bloomberg — semuanya duduk di dewan governance yang sama. Ketika rival-rival terbesar industri mau duduk semeja, kamu tahu bahwa masalah yang diselesaikan memang benar-benar nyata. Per September 2026, AAIF bahkan tumbuh menjadi 240 anggota dan disebut sebagai yayasan dengan pertumbuhan tercepat dalam sejarah Linux Foundation.

Cara Kerja MCP: Tiga Aktor di Atas Panggung

Arsitektur MCP memisahkan peran menjadi tiga lapisan yang bersih: Host, Client, dan Server. Memahami ketiganya adalah kunci memahami seluruh protokol.

MCP Host adalah aplikasi AI yang ingin mengakses data dan tools — misalnya Claude Desktop, Cursor, Windsurf, VS Code dengan Copilot, atau ChatGPT. Host adalah "otak" dari operasi: ia menjalankan LLM, mengelola percakapan dengan user, dan memutuskan kapan perlu memanggil tools eksternal.

MCP Client adalah komponen protokol yang menjaga koneksi 1:1 dengan satu server, atas nama host. Satu host bisa memiliki banyak client sekaligus, masing-masing terhubung ke server yang berbeda. Client inilah yang menerjemahkan keinginan model ("aku butuh data X") menjadi pesan JSON-RPC yang dikirim ke server, lalu mengembalikan hasilnya ke model.

MCP Server adalah program ringan yang mengekspos kapabilitas spesifik lewat protokol MCP. Server inilah yang kamu bangun (atau install dari komunitas): server untuk GitHub, server untuk PostgreSQL, server untuk Google Drive, server untuk CMS blog kamu. Setiap server mendeklarasikan apa yang ia sediakan, dan client bisa men-discover-nya secara otomatis.

Alurnya dalam praktik terlihat seperti ini. Misalkan kamu mengetik di Claude Desktop: "Tolong ringkas 5 issue terakhir yang belum selesai di repo backend-api." Berikut yang terjadi di balik layar:

1. Host (Claude Desktop) meneruskan pesanmu ke model.
2. Model menyadari ia butuh data dari GitHub, dan melihat bahwa salah satu MCP client-nya terhubung ke GitHub MCP server yang punya tool list_issues.
3. Client mengirim request JSON-RPC tools/call ke server dengan argumen yang sesuai.
4. Server mengeksekusi (memanggil GitHub API dengan kredensial yang sudah dikonfigurasi), lalu mengembalikan hasilnya.
5. Model menerima hasil tersebut sebagai konteks tambahan, lalu menyusun ringkasan untukmu.

Yang elegan: sebagai user, kamu tidak pernah mengonfigurasi "cara memanggil GitHub API" di Claude. Kamu cukup menginstall GitHub MCP server sekali, dan semua aplikasi AI yang kompatibel langsung bisa memakainya. Pemisahan peran ini juga berarti satu host bisa terhubung ke banyak server secara simultan — GitHub untuk kode, Postgres untuk data, Slack untuk komunikasi — masing-masing lewat client-nya sendiri.

Tiga Primitif: Tools, Resources, dan Prompts

MCP server mengekspos tiga jenis kapabilitas, yang disebut primitif. Memahami ketiganya penting karena mereka menjawab tiga kebutuhan berbeda dari AI.

Tools adalah fungsi yang bisa dipanggil oleh model untuk melakukan aksi. Membuat record di CRM, mengirim email, mengeksekusi query database, memicu deploy — semua itu adalah tools. Setiap tool dideklarasikan dengan nama, deskripsi (yang dibaca oleh model!), dan skema input dalam bentuk JSON Schema. Deskripsi ini penting banget: model memutuskan kapan memakai tool berdasarkan deskripsinya. Nanti kita akan lihat bahwa deskripsi inilah yang menjadi salah satu vektor serangan keamanan paling licik.

Resources adalah sumber data yang bisa dibaca oleh model — dokumen, file, skema database, isi API. Bedanya dengan tools: resources bersifat read-only dan tidak mengeksekusi aksi. Kalau tools adalah "tangan" AI, resources adalah "mata"-nya. Contoh: MCP server untuk PostgreSQL bisa mengekspos skema tabel sebagai resource (supaya model tahu struktur datanya) dan query executor sebagai tool (supaya model bisa mengambil datanya).

Prompts adalah template instruksi yang disediakan oleh server untuk memandu perilaku model dalam workflow tertentu. Misalnya, server untuk code review bisa menyediakan prompt "review kode ini dengan standar keamanan OWASP" — user tinggal memilih prompt tersebut, dan model menjalankannya dengan konteks yang sudah disiapkan server.

Ketiganya bersama-sama inilah yang membedakan sistem AI yang terhubung MCP dari chatbot biasa yang hanya bekerja dengan data training-nya. Chatbot menjawab dari ingatan; agen berbasis MCP membaca, memutuskan, dan bertindak di dunia nyata.

Transport: stdio untuk Lokal, Streamable HTTP untuk Remote

MCP mendukung dua transport utama, dan pemilihannya tergantung di mana server berjalan.

stdio (standard input/output) dipakai ketika server berjalan sebagai proses lokal di mesin yang sama dengan host — misalnya plugin di Claude Desktop atau Cursor yang perlu membaca file di laptop kamu. Host menjalankan server sebagai subprocess dan berkomunikasi lewat stdin/stdout. Sederhana, cepat, dan ideal untuk akses lokal. Tapi ingat: model keamanan stdio inilah yang belakangan menjadi sorotan tajam para peneliti keamanan, seperti akan kita bahas nanti.

Streamable HTTP adalah transport untuk server remote — server yang berjalan di cloud atau di VPS, diakses lewat HTTP. Inilah transport yang membuat MCP layak untuk production dan enterprise: server CMS, server internal perusahaan, atau API publik bisa diekspos sebagai MCP server yang diakses dari mana saja. Dulu MCP sempat memakai HTTP+SSE (Server-Sent Events), tetapi sejak revisi spesifikasi 2025-03-26, Streamable HTTP menjadi transport HTTP resmi yang menggantikannya.

Contoh konkret yang dekat dengan kita: Vechcode — platform AI router yang sedang dibangun — mengekspos MCP server remote di https://vechcode.com/api/mcp dengan transport Streamable HTTP. Agen AI mana pun yang dikonfigurasi dengan API key yang valid bisa terhubung ke endpoint itu dan mengelola konten blog, portfolio, dan produk lewat tools seperti blog_list, blog_create, atau portfolio_update. Tidak perlu SDK khusus Vechcode, tidak perlu integrasi custom per aplikasi AI — cukup satu endpoint yang berbicara dalam bahasa MCP standar.

Evolusi Protokol: Dari Prototipe Riset Menjadi Infrastruktur

Salah satu hal paling menarik dari MCP adalah kecepatan evolusinya. Spesifikasinya direvisi dengan ritme yang cukup konsisten, dan setiap revisi menandai pendewasaan yang nyata. Berikut linimasanya:

• 2024-11-05 — Spesifikasi awal: model client-server, messaging JSON-RPC 2.0, tiga primitif (tools, resources, prompts), transport stdio dan HTTP+SSE.
• 2025-03-26 — Otorisasi berbasis OAuth 2.1, transport Streamable HTTP (menggantikan HTTP+SSE), tool annotations, konten audio, dan JSON-RPC batching.
• 2025-06-18 — Structured tool output, elicitation (server bisa meminta input tambahan dari user lewat client), resource links, dan halaman security best practices.
• 2025-11-25 — OpenID Connect Discovery, metadata ikon, elicitation enums berbasis standar, dan experimental tasks.
• 2026-07-28 — Revisi terbesar sejak peluncuran, dan yang berlaku sebagai versi "current" per Oktober 2026.

Revisi 2026-07-28 layak dibedah lebih dalam karena ia mengubah karakter protokol secara fundamental: dari "prototipe riset" menjadi "infrastruktur". Perubahan terbesarnya adalah inti protokol yang kini sepenuhnya stateless. Handshake initialize/initialized dihapus, begitu pula header Mcp-Session-Id yang dulu mengikat client ke satu instance server tertentu. Setiap request kini bersifat mandiri (self-contained): ia membawa versi protokol dan info client-nya sendiri, sehingga instance server mana pun bisa menjawab request mana pun. Konsekuensinya besar untuk production: MCP kini bisa berjalan di belakang load balancer HTTP standar tanpa session affinity, memungkinkan horizontal scaling untuk puluhan ribu agen dalam satu deployment.

Revisi yang sama juga memperkenalkan server/discover (client mengambil kapabilitas server on-demand, bukan otomatis saat handshake), routing berbasis header (MCP-Protocol-Version, Mcp-Method, Mcp-Name), hasil listing yang bisa di-cache (dengan hint ttlMs dan cacheScope), ekstensi Tasks untuk operasi long-running, sebuah extensions framework resmi, pengerasan OAuth/DCR, dan — yang penting untuk enterprise — kebijakan depresiasi formal: tidak ada fitur dalam kohort ini yang boleh dihapus sebelum Juli 2027. Pesan yang ingin disampaikan jelas: bangun di atas MCP dengan tenang, fondasinya tidak akan digeser tiba-tiba.

Lalu pada 28 September 2026, datang apa yang disebut sebagai "rilis enterprise" — finalisasi dari arah panjang tersebut. Sorotannya: Enterprise Managed Authorization yang dibangun bersama Okta (IdP korporat menjadi gatekeeper resmi untuk akses MCP server — kredensial korporat, bukan personal), validasi wajib terhadap parameter iss (issuer) OAuth untuk menutup seluruh kelas serangan mix-up, serta kelulusan MCP Apps dan MCP Tasks menjadi ekstensi resmi. MCP Apps sendiri sudah mendarat sejak Januari 2026: ia memungkinkan server me-render UI HTML interaktif di dalam iframe yang di-sandbox, langsung di dalam Claude, ChatGPT, VS Code, dan Goose. Bayangkan tool MCP yang tidak hanya mengembalikan teks, tapi menampilkan dashboard mini yang bisa diklik — itulah MCP Apps.

Siapa yang Mengadopsi? Angkanya Bicara Sendiri

Adopsi MCP di 2026 bukan lagi cerita "menarik untuk dicoba" — ia sudah menjadi standar de facto. Mari kita lihat angkanya, semuanya dari paruh pertama 2026:

• 97 juta download SDK per bulan (paket Python dan TypeScript digabung) — tumbuh dari sekitar 2 juta saat peluncuran. Itu pertumbuhan hampir 50 kali lipat dalam waktu kurang dari dua tahun.
• 9.400 hingga lebih dari 10.000 MCP server publik tercatat pada pertengahan 2026, belum termasuk server privat/internal perusahaan yang diperkirakan 3–4 kali lipatnya.
• 78% tim AI enterprise melaporkan sudah menjalankan minimal satu agen berbasis MCP di production (survei April 2026).
• 28% perusahaan Fortune 500 telah mengimplementasikan MCP server.
• Tersedia 10 SDK resmi: Python, TypeScript, Go, Java, Kotlin, C#, PHP, Ruby, Rust, dan Swift — jadi hampir tidak ada developer yang terkecuali dari ekosistem ini.

Daftar pengadopsinya membaca seperti daftar tamu acara industri: Anthropic (Claude Desktop, Claude Code — implementasi referensi), OpenAI (ChatGPT), Google (Gemini/DeepMind), Microsoft (VS Code Copilot — akses ke basis pengguna IDE terbesar di planet ini), Block, Cloudflare (Workers AI), AWS, GitHub, Salesforce, Snowflake. Di sisi tools developer: Cursor dan Windsurf menjadikannya fondasi context awareness, Replit untuk workflow agentic development, Sourcegraph untuk Cody, plus platform otomasi seperti n8n, Zapier, dan Activepieces.

Yang menarik, adopsi ini juga melahirkan pola penggunaan yang konkret di enterprise. Organisasi yang datanya tersebar di SharePoint, Confluence, wiki internal, dan database proprietary memakai MCP server untuk memberi asisten AI pandangan terpadu — tanpa harus memigrasi data ke satu tempat. Datanya tetap di mana ia berada; AI mengaksesnya lewat MCP. Pencarian seperti "Salesforce MCP server" atau "SAP MCP connector" terus naik — sinyal bahwa para technical leader sudah berpikir dalam kerangka "hubungkan stack yang ada ke AI lewat MCP", bukan lewat integrasi one-off.

Bahkan ada angka ROI yang mulai terdokumentasi: Forbes dilaporkan menghemat 18.000 jam kerja per tahun, dan Agentforce dari Salesforce mencapai resolusi kasus 84% lebih cepat dengan sistem AI berbasis MCP. Tentu, angka-angka vendor seperti ini patut dibaca dengan skeptis, tapi arahnya jelas.

MCP vs Function Calling Biasa: Apa Bedanya?

Pertanyaan yang paling sering muncul dari developer: "Bukankah ini sama saja dengan function calling yang sudah ada di API LLM?" Jawabannya: mirip di permukaan, beda jauh di filosofi. Mari kita bedah.

Function calling (atau tool use) adalah fitur di mana kamu mendefinisikan daftar fungsi secara manual di setiap request ke model — lengkap dengan nama, deskripsi, dan skema parameternya — lalu model memilih fungsi mana yang dipanggil. Ini bekerja, tapi ada masalah struktural:

1. Definisi manual per aplikasi. Setiap aplikasi yang memakai model harus mendefinisikan ulang fungsi-fungsinya sendiri. Pindah dari Claude ke GPT? Tulis ulang definisinya dalam format yang sedikit berbeda.
2. Tidak ada discovery. Model hanya tahu fungsi yang kamu daftarkan secara eksplisit. Tidak ada mekanisme standar bagi model untuk bertanya "tools apa saja yang tersedia di sini?"
3. Format berbeda-beda. Setiap provider punya dialek function calling sendiri. Kode integrasimu terikat ke satu vendor.
4. Auth dan skema seadanya. Kamu yang mengurus semuanya sendiri: bagaimana kredensial diteruskan, bagaimana error diketikkan, bagaimana tools di-dokumentasikan ke model.

MCP membalik pendekatannya:

Cara paling ringkas memahaminya: function calling berkata "ini daftar fungsi yang boleh kamu panggil", sedangkan MCP berkata "ini cara standar untuk menemukan fungsi apa pun yang tersedia, memahami cara pakainya, dan memanggilnya dengan aman — di aplikasi AI mana pun". Function calling adalah fitur; MCP adalah lapisan infrastruktur.

Tentu, keduanya tidak saling meniadakan. Di balik layar, host MCP tetap menggunakan kemampuan tool-use dari model untuk mengeksekusi pemanggilan. MCP hanya menstandarkan segala sesuatu di sekitarnya: discovery, skema, auth, transport, dan lifecycle.

Contoh Implementasi Nyata: Dari GitHub sampai CMS Blog

Teori cukup — mari lihat MCP bekerja di dunia nyata, dari yang generik sampai yang spesifik seperti CMS.

Contoh 1: GitHub MCP Server. Ini salah satu server komunitas paling populer. Setelah terhubung, kamu bisa mengetik di Claude Desktop atau Cursor: "Buatkan PR untuk branch feature-login dengan ringkasan perubahan dari 5 commit terakhir." AI akan memanggil tool untuk membaca commit, menyusun deskripsi, dan membuka pull request — semuanya lewat protokol yang sama, tanpa kamu menulis satu baris pun kode integrasi GitHub.

Contoh 2: PostgreSQL MCP Server. "Berapa total revenue bulan lalu dari tabel orders, dan bandingkan dengan bulan sebelumnya?" Server mengekspos skema tabel sebagai resource (supaya model paham struktur data) dan eksekutor query sebagai tool. Model menyusun SQL-nya sendiri, menjalankannya lewat tool, dan menyajikan jawabannya dalam bahasa natural. Tentu, dengan kontrol akses yang ketat — kita akan bahas risikonya di bagian keamanan.

Contoh 3: CMS untuk blog dan portfolio — studi kasus Vechcode. Inilah contoh yang paling relevan buat kita sebagai developer Indonesia yang mengelola konten web. Vechcode mengekspos MCP server di https://vechcode.com/api/mcp dengan tools seperti blog_list, blog_get, blog_create, blog_update, portfolio_list, hingga product_create. Artinya, seluruh manajemen konten — yang biasanya lewat dashboard admin — bisa dilakukan lewat percakapan dengan AI.

Skenarionya: kamu membuka aplikasi AI favoritmu yang sudah terhubung ke server Vechcode, lalu mengetik: "Buatkan draft artikel tentang tips optimasi Core Web Vitals, sekitar 800 kata, dalam Bahasa Indonesia." AI memanggil blog_create dengan argumen title, content (Markdown), excerpt, dan isPublished: false — dan draft tersimpan sebagai draft, bukan langsung publish. Kamu review dulu di dashboard, lalu publish manual. Atau: "Tampilkan 5 portfolio terakhir, lalu update deskripsi project X." Semua lewat bahasa natural, semua tercatat dalam audit log server.

Pola ini powerful karena ia mengubah CMS dari "aplikasi yang harus dibuka" menjadi "kemampuan yang bisa dipanggil dari mana saja". Dan karena memakai protokol standar, kamu tidak terkunci ke satu aplikasi AI — ganti dari Claude ke ChatGPT ke Gemini, koneksinya tetap sama.

Contoh 4: Bikin MCP server sendiri — sesederhana ini. Dengan SDK resmi, membuat server bisa sangat ringkas. Berikut sketsa dalam TypeScript yang mengekspos satu tool untuk sebuah blog:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "blog-cms", version: "1.0.0" });

server.tool(
  "create_draft",
  "Buat draft artikel blog baru (selalu sebagai draft, tidak langsung publish)",
  {
    title: z.string().describe("Judul artikel"),
    content: z.string().min(50).describe("Isi artikel dalam Markdown, minimal 50 karakter"),
    lang: z.enum(["id", "en"]).default("id"),
  },
  async ({ title, content, lang }) => {
    const slug = title.toLowerCase().replace(/[^a-z0-9]+/g, "-");
    const draft = await db.drafts.insert({ title, content, lang, slug, published: false });
    return {
      content: [{ type: "text", text: `Draft tersimpan: ${draft.slug} (belum dipublish)` }],
    };
  }
);

await server.connect(new StdioServerTransport());

Perhatikan betapa deskripsi tool ditulis dalam bahasa natural — karena yang membacanya adalah model, bukan manusia. Untuk server production, kamu akan memakai Streamable HTTP transport dengan autentikasi Bearer (persis seperti pola Vechcode), menambahkan validasi input yang ketat, dan mewajibkan isPublished: false sebagai default — prinsip "aman secara default" yang akan kita perdalam di bagian keamanan.

Tantangan Keamanan: Bagian yang Tidak Boleh Di-skip

Sekarang bagian yang serius — dan jujur saja, bagian yang paling penting dari artikel ini. MCP memberi AI "tangan" untuk bertindak di dunia nyata, dan setiap tangan baru adalah permukaan serangan baru. Spesifikasi resminya sendiri mengakui secara eksplisit bahwa protokol "tidak dapat menegakkan prinsip-prinsip keamanan ini di level protokol". Terjemahan bebasnya: MCP menyediakan ruangannya, kamulah yang harus membawa gemboknya. Dan kebanyakan tim tidak melakukannya.

OWASP menerbitkan MCP Top 10 pada 2025 — klasifikasi risiko MCP pertama yang proper. Berikut ancaman yang benar-benar terjadi di lapangan, bukan sekadar teori:

1. Prompt injection. Instruksi tersembunyi di dalam data, output tool, atau halaman web membajak agen. Karena MCP pada dasarnya adalah "protokol untuk menyuntikkan data eksternal ke context window LLM", ia menjadi vektor utama untuk serangan ini. Satu studi awal 2026 menemukan arsitektur MCP memperkuat tingkat keberhasilan serangan prompt injection secara signifikan dibanding baseline.

2. Tool poisoning — yang paling licik. Penyerang menanam instruksi jahat di dalam deskripsi tool. Ingat: deskripsi tool dibaca oleh model, tapi jarang dibaca oleh manusia. Tool yang terlihat seperti kalkulator add(a, b) yang tidak berbahaya bisa diam-diam memerintahkan agen untuk membaca file privat dan mengirimkannya keluar. Benchmark MCPTox menguji 20 agen LLM terhadap 45 MCP server nyata — hasilnya: sebagian besar rentan.

3. Rug pull. Tool yang sudah kamu audit dan approve minggu lalu diam-diam mengupdate perilakunya minggu ini. Tidak ada permintaan approval ulang. Tidak ada notifikasi. Kamu memvetting sesuatu yang aman; server menukarnya dengan yang jahat.

4. Tool shadowing. Server jahat mendaftarkan tool dengan nama yang sama persis dengan tool tepercaya. Agen memilih yang salah. Kamu tidak pernah sadar.

5. Serangan supply chain. Paket MCP jahat pertama muncul di registry publik pada September 2025 — tekniknya klasik: typosquatting dan paket yang meniru server "resmi". CVE-2025-49596 (skor CVSS 9.4, kritis) memungkinkan eksekusi perintah arbitrer lewat instance MCP Inspector yang tidak diautentikasi. Pada Februari 2026, worm npm SANDWORM_MODE bahkan menyertakan modul "McpInject" yang menanam rogue MCP server di mesin korban untuk mencuri SSH key, kredensial AWS, dan file .env dari pengguna Claude Code, Cursor, dan VS Code. Audit OX Security menempatkan dampaknya pada 200+ proyek open source, 150 juta+ download SDK, 7.000+ server yang terekspos publik, dan sekitar 200.000 instance yang rentan.

6. Confused deputy & scope berlebihan. Server MCP bertindak atas nama user tapi dengan hak akses yang lebih luas dari yang dimiliki user. Token dengan scope files:* atau admin:* yang bocor dari log berarti satu token yang dicuri membuka seluruh blast radius.

7. Agregasi kredensial. Satu MCP server memegang kredensial untuk Slack, GitHub, Postgres, dan Salesforce sekaligus. Kompromikan satu server, jebol empat sistem.

Kabar baiknya: tidak semua suram. Revisi spesifikasi akhir 2025 mewajibkan OAuth 2.1 dengan PKCE, token yang terikat ke server spesifik (resource indicators), dan HTTPS di seluruh jalur. Revisi 2026-07-28 mengeraskan lagi dengan validasi wajib terhadap parameter iss (issuer) untuk menutup serangan mix-up — dan menurut maintainer-nya, ini adalah preventive engineering, bukan respons insiden: belum ada eksploitasi yang diketahui, mereka menutupnya duluan.

Tapi ada satu hal yang harus dipahami dengan jernih: tidak ada revisi spesifikasi yang bisa memperbaiki tool poisoning dan prompt injection. Keduanya mengeksploitasi cara model bahasa memproses teks, bukan cara token diterbitkan. Itu keterbatasan fundamental LLM, bukan bug implementasi.

Lalu apa yang bisa dilakukan developer secara praktis? Checklist yang realistis:

• Prinsip least privilege: beri setiap server hanya scope minimum yang ia butuhkan. Butuh baca repo? Jangan kasih scope tulis.
• Pin versi dan verifikasi publisher sebelum menginstall server komunitas; perlakukan server MCP seperti dependensi yang belum diaudit — karena memang begitu.
• Baca deskripsi tool sebelum approve, terutama untuk server yang baru dipasang.
• Human-in-the-loop untuk aksi destruktif atau ireversibel (hapus data, kirim uang, publish konten). Spesifikasi hanya "menganjurkan" ini — jadikan kewajiban di implementasimu.
• Jangan pernah hardcode kredensial di konfigurasi server; pakai secret manager atau environment yang proper.
• Log setiap pemanggilan tool — audit trail adalah satu-satunya cara merekonstruksi timeline saat insiden terjadi.
• Untuk server yang kamu bangun sendiri: validasi semua input, jaga deskripsi tool tetap bersih dari apapun yang menyerupai instruksi untuk model, dan default-kan ke mode aman (contoh: konten baru selalu draft dulu, seperti pola isPublished: false di contoh Vechcode tadi).

Masa Depan: Ke Mana MCP Akan Pergi?

Jika fase 2024–2025 adalah "integrasi dasar" (tools, resources, prompts — agen bisa membaca dan memanggil), maka 2026 adalah fase "kapabilitas kaya": Tasks untuk operasi long-running, multi-round interaction, MCP Apps untuk antarmuka UI, dan otorisasi enterprise. Peta jalannya, yang ditetapkan pada Maret 2026, berfokus pada empat area prioritas: evolusi transport dan skalabilitas, komunikasi antar-agen, pendewasaan governance, dan kesiapan enterprise.

Satu perkembangan arsitektural yang paling penting untuk dipahami adalah model dua lapis yang kini menjadi referensi: MCP untuk akses tools dan data, A2A untuk koordinasi antar-agen. A2A (Agent-to-Agent, awalnya dari Google) menangani lifecycle task, update streaming, dan negosiasi kapabilitas antar agen yang otonom. Keduanya bukan rival — mereka komplementer, dan kini keduanya hidup di bawah naungan Linux Foundation yang sama. Aturan praktisnya: pakai MCP setiap kali agen perlu memanggil tool atau membaca resource di luar dirinya; pakai A2A saat satu agen perlu mendelegasikan ke agen lain, terutama lintas tim atau vendor.

Di cakrawala sudah terlihat fase berikutnya: Skills (agen mengeksekusi prosedur terdokumentasi, bukan sekadar fungsi individual), event-driven MCP (agen bereaksi terhadap perubahan di sistem underlying, bukan hanya dipanggil), hasil berbasis streaming dan referensi untuk dataset besar, serta mekanisme trust machine-to-machine yang lebih kuat seperti DPoP dan Workload Identity Federation. Ada juga MCP Server Cards — metadata server terstruktur yang disajikan lewat URL .well-known, sehingga registry dan crawler bisa menemukan kapabilitas tanpa koneksi live.

Framing yang paling tepat untuk MCP ke depan, meminjam analogi dari para pengamatnya: ia sedang bertransformasi dari "API untuk memanggil fungsi" menjadi application protocol untuk agen — seperti HTTP yang dulu hanya "cara mengambil dokumen" lalu menjadi substrat bagi seluruh aplikasi modern. Fondasinya (stateless, cacheable, terotentikasi, tergovernance dengan kebijakan depresiasi yang jelas) sudah diletakkan. Yang tersisa adalah apa yang akan dibangun di atasnya.

Kesimpulan: Standar yang Layak Kamu Pelajari Sekarang

Mari rangkum perjalanan kita. MCP lahir dari masalah nyata — neraka integrasi N × M — dan menyelesaikannya dengan elegan lewat protokol terbuka yang memisahkan peran host, client, dan server, dengan tiga primitif (tools, resources, prompts) dan dua transport (stdio, Streamable HTTP). Dalam waktu kurang dari dua tahun ia berevolusi dari prototipe menjadi infrastruktur: stateless, scalable, terotentikasi dengan OAuth 2.1, dan dikelola secara vendor-neutral di bawah Linux Foundation dengan ratusan anggota. Adopsinya — 97 juta download SDK per bulan, 10.000+ server publik, mayoritas tim AI enterprise sudah production — menjadikannya taruhan yang aman untuk dipelajari.

Tapi ia bukan tanpa cela. Model keamanannya menuntut kedisiplinan implementor: tool poisoning, rug pull, dan serangan supply chain adalah ancaman nyata yang sudah memakan korban. Protokolnya memberi fondasi; gemboknya tetap tanggung jawabmu.

Buat kamu developer Indonesia yang membaca ini, kabar baiknya: barrier untuk mulai sangat rendah. Tiga langkah praktis untuk minggu ini:

1. Coba dulu yang sudah ada. Install satu MCP server komunitas — misalnya server GitHub atau Postgres — di Claude Desktop atau Cursor, dan rasakan sendiri perbedaannya dibanding chatbot biasa.
2. Baca spesifikasinya. Dokumentasi di modelcontextprotocol.io termasuk yang paling rapi di industri; sketsa arsitekturnya bisa dipahami dalam satu sore.
3. Bangun satu server kecil untuk API-mu sendiri. Punya side project dengan REST API? Bungkus tiga endpoint-nya jadi MCP server seperti contoh di artikel ini. Begitu satu server jalan, semua aplikasi AI yang kompatibel langsung bisa memakainya — dan di situlah keajaiban N + M benar-benar terasa.

AI yang hanya bisa menjawab pertanyaan adalah masa lalu. AI yang bisa bertindak di dunia nyata — membaca database, mengelola CMS, mengeksekusi workflow — adalah masa kini, dan MCP adalah bahasa standarnya. Pertanyaannya bukan lagi apakah kamu akan menggunakannya, melainkan kapan kamu mulai membangun di atasnya.

Artikel ini ditulis untuk blog teknologi Vechcode. Fakta dan angka merujuk pada kondisi per Oktober 2026; protokol ini berevolusi cepat — selalu verifikasi ke dokumentasi resmi terbaru sebelum mengambil keputusan arsitektural.