Dua tahun lalu, menghubungkan asisten AI ke tool Anda berarti menulis integrasi khusus per model per tool: satu lapisan perekat untuk Claude dan database Anda, satu lagi untuk ChatGPT dan database yang sama, yang ketiga saat model berikutnya datang. Model Context Protocol — MCP, di-open-source Anthropic pada November 2024 — ada untuk membunuh matriks N-kali-M itu.
MCP sejak itu menjadi standar de facto, didukung Claude, ChatGPT, VS Code, Cursor, dan deretan panjang framework agent. Saya memakai server MCP setiap hari di Claude Code, termasuk yang saya tulis sendiri untuk mengekspos data monitoring dan infrastruktur kami. Tulisan ini menjelaskan protokolnya dari dasar: arsitektur, tiga primitif, dan jawaban jujur untuk pertanyaan yang paling sering saya terima — perlukah kami membangun server sendiri?
Apa Itu MCP
Dokumentasi resminya menggambarkan MCP sebagai port USB-C untuk aplikasi AI, dan analoginya tepat: konektor terstandar supaya aplikasi AI mana pun bisa bicara dengan sistem eksternal mana pun tanpa pengkabelan khusus. Alih-alih setiap tim mengimplementasikan ulang tool calling untuk database, kalender, atau issue tracker mereka terhadap API tiap vendor model, sistemnya mengekspos dirinya sekali sebagai server MCP, dan setiap aplikasi yang mendukung MCP bisa memakainya.
Nuansa pentingnya: MCP tidak menggantikan API tool-calling penyedia model Anda — ia menstandarkan lapisan di belakangnya. Model tetap mengeluarkan panggilan tool; MCP menstandarkan bagaimana kapabilitas itu ditemukan, dideskripsikan, dan dipanggil lintas aplikasi. Build once, integrate everywhere adalah seluruh pitch-nya.
Server, Client, Host: Arsitekturnya
Tiga peran, dan namanya lebih mudah dicerna kalau dilihat dalam satu diagram. Host adalah aplikasi AI-nya — Claude Desktop, IDE, atau produk Anda sendiri. Host menjalankan satu MCP client per koneksi, dan tiap client bicara dengan tepat satu server MCP, lokal lewat stdio atau remote lewat Streamable HTTP:
┌──────────────────────────────┐
│ Host (Claude, IDE, your app)│
│ ┌────────────┐ ┌──────────┐ │ one client per server
│ │ MCP client │ │MCP client│ │
│ └─────┬──────┘ └────┬─────┘ │
└────────┼─────────────┼───────┘
│ stdio │ Streamable HTTP
▼ ▼
┌────────────┐ ┌──────────────┐
│ MCP server │ │ MCP server │
│ (local: │ │ (remote: │
│ files, │ │ GitHub, │
│ postgres) │ │ Linear, …) │
└────────────┘ └──────────────┘
tools · resources · promptsTools
Fungsi yang bisa dipanggil model: query database, membuat tiket, mengirim pesan. Masing-masing membawa nama, deskripsi, dan JSON Schema untuk input. Ini primitif yang paling sering Anda pakai.
Resources
Konteks read-only yang bisa dimuat aplikasi: file, skema tabel, dokumen. Resource dialamatkan lewat URI dan dimaksudkan untuk menghidrasi konteks, bukan mengambil aksi.
Prompts
Template prompt parametrik yang bisa dipakai ulang dan dikirim server, memunculkan workflow domain — misalnya template review-insiden-ini dari tooling insiden Anda.
Mengapa Ini Penting dalam Praktik
Keuntungan praktisnya muncul cepat. Efek ekosistem yang paling besar: sudah ada server siap pakai untuk GitHub, Slack, Postgres, Google Drive, dan ratusan sistem lain, sehingga sebagian besar kapabilitas agent kini berupa konfigurasi, bukan kode. Saat saya ingin Claude Code memeriksa database produksi atau membaca dashboard Grafana kami, saya menambahkan satu entri server ke file konfigurasi — tanpa kerja integrasi SDK sama sekali.
Keuntungan kedua sifatnya organisasional: permukaan integrasi menjadi kontrak. Tim pemilik ERP bisa merilis dan memversikan server MCP untuknya, dan setiap inisiatif AI di perusahaan mengonsumsi server yang sama — auth sama, audit log sama, operasi yang diizinkan sama — alih-alih lima tim menulis lima lapisan perekat berbeda terhadap API mentahnya.
Kapan Anda Perlu Membangun Server Sendiri?
Tabel keputusan jujurnya, berdasarkan server yang pernah saya bangun dan yang saya sesali:
| Situasi | Putusan |
|---|---|
| Server MCP publik sudah ada untuk sistemnya (GitHub, Postgres, Slack...) | Pakai itu — tulis nol kode |
| Sistem internal ber-API yang akan dibutuhkan beberapa use case AI | Bangun server — balik modal sejak konsumen kedua |
| Otomasi sekali-pakai di dalam satu aplikasi yang Anda kendalikan penuh | Lewati MCP — definisi tool biasa di agent loop sendiri lebih sederhana |
| Anda ingin non-engineer memakai data internal dengan aman dari Claude | Bangun server — dengan tool ter-scope dan mayoritas read-only |
| Mengekspos mutasi berbahaya (pembayaran, penghapusan) ke model mana pun | Tahan dulu — rancang model izinnya, baru bangun sesempit mungkin |
Server Pertama Anda Lebih Kecil dari Dugaan
Server MCP yang berguna itu kodenya sedikit sekali. Dengan SDK TypeScript resmi, satu tool nyata — nama, deskripsi, skema, handler — muat dalam satu layar:
// A minimal MCP server with the official TypeScript SDK
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: "erp-tools", version: "1.0.0" })
server.tool(
"get_stock_level",
"Look up current warehouse stock for a SKU. Call this for any availability question.",
{ sku: z.string().describe("Product SKU, e.g. BRG-0042") },
async ({ sku }) => {
const row = await db.query("SELECT qty FROM stock WHERE sku = $1", [sku])
return { content: [{ type: "text", text: String(row?.qty ?? "SKU not found") }] }
},
)
await server.connect(new StdioServerTransport())Jalankan lewat stdio untuk pengembangan lokal, dan naik kelas ke Streamable HTTP di belakang reverse proxy biasa saat orang lain membutuhkannya. Keterampilan dari panduan pengembangan server MCP saya di blog ini berlaku langsung; versi singkatnya: deskripsi tool layak mendapat perhatian yang sama dengan copy untuk pengguna, karena ia efektif adalah prompt.
Perlakukan setiap server MCP sebagai API gateway dengan client yang sangat kreatif. Scope kredensialnya ke minimum yang dibutuhkan tool, utamakan user database read-only, catat setiap pemanggilan, dan wajibkan alur persetujuan di host untuk apa pun yang ireversibel. Protokol menstandarkan konektivitas — ia tidak membebaskan Anda dari desain otorisasi, itulah kenapa saya menulis terpisah soal menaruh Cerbos di depan auth MCP.
Kesimpulan
MCP mengubah bagian paling berantakan dari membangun dengan LLM — menghubungkannya ke sistem nyata — menjadi antarmuka komoditas. Pelajari tiga primitifnya, pakai ulang server publik di mana pun ada, dan bangun sendiri hanya saat sistem internal akan melayani lebih dari satu konsumen AI. Saat Anda membangun, engineering-nya bagian mudah; kerja yang awet adalah merancang tool dan izin yang nyaman Anda serahkan ke sebuah model.
Sumber dan bacaan lanjutan