MCP dibongkar ulang: kabar baik buat kamu yang capek nulis konektor

Kamu punya beberapa endpoint internal: satu buat data artikel, satu buat pengguna, satu lagi buat laporan. Lalu ada satu agent AI yang harus bisa mengakses semuanya. Cara paling cepat adalah menulis konektor per pasangan, yaitu satu kode khusus untuk model A dan sumber data X, satu lagi untuk model A dan sumber Y. Awalnya terasa beres. Semua jalan, demo lancar, dan kamu merasa cukup produktif hari itu.

Masalahnya baru kelihatan begitu modelnya diganti. Format tool calling beda, cara mendeskripsikan argumen beda, penanganan error pun beda. Setengah kode konektor tadi mendadak jadi sampah, dan kamu harus mengulang dari awal 😅. Kalau dihitung kasar, lima model dikali sepuluh sumber data berarti lima puluh implementasi yang harus dirawat. Angka itu cuma ilustrasi, tapi rasa sakitnya nyata bagi siapa pun yang pernah menjaga kode perekat.

Nah, di titik inilah Model Context Protocol (MCP) masuk. Ide dasarnya sederhana: daripada setiap model bicara dengan setiap sumber lewat jalur khusus, semuanya bicara lewat satu protokol standar. Sumber data cukup ditulis sekali sebagai server — dan model apa pun yang paham protokolnya bisa memakainya.

Kenapa masalah remeh ini mahal?

Kode perekat itu jarang dianggap pekerjaan serius. Isinya cuma mengubah format, menyalin skema, dan menempelkan kredensial. Tapi justru bagian itu yang paling rapuh, karena setiap perubahan di salah satu ujung memaksa perubahan di ujung lain. Biayanya nggak kelihatan di sprint planning, tapi menumpuk diam-diam sampai satu hari kita sadar separuh waktu habis untuk menambal konektor.

Kalau kamu pernah memakai editor modern, kamu sudah merasakan solusi serupa di dunia lain. Spesifikasi MCP sendiri menyebut bahwa protokol ini mengambil inspirasi dari Language Server Protocol. Dulu setiap editor harus mengimplementasikan dukungan untuk setiap bahasa pemrograman. Setelah ada protokol bersama, satu language server bisa melayani banyak editor. MCP membawa pola yang sama ke dunia agent AI, jadi kamu menulis konektor sekali dan nggak perlu peduli siapa yang memakainya nanti.

Siapa yang ngobrol dengan siapa

Arsitekturnya punya tiga peran. Host adalah aplikasi yang kamu pakai langsung, misalnya aplikasi desktop atau ekstensi editor, dan di dalamnya model AI berjalan. Client adalah komponen di dalam host yang mengurus komunikasi. Server adalah program yang membuka kemampuan atau data, dan di sinilah kode yang kamu tulis nanti berada.

Satu hal yang perlu diingat: satu client berpasangan dengan tepat satu server. Kalau host terhubung ke tiga server, berarti ada tiga client di dalamnya. Pembagian ini bukan kebetulan, karena dari sinilah batas keamanannya terbentuk. Menurut prinsip arsitektur di spec, server nggak boleh bisa membaca seluruh percakapan dan nggak boleh bisa melihat ke dalam server lain. Riwayat percakapan tetap tinggal di host.

Kredensial juga ikut aman. Token database atau kunci API tetap berada di sisi server, jadi nggak pernah ikut masuk ke prompt. Model cuma tahu bahwa ada tool bernama sekian dengan argumen sekian, bukan password di belakangnya. Itu keputusan desain yang menenangkan, kan.

Tiga primitif, dan siapa yang pegang kendali

Server bisa menawarkan tiga jenis hal, dan perbedaannya terletak pada siapa yang memutuskan kapan dipakai.

• Tools dikendalikan model. Model memutuskan sendiri kapan memanggilnya, dan tool biasanya punya efek samping seperti menulis data atau mengirim sesuatu.
• Resources dikendalikan aplikasi. Isinya data yang dibaca lewat URI, dan host yang menentukan apa yang masuk ke konteks.
• Prompts dikendalikan user. Bentuknya template alur kerja yang dipilih manusia secara sadar.

Buat kita yang terbiasa bikin web API, ada padanan yang gampang diingat. Resource itu seperti GET — cuma membaca dan nggak mengubah apa-apa. Tool itu seperti POST, karena bisa mengubah keadaan di dunia luar. Dengan cara pikir ini, memutuskan sebuah fungsi harus jadi resource atau tool biasanya selesai dalam hitungan detik.

