Panduan Lengkap MCP: Model Context Protocol untuk AI Agent
Panduan lengkap Model Context Protocol (MCP): arsitektur client-server, tiga primitif inti, transport, keamanan, dan tutorial membangun server MCP pertama dengan TypeScript.
Panji Ihsanudin Fajri
15 min read0 reads

Contents
- Apa itu Model Context Protocol (MCP)?
- Kenapa MCP penting untuk AI agent
- Cara kerja MCP: arsitektur client-server
- Tiga peran: Host, Client, Server
- Dua lapisan: data dan transport
- Tiga primitif inti: Tools, Resources, Prompts
- Tools: fungsi yang bisa dipanggil model
- Resources: data untuk konteks
- Prompts: template interaksi siap pakai
- Transport: stdio vs Streamable HTTP
- Tutorial: membangun server MCP pertamamu
- 1. Siapkan proyek
- 2. Tulis server
- 3. Build dan uji dengan MCP Inspector
- 4. Hubungkan ke host
- Alur pesan: dari discovery sampai tools/call
- Keamanan MCP yang perlu kamu tahu
- MCP vs integrasi custom: kapan memakai apa
- Kesalahan umum dan cara menghindarinya
- Best practice membangun server MCP
- FAQ
- Apakah MCP hanya bisa dipakai dengan Claude?
- Apakah MCP menggantikan function calling?
- Transport mana yang harus saya pilih: stdio atau Streamable HTTP?
- Apakah data saya aman saat memakai server MCP?
- Seberapa sulit membuat server MCP sendiri?
- Kesimpulan
Model AI seperti Claude atau ChatGPT makin pintar setiap tahun, tapi ada satu batasan yang tidak bisa diatasi hanya dengan model yang lebih besar: mereka tidak tahu isi database kamu, tidak bisa membaca file di laptopmu, dan tidak bisa menekan tombol di aplikasimu. Model Context Protocol (MCP) adalah jawaban standar untuk masalah ini — protokol terbuka yang diperkenalkan Anthropic untuk memberi aplikasi AI satu cara yang sama dalam terhubung ke data dan tools, apa pun model atau aplikasinya.
Artikel ini membahas MCP dari nol sampai bisa praktik: apa itu MCP dan kenapa ia penting untuk AI agent, cara kerja arsitektur client-server-nya, tiga primitif inti (tools, resources, prompts), pilihan transport, sampai tutorial membangun server MCP pertamamu dengan TypeScript. Semua fakta teknis di artikel ini merujuk pada dokumentasi resmi di modelcontextprotocol.io dan spesifikasi protokol versi 2026-07-28.
Ringkasan: MCP adalah standar terbuka (diperkenalkan Anthropic, November 2024) yang menstandarkan cara aplikasi AI terhubung ke data dan tools — seperti USB-C untuk AI. Satu MCP host menjalankan satu MCP client per MCP server; server mengekspos tools, resources, dan prompts lewat pesan JSON-RPC 2.0. Ada dua transport: stdio untuk server lokal dan Streamable HTTP untuk server remote. Kamu bisa membangun server MCP sendiri dengan SDK resmi dalam puluhan baris kode.

Apa itu Model Context Protocol (MCP)?
Model Context Protocol (MCP) adalah standar terbuka untuk menghubungkan aplikasi AI ke sistem eksternal seperti sumber data, tools, dan workflow. Dengan MCP, asisten AI tidak hanya menjawab dari pengetahuannya, tetapi bisa membaca file lokalmu, mengquery database, memanggil API, dan menjalankan aksi — semuanya lewat satu protokol yang sama.
MCP diperkenalkan dan di-open source-kan oleh Anthropic pada 25 November 2024. Pada 9 Desember 2025, Anthropic mendonasikan MCP ke Agentic AI Foundation di bawah Linux Foundation — yayasan yang didirikan bersama Block dan OpenAI — sehingga MCP kini menjadi protokol netral-vendor, bukan milik satu perusahaan.
Dokumentasi resminya memakai analogi yang tepat: MCP adalah port USB-C untuk aplikasi AI. Sama seperti USB-C memberi satu cara standar untuk menghubungkan perangkat elektronik, MCP memberi satu cara standar untuk menghubungkan aplikasi AI ke sistem eksternal. Vendor yang membangun satu MCP server tidak perlu membangun ulang integrasinya untuk setiap asisten AI — bangun sekali, dipakai di mana saja.
Kenapa MCP penting untuk AI agent
AI agent yang berguna bukan sekadar model yang pintar merangkai kata. Agent harus bisa bertindak: membaca konteks yang relevan, memanggil fungsi yang tepat, dan mengeksekusi langkah berurutan sampai tugas selesai. Tanpa cara standar untuk mengakses dunia luar, setiap kemampuan baru berarti integrasi custom baru.
Sebelum MCP, situasinya adalah masalah N×M. Setiap aplikasi AI yang ingin bicara dengan database, kalender, atau issue tracker membangun konektornya sendiri — dan setiap konektor harus dibangun ulang untuk setiap aplikasi AI. Anthropic membangun tool use dengan formatnya sendiri, OpenAI membangun function calling dengan format berbeda, Google dengan formatnya sendiri lagi. Hasilnya: pekerjaan integrasi yang sama dikerjakan berulang-ulang.
MCP meruntuhkan masalah itu menjadi N+M: setiap aplikasi AI cukup bicara MCP, setiap tools cukup mengekspos MCP server, dan keduanya bisa saling menemukan. Menurut angka yang dilaporkan Anthropic pada Desember 2025, sudah ada lebih dari 10.000 MCP server publik, dan protokol ini didukung di Claude, ChatGPT, Visual Studio Code, dan Cursor.
Bagi developer, ini berarti waktu integrasi yang jauh lebih singkat. Bagi pengguna, ini berarti asisten AI yang benar-benar bisa menyentuh sistem mereka, bukan sekadar membicarakannya.
Cara kerja MCP: arsitektur client-server
MCP memakai arsitektur client-server yang sederhana, dengan tiga peran yang jelas. Memahami tiga peran ini adalah kunci untuk memahami seluruh protokol.
Tiga peran: Host, Client, Server
- MCP Host adalah aplikasi AI yang kamu pakai — misalnya Claude Desktop, Claude Code, ChatGPT, atau VS Code. Host menjalankan model, mengatur percakapan, dan mengoordinasikan satu atau banyak MCP client.
- MCP Client adalah konektor di dalam host yang bicara dengan satu MCP server. Satu host membuat satu client untuk setiap server yang ia hubungi, dan setiap client menjaga koneksi khusus ke servernya masing-masing.
- MCP Server adalah program yang menyediakan konteks ke client. Server bisa berjalan lokal di mesin yang sama (misalnya server filesystem) atau remote di infrastruktur penyedia (misalnya server Sentry resmi yang berjalan di platform Sentry).

Satu detail penting: istilah "server" di sini merujuk pada program yang melayani data konteks, bukan pada mesin fisik. Server lokal yang memakai transport stdio biasanya melayani satu client, sedangkan server remote yang memakai Streamable HTTP bisa melayani banyak client sekaligus.
Agar model memilih tool yang tepat dari daftar yang disediakan server, deskripsi tool harus ditulis dengan jelas — di sinilah kualitas instruksi berperan besar, dan teknik prompt engineering yang tepat membuat perbedaan nyata pada keandalan agent.
Dua lapisan: data dan transport
Protokol MCP terdiri dari dua lapisan. Lapisan data adalah lapisan dalam: protokol pertukaran berbasis JSON-RPC 2.0 yang mendefinisikan struktur dan makna pesan — termasuk discovery, kapabilitas, dan primitif inti seperti tools, resources, dan prompts. Lapisan transport adalah lapisan luar: mekanisme komunikasi yang mengatur pembentukan koneksi, framing pesan, dan autentikasi.
Sejak spesifikasi versi 2026-07-28, inti protokol bersifat stateless: setiap request membawa versi protokol dan metadata yang relevan di field _meta, sehingga server bisa memproses setiap request secara mandiri tanpa sesi. Client menemukan kemampuan server lewat request server/discover sebelum melakukan hal lain. Perubahan ini menyederhanakan deployment server, terutama untuk server remote yang harus melayani banyak client.
Tiga primitif inti: Tools, Resources, Prompts
Primitif adalah konsep terpenting di MCP. Primitif mendefinisikan jenis informasi kontekstual apa yang bisa dibagikan ke aplikasi AI dan aksi apa yang bisa dilakukan. Ada tiga primitif inti yang bisa diekspos oleh server:
Tools: fungsi yang bisa dipanggil model
Tools adalah fungsi executable yang bisa dipanggil aplikasi AI untuk melakukan aksi — operasi file, panggilan API, query database. Client menemukan tools lewat tools/list, lalu mengeksekusinya lewat tools/call. Tools adalah primitif yang paling sering dipakai, karena di sinilah "agent bisa bertindak" menjadi nyata. Panggilan tool umumnya butuh persetujuan pengguna, terutama untuk aksi yang mengubah state.
Resources: data untuk konteks
Resources adalah sumber data yang memberi informasi kontekstual ke aplikasi AI — isi file, record database, respons API. Client menemukannya lewat resources/list dan membaca isinya lewat resources/read. Bedanya dengan tools: resources bersifat pasif (dibaca, bukan dieksekusi) dan biasanya dikontrol aplikasinya — model tidak memutuskan sendiri kapan mengambil resource, aplikasi yang menyediakannya sebagai konteks.
Prompts: template interaksi siap pakai
Prompts adalah template yang bisa dipakai ulang untuk menyusun interaksi dengan model — misalnya system prompt khusus atau contoh few-shot untuk memakai tools tertentu. Client menemukannya lewat prompts/list dan mengambilnya lewat prompts/get. Primitif ini berguna untuk membakukan alur kerja: alih-alih setiap pengguna merangkai instruksi dari nol, server menyediakan template yang sudah teruji. Konsepnya sejalan dengan praktik menyusun instruksi sistem yang baik seperti dibahas di panduan prompt engineering.