Kenapa protokolnya dibongkar ulang

Ini bagian terpenting, jadi yuk kita bahas pelan-pelan. MCP lahir dengan transport stdio untuk aplikasi lokal. Di situ server adalah proses anak yang hidup berdampingan dengan host, dan state itu wajar. Ada koneksi, ada sesi, dan semuanya berjalan di satu mesin.

Masalah muncul ketika server mulai berjalan jauh dari host. State tadi ikut terbawa ke HTTP: urusan sesi, stream yang digantung terus, sampai replay pesan ketika koneksi putus. Tulisan Cloudflare menyebut bahwa kritik utama ke MCP memang koneksi stateful-nya. Bebannya berupa mengatur rute request ke sticky session, menahan stream terbuka, dan memutar ulang pesan. Siapa sih yang senang mengoperasikan itu semua di produksi?

Jawaban dari spesifikasi 2026-07-28 cukup tegas. Handshake initialize dan header Mcp-Session-Id dihapus. Sebagai gantinya, setiap request membawa versi protokol, identitas client, dan capability-nya sendiri. Client yang tetap ingin tahu kemampuan server lebih dulu bisa memanggil server/discover, tapi itu opsional, bukan syarat. Singkatnya, protokolnya sekarang stateless di level protokol.

Beberapa detail baru layak dicatat. Pertama, header Mcp-Method dan Mcp-Name kini wajib ada di request Streamable HTTP. Gateway, rate limiter, atau WAF jadi bisa memutuskan tanpa membedah body JSON, dan itu kabar bagus buat yang mengurus infrastruktur.

Kedua, hasil tools/list dan kawan-kawannya membawa petunjuk cache ttlMs dan cacheScope, dengan urutan yang deterministik. Artinya katalog tool bisa di-cache oleh client dengan aman, tanpa khawatir urutannya berubah-ubah.

Ketiga, ada MRTR (Multi Round-Trip Request). Kalau sebuah tool butuh konfirmasi, server membalas input_required beserta permintaan yang dibutuhkan. Client mengumpulkan jawaban dari user, lalu mengulang pemanggilan aslinya. Dulu urusan server-ke-client seperti ini butuh stream terbuka, sekarang cukup putaran request biasa.

Konsekuensinya besar: server MCP sekarang bisa jadi workload HTTP biasa. Nggak ada sesi yang harus dijaga, dan server bisa jalan di serverless. Menurut Cloudflare, setelah protokolnya stateless, server MCP bisa jalan di Worker dan primitif McpAgent mereka nggak lagi diperlukan. Emang begitu hasilnya kalau state dipindahkan dari koneksi ke request.

Satu catatan supaya nggak salah paham: stateless bukan berarti aplikasimu nggak boleh punya state. Kalau butuh, buat handle eksplisit dari sebuah tool, misalnya pengenal keranjang atau sesi kerja, lalu biarkan model membawanya balik sebagai argumen di panggilan berikutnya. State-nya pindah ke tempat yang kelihatan, bukan hilang.

Yang perlu diwaspadai kalau baca tutorial lama

Banyak tutorial MCP ditulis sebelum perubahan di atas, jadi ada beberapa jebakan yang gampang kita temui. Kalau kamu menemukan contoh yang kelihatan meyakinkan, cek dulu hal-hal ini:

• from mcp.server.fastmcp import FastMCP itu API versi lama. Sekarang yang dipakai from mcp.server import MCPServer, dan import lamanya langsung melempar ModuleNotFoundError.
• Transport HTTP+SSE sudah digantikan Streamable HTTP sejak revisi 2025-03-26. Ia masih hidup demi kompatibilitas, tapi statusnya deprecated.
• Roots, Sampling, dan Logging juga deprecated, dengan masa transisi minimal 12 bulan. Sementara itu ping sudah dihapus dari protokol.

Artikel ini sendiri punya tanggal kedaluwarsa. Revisi spec datang dengan jarak 3 sampai 8 bulan, dengan urutan 2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25, lalu 2026-07-28. Versi yang dipakai di sini adalah 2026-07-28, jadi kalau kamu membaca ini jauh setelahnya, cek versi terbaru sebelum menyalin apa pun.

Server MCP pertama, sedikit baris

Cukup teorinya, sekarang kita lihat kodenya. Server di bawah nih punya satu resource berisi skema tabel dan satu tool pencarian. Isinya sengaja dibuat sederhana, dan fungsi pencariannya cuma mengembalikan teks, bukan query sungguhan.