| Primitif | Arah utama | Metode | Contoh |
|---|---|---|---|
| Tools | Model memanggil server | tools/list, tools/call |
get_forecast, create_issue |
| Resources | Server menyediakan data | resources/list, resources/read |
Skema database, isi file |
| Prompts | Server menyediakan template | prompts/list, prompts/get |
Template review kode |
Selain primitif server, protokol juga mendefinisikan primitif sisi client. Elicitation memungkinkan server meminta input tambahan dari pengguna — misalnya konfirmasi sebelum menjalankan aksi sensitif. Catatan: primitif sampling (server meminta komplesi model lewat client) sudah deprecated sejak versi 2026-07-28; implementasi baru disarankan berintegrasi langsung dengan API penyedia LLM.
Transport: stdio vs Streamable HTTP
MCP mendukung dua mekanisme transport, dan memilih yang tepat tergantung di mana server berjalan:
| Aspek | Stdio | Streamable HTTP |
|---|---|---|
| Cara kerja | Komunikasi proses lokal via stdin/stdout | HTTP POST client-ke-server, opsional Server-Sent Events untuk streaming |
| Kegunaan | Server lokal di mesin yang sama | Server remote yang melayani banyak client |
| Overhead | Minimal, tanpa jaringan | Overhead HTTP standar |
| Autentikasi | Tidak relevan (proses lokal) | Bearer token, API key, header custom; OAuth direkomendasikan |
Aturan praktisnya sederhana: kalau server mengakses sesuatu yang hanya ada di mesin pengguna (file lokal, CLI, database lokal), pakai stdio dan biarkan host menjalankan server sebagai subprocess. Kalau server adalah layanan bersama — misalnya integrasi SaaS resmi — pakai Streamable HTTP dan amankan dengan OAuth.
Satu aturan keras untuk server stdio: jangan pernah menulis ke stdout. Stdout adalah jalur pesan JSON-RPC, sehingga console.log() atau print() akan merusak pesan dan menghancurkan server. Untuk logging di server stdio, tulis ke stderr (console.error() di Node.js, modul logging di Python).
Tutorial: membangun server MCP pertamamu
Bagian ini mengikuti alur tutorial resmi membangun server MCP. Kita akan membuat server cuaca sederhana dengan TypeScript yang mengekspos satu tool, lalu menghubungkannya ke host.
1. Siapkan proyek
Butuh Node.js 20 ke atas. Buat folder proyek, inisialisasi npm, dan instal SDK resmi:
mkdir weather-server && cd weather-server
npm init -y
npm install @modelcontextprotocol/sdk zod
Tambahkan "type": "module" di package.json dan siapkan tsconfig.json standar untuk proyek ESM.
2. Tulis server
Buat src/index.ts. SDK menyediakan class McpServer tingkat tinggi — deskripsi dan skema input yang kamu tulis otomatis menjadi definisi tool yang dibaca model:
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: "weather-server",
version: "1.0.0",
});
server.registerTool(
"get_forecast",
{
description: "Get the weather forecast for a city",
inputSchema: {
city: z.string().describe("City name, e.g. Jakarta"),
},
},
async ({ city }) => {
// Ganti dengan panggilan ke API cuaca sungguhan
const forecast = { city, condition: "sunny", tempC: 29 };
return {
content: [{ type: "text", text: JSON.stringify(forecast) }],
};
},
);
const transport = new StdioServerTransport();
await server.connect(transport);
Perhatikan tiga hal: nama tool memakai snake_case yang deskriptif, description menjelaskan kapan tool dipakai (model membaca ini untuk memutuskan), dan skema input memakai Zod sehingga validasi argumen otomatis. Jangan gunakan console.log() di mana pun — pakai console.error() untuk debug.
3. Build dan uji dengan MCP Inspector
npm run build
SDK menyediakan MCP Inspector — perkakas resmi untuk menguji server tanpa host. Jalankan Inspector, arahkan ke server stdio-mu, dan panggil tools/list untuk memastikan get_forecast muncul, lalu tools/call untuk mengeksekusinya. Kalau daftar tool kosong, 90% penyebabnya adalah lupa menjalankan build atau salah path.
4. Hubungkan ke host
Untuk Claude Desktop, buka file konfigurasi (~/Library/Application Support/Claude/claude_desktop_config.json di macOS) dan daftarkan server di key mcpServers:
{
"mcpServers": {
"weather": {
"command": "node",
"args": ["/ABSOLUTE/PATH/TO/weather-server/build/index.js"]
}
}
}
Simpan, restart Claude Desktop, dan server akan dijalankan otomatis sebagai subprocess. Sekarang tanyakan "Bagaimana cuaca di Jakarta?" — model akan menemukan get_forecast lewat tools/list, meminta argumen city, mengeksekusinya lewat tools/call, dan menjawab dari hasilnya.
Alur pesan: dari discovery sampai tools/call
Agar konkret, berikut urutan pesan saat model memakai tool dari server. Semua pesan memakai format JSON-RPC 2.0:
- Discovery — client mengirim
server/discoveruntuk mengetahui versi protokol dan kapabilitas server. - Listing — client memanggil
tools/listdan menerima daftar tool beserta skema inputnya. - Keputusan model — model membaca deskripsi tool dan memutuskan tool mana yang cocok untuk permintaan pengguna, lalu menyusun argumennya.
- Eksekusi — client mengirim
tools/call:
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "get_forecast",
"arguments": { "city": "Jakarta" }
}
}
- Hasil — server mengembalikan hasil, host meneruskannya ke model, dan model menyusun jawaban akhir untuk pengguna.
Pola yang sama berlaku untuk resources (resources/list lalu resources/read) dan prompts (prompts/list lalu prompts/get). Karena setiap request mandiri (stateless), server tidak perlu menyimpan sesi antar request — ini yang membuat MCP server mudah di-scale secara horizontal.

Keamanan MCP yang perlu kamu tahu
Standar terbuka tidak otomatis berarti aman — keamanan MCP ada di tangan pembuat server dan host. Praktik terbaik dari dokumentasi keamanan resmi:
- Persetujuan pengguna untuk tool call. Host yang baik selalu meminta konfirmasi sebelum tool yang mengubah state dijalankan. Jangan membangun client yang mengeksekusi tool destruktif secara diam-diam.
- Prinsip least privilege. Server filesystem misalnya harus dibatasi ke direktori tertentu, bukan seluruh disk. Setiap tool hanya boleh bisa melakukan tepat apa yang dideskripsikannya.
- Autentikasi untuk server remote. Transport Streamable HTTP mendukung bearer token, API key, dan header custom — dokumentasi resmi merekomendasikan OAuth untuk mendapatkan token autentikasi.
- Validasi input di server. Jangan percaya argumen dari model begitu saja; validasi tipe, rentang, dan format sebelum dieksekusi — skema Zod di contoh di atas adalah garis pertahanan pertama, bukan satu-satunya.
- Pisahkan kredensial dari kode. API key untuk layanan yang dibungkus server harus dibaca dari environment variable, bukan di-hardcode.
Ancaman terbesar justru non-teknis: server MCP pihak ketiga yang terlihat meyakinkan bisa mengekspos tool berbahaya. Instal server hanya dari sumber yang kamu percaya, dan periksa daftar tool yang diekspos sebelum memberi akses ke data sensitif.
MCP vs integrasi custom: kapan memakai apa
| Aspek | MCP | Integrasi custom per aplikasi |
|---|---|---|
| Upaya bangun | Sekali, dipakai semua host | Berulang untuk setiap aplikasi AI |
| Discovery | Otomatis via */list |
Dokumentasi manual per integrasi |
| Transport | Standar (stdio / Streamable HTTP) | Bebas, tapi tidak interoperabel |
| Kontrol | Penuh di tangan pembuat server | Penuh, tapi terkunci ke satu aplikasi |
| Cocok untuk | Tools/data yang dipakai banyak agent | Integrasi sangat spesifik satu produk |
MCP bukan pengganti function calling — ia adalah lapisan standar di atasnya. Model tetap memakai mekanisme tool use bawaannya; MCP menstandarkan bagaimana tools ditemukan, dideskripsikan, dan dipanggil lintas aplikasi. Kalau kamu membangun kemampuan yang hanya dipakai satu aplikasi internal dan tidak akan dipakai ulang, integrasi custom masih sah. Tapi untuk apa pun yang berpotensi dipakai lintas agent dan lintas aplikasi, MCP adalah pilihan yang lebih tahan lama.
Kesalahan umum dan cara menghindarinya
- Menulis ke stdout di server stdio.
console.log()untuk debug akan merusak pesan JSON-RPC. Pakaiconsole.error()atau logger yang menulis ke stderr/file. - Deskripsi tool yang kabur. "Get data" tidak memberi tahu model kapan memakai tool. Tulis deskripsi seperti dokumentasi fungsi: kapan dipakai, apa inputnya, apa yang dikembalikan.
- Tool bloat. Mengekspos 50 tool membuat model bingung memilih dan menghabiskan budget konteks untuk skema. Pecah menjadi beberapa server yang fokus, masing-masing dengan permukaan kecil.
- Mengabaikan autentikasi di server remote. Server Streamable HTTP tanpa auth sama dengan API publik tanpa auth. Terapkan OAuth atau setidaknya API key.
- Masih mengandalkan sampling. Primitif sampling deprecated sejak 2026-07-28 — jangan mendesain alur baru di atasnya; panggil API LLM langsung dari server bila butuh komplesi model.
- Tidak menangani perubahan daftar primitif. Server bisa mengirim notifikasi saat tools berubah; client yang baik berlangganan notifikasi ini alih-alih meng-cache daftar selamanya.
Best practice membangun server MCP
- Desain tool yang atomik. Satu tool melakukan satu hal dengan baik —
get_forecastlebih baik daripadado_weather_stuff. - Tulis deskripsi untuk model, bukan untuk manusia. Model memutuskan pemakaian tool murni dari nama, deskripsi, dan skema. Uji dengan bertanya ke model apakah ia bisa menjelaskan kapan memakai tool-mu.
- Batasi permukaan serangan. Ekspos seminimal mungkin; setiap tool tambahan adalah risiko dan biaya konteks.
- Uji dengan MCP Inspector dulu sebelum menghubungkan ke host — iterasi di Inspector jauh lebih cepat daripada restart aplikasi host.
- Versikan servermu. Cantumkan versi di konstruktor server dan perlakukan perubahan skema sebagai perubahan API: jangan diam-diam mengubah arti argumen.
- Dokumentasikan untuk manusia juga. README yang menjelaskan cara instal, konfigurasi yang dibutuhkan (env var, kredensial), dan contoh pemakaian.
FAQ
Apakah MCP hanya bisa dipakai dengan Claude?
Tidak. MCP adalah standar terbuka yang netral-vendor sejak didonasikan ke Agentic AI Foundation pada Desember 2025. Dokumentasi resmi menyebut dukungan di Claude, ChatGPT, Visual Studio Code, dan Cursor — dan karena spesifikasinya terbuka, siapa pun bisa membangun client atau server yang kompatibel.
Apakah MCP menggantikan function calling?
Tidak — keduanya bekerja di lapisan berbeda. Function calling adalah mekanisme model untuk memanggil fungsi; MCP adalah protokol standar untuk menemukan, mendeskripsikan, dan memanggil fungsi tersebut lintas aplikasi. MCP membuat definisi tool yang kamu tulis sekali bisa dipakai oleh banyak model dan aplikasi.
Transport mana yang harus saya pilih: stdio atau Streamable HTTP?
Pakai stdio untuk server lokal yang berjalan di mesin pengguna sebagai subprocess (akses file lokal, CLI, database lokal). Pakai Streamable HTTP untuk server remote yang melayani banyak client dan butuh autentikasi. Keduanya memakai format pesan JSON-RPC 2.0 yang sama.
Apakah data saya aman saat memakai server MCP?
Keamanannya tergantung server yang kamu pasang, bukan protokolnya. Terapkan prinsip least privilege (batasi akses server seminimal mungkin), minta persetujuan sebelum tool destruktif dijalankan, gunakan OAuth untuk server remote, dan instal server hanya dari sumber tepercaya.
Seberapa sulit membuat server MCP sendiri?
Tidak sulit untuk kasus sederhana. SDK resmi tersedia untuk TypeScript, Python, dan bahasa lain; server satu tool seperti contoh di artikel ini hanya puluhan baris kode. Bagian tersulit biasanya bukan protokolnya, melainkan mendesain tool yang deskripsinya cukup jelas untuk dipakai model dengan andal.
Kesimpulan
MCP memecahkan masalah paling membosankan dalam pengembangan AI agent: integrasi yang dibangun berulang-ulang untuk setiap pasangan model dan tools. Dengan tiga peran yang jelas (host, client, server), tiga primitif inti (tools, resources, prompts), dan dua transport standar (stdio, Streamable HTTP), protokol ini memberi satu fondasi netral-vendor — kini di bawah Agentic AI Foundation — untuk menghubungkan AI ke dunia nyata.
Langkah berikutnya yang paling masuk akal: bangun satu server MCP kecil untuk alur kerjamu sendiri — misalnya server yang mengekspos database internal atau CLI favoritmu — lalu uji dengan MCP Inspector. Setelah merasakan betapa sedikit kode yang dibutuhkan, kamu akan melihat kenapa ekosistem ini tumbuh ke lebih dari 10.000 server publik.
Untuk melengkapi kemampuan agent-mu, pelajari juga panduan lengkap prompt engineering: tool yang bagus tetap butuh instruksi yang jelas agar model memakainya dengan tepat. Dan kalau ingin mendalami spesifikasinya langsung, mulai dari pengantar resmi MCP.