# server.py
from mcp.server import MCPServer

mcp = MCPServer("Invasikode Database Server")


@mcp.resource("db://articles/schema")
def get_articles_schema() -> str:
    """Skema DDL tabel artikel, buat konteks LLM."""
    return """
    CREATE TABLE articles (
        id SERIAL PRIMARY KEY,
        title VARCHAR(255) NOT NULL,
        slug VARCHAR(255) UNIQUE NOT NULL,
        tags VARCHAR(255),
        status VARCHAR(32) DEFAULT 'draft'
    );
    """


@mcp.tool()
def search_articles_by_keyword(keyword: str, limit: int = 5) -> str:
    """Cari artikel berdasarkan kata kunci judul.

    Args:
        keyword: Kata kunci pencarian.
        limit: Batas maksimum artikel yang dikembalikan.
    """
    return f"Berhasil mengambil {limit} artikel dengan kata kunci '{keyword}'."

Perhatikan apa yang nggak ada di kode tuh. Nggak ada JSON Schema yang ditulis tangan, karena type hint dan docstring sudah otomatis jadi skema. Nggak ada request handler, nggak ada deklarasi capability. Nama, deskripsi, dan skema argumen semuanya diturunkan dari fungsi Python-nya sendiri. Itulah poinnya — kamu menulis fungsi biasa, dan SDK mengurus sisanya. Kode ini sudah dijalankan pada SDK Python mcp 2.0.0, dengan protokol yang dinegosiasikan 2026-07-28, dan tool serta resource-nya terdaftar. Ia belum diuji di server produksi, jadi perlakukan sebagai titik awal. Dokumentasi lengkapnya ada di panduan SDK Python.

Cara menjalankannya gampang kok: simpan sebagai server.py, pasang paketnya, lalu jalankan lewat SDK. Setelah itu kita daftarkan ke host. Di aplikasi desktop, biasanya lewat berkas konfigurasi seperti claude_desktop_config.json, dengan menunjuk perintah yang menjalankan servermu. Di editor, biasanya lewat ekstensi atau pengaturan MCP. Setelah terdaftar, coba tanya agent soal skema tabel artikel deh, lalu lihat apakah ia memakai resource yang baru kamu tulis 🙂.

Kenapa ini penting buat kamu

Keuntungan paling nyata adalah sekali tulis, dipakai di mana-mana. Konektor ke database artikel yang tadi kamu tulis bisa dipakai oleh host mana pun yang mendukung MCP, tanpa perubahan di sisi server. Ganti model nggak lagi berarti nulis ulang konektor, dan itu menyelesaikan masalah di pembuka tadi.

Kredensial juga tetap di sisimu. Server yang menyimpan token dan kunci, model cuma melihat hasil yang sudah kamu izinkan. Dan karena protokolnya kini stateless, men-deploy server MCP nggak lagi butuh trik khusus. Ia bisa diperlakukan seperti layanan HTTP lain yang sudah biasa kamu urus, lengkap dengan load balancer dan autoscaling. Itu perubahan yang sebenarnya menarik buat kamu yang kerja di backend, lho!

Standarisasi dan siapa yang pegang protokolnya

MCP diperkenalkan Anthropic pada 25 November 2024. Pada Desember 2025, protokol ini didonasikan ke Agentic AI Foundation, sebuah dana terarah di bawah Linux Foundation. Pendirinya adalah Anthropic, Block, dan OpenAI, dengan dukungan Google, Microsoft, AWS, Cloudflare, dan Bloomberg. Governance-nya nggak berubah, jadi proses pengambilan keputusan yang sudah berjalan tetap sama.

Soal adopsi, tulisan donasi itu mencatat bahwa per Desember 2025 ada lebih dari 10.000 MCP server publik yang aktif. Protokolnya juga sudah diadopsi ChatGPT, Cursor, Gemini, Microsoft Copilot, dan VS Code. Angka itu cukup menjelaskan kenapa banyak developer memutuskan belajar MCP sekarang, bukan nanti 🚀.

Jadi, kalau endpoint internalmu sudah menunggu ditempelkan ke agent, kamu sudah punya jalan pintasnya. Mulai dari satu fungsi kecil, biarkan type hint jadi skema, dan simpan konektor lima puluh itu sebagai cerita lama. Tinggal pastikan versi spec yang kamu pakai sama dengan yang dipakai host-mu.