Saat menghubungkan agen AI ke tool dan API eksternal, ada dua pendekatan umum: menggunakan Model Context Protocol (MCP) sebagai lapisan abstraksi, atau memanggil API secara langsung melalui HTTP. Keduanya berfungsi. Keduanya membuat trade-off yang berbeda terkait fleksibilitas, kompleksitas, performa, dan portabilitas.
Artikel ini membandingkan kedua pendekatan tersebut dengan contoh kode konkret, analisis latensi, dan kerangka keputusan untuk memilih di antara keduanya.
Dua pendekatan
Integrasi HTTP langsung
Aplikasi AI (atau backend-nya) memanggil API eksternal secara langsung menggunakan request HTTP standar. Developer menulis kode untuk membuat request, menangani autentikasi, mengurai respons, dan memasukkan hasilnya kembali ke LLM.
┌──────┐ ┌────────┐ ┌─────────────┐
│ User │────▶│ AI App │──── HTTP request ─────▶│ Weather API │
└──────┘ │ │◀─── JSON response ─────│ │
│ │ └─────────────┘
│ │── result as context ──▶ LLM
│ │◀── formatted answer ───
└───┬────┘
│
▼
User gets answer
Integrasi MCP
Aplikasi AI terhubung ke server MCP yang membungkus API eksternal. Aplikasi menggunakan protokol MCP untuk menemukan tool yang tersedia, memanggilnya berdasarkan nama, dan menerima hasil. Server MCP menangani panggilan HTTP aktual ke API eksternal.
┌──────┐ ┌───────────────────┐ ┌────────────┐ ┌──────────┐
│ User │────▶│ AI App/MCP Client │── JSON-RPC ─▶│ MCP Server │────▶│ HTTP API │
└──────┘ │ │◀─ JSON-RPC ──│ │◀────│ │
│ │ └────────────┘ └──────────┘
│ │── result as context ──▶ LLM
│ │◀── formatted answer ───
└─────────┬─────────┘
│
▼
User gets answer
Perbedaan utamanya: dengan HTTP langsung, aplikasi AI memiliki kode integrasi API. Dengan MCP, server MCP yang memilikinya, dan aplikasi AI cukup memanggil tool berdasarkan nama.
Anda dapat menggunakan sisi MCP dari diagram ini tanpa membangun server: Quickchat AI meng-host server MCP streamable-HTTP untuk setiap AI Agent, dan mengubah agen Anda menjadi server MCP cukup dengan menempelkan satu URL ke aplikasi AI.
Perbandingan kode
Mari bandingkan kedua pendekatan untuk contoh praktis: mengambil repositori milik pengguna GitHub.
Integrasi HTTP langsung
import httpx
async def get_user_repos(username: str, token: str) -> list[dict]:
"""Ambil repositori untuk pengguna GitHub."""
async with httpx.AsyncClient() as client:
response = await client.get(
f"https://api.github.com/users/{username}/repos",
headers={
"Authorization": f"Bearer {token}",
"Accept": "application/vnd.github.v3+json",
"X-GitHub-Api-Version": "2022-11-28"
},
params={"sort": "updated", "per_page": 10}
)
response.raise_for_status()
repos = response.json()
return [
{
"name": r["name"],
"description": r["description"],
"stars": r["stargazers_count"],
"language": r["language"],
"url": r["html_url"]
}
for r in repos
]
Untuk mengintegrasikan ini dengan LLM, Anda juga memerlukan:
- Definisi tool dalam format apa pun yang diharapkan LLM (skema OpenAI function calling, skema Claude tool use, dan sebagainya)
- Kode untuk mengurai pemanggilan tool dari LLM, menjalankan
get_user_repos, dan menyisipkan hasilnya kembali ke percakapan - Penanganan error untuk kegagalan HTTP, rate limit, dan kedaluwarsa autentikasi
Server MCP
from mcp.server.fastmcp import FastMCP
import httpx
mcp = FastMCP("github-server")
GITHUB_TOKEN = os.environ["GITHUB_TOKEN"]
@mcp.tool()
async def get_user_repos(username: str) -> str:
"""Ambil 10 repositori yang paling baru diperbarui untuk pengguna GitHub.
Args:
username: Nama pengguna GitHub yang akan dicari
"""
async with httpx.AsyncClient() as client:
response = await client.get(
f"https://api.github.com/users/{username}/repos",
headers={
"Authorization": f"Bearer {GITHUB_TOKEN}",
"Accept": "application/vnd.github.v3+json",
"X-GitHub-Api-Version": "2022-11-28"
},
params={"sort": "updated", "per_page": 10}
)
response.raise_for_status()
repos = response.json()
lines = []
for r in repos:
stars = r["stargazers_count"]
lang = r["language"] or "tidak diketahui"
lines.append(f"- {r['name']} ({lang}, {stars} bintang): {r['description'] or 'Tidak ada deskripsi'}")
return "\n".join(lines)
if __name__ == "__main__":
mcp.run(transport="stdio")
Versi MCP merangkum panggilan API, autentikasi, dan pemformatan respons di dalam server. Klien apa pun yang kompatibel dengan MCP dapat menggunakan tool ini tanpa mengetahui apa pun tentang GitHub API.
Apa yang berubah untuk aplikasi AI
| Aspek | HTTP langsung | MCP |
|---|---|---|
| Definisi tool | Ditulis dalam format native LLM (skema OpenAI, dll.) | Dibuat otomatis dari server MCP |
| Autentikasi | Dikelola oleh aplikasi AI | Dikelola oleh server MCP |
| Penguraian respons | Aplikasi AI mengekstrak dan memformat data | Server MCP mengembalikan hasil yang sudah diformat |
| Penanganan error | Aplikasi AI menangani error HTTP | Server MCP menangani error, mengembalikan pesan error terstruktur |
| Menambahkan tool baru | Menulis kode baru di aplikasi AI | Terhubung ke server MCP baru (atau menambahkan tool ke server yang ada) |
| Mengganti LLM | Menulis ulang definisi tool untuk format LLM baru | Tidak perlu perubahan |
Perbandingan performa
MCP menambahkan satu lapisan antara aplikasi AI dan API eksternal. Lapisan tersebut memiliki biaya.
Latensi
Untuk stdio transport (server MCP lokal), overhead-nya minimal: pembuatan proses saat startup (sekali saja, biasanya di bawah 100ms) dan komunikasi antarproses per pesan (sub-milidetik pada sistem modern). Dalam praktiknya, panggilan API eksternal mendominasi total latensi.
Untuk server MCP remote (Streamable HTTP atau SSE), Anda menambahkan satu HTTP round-trip antara klien dan server MCP, ditambah HTTP round-trip dari server MCP ke API eksternal. Jika server MCP dan API eksternal berada di lokasi yang sama, overhead ini kecil (beberapa milidetik). Jika berada di region yang berbeda, overhead bertambah. Namun, transport jarang menjadi bagian yang dirasakan pengguna: saat membangun agen help center di server MCP yang di-host Notion, 248 pemanggilan tool memiliki rata-rata 2,7 detik per panggilan, hampir semuanya untuk pencarian Notion dan rendering halaman, bukan hop di antaranya.
| Setup | Perkiraan latensi tambahan |
|---|---|
| Server MCP lokal (stdio) | < 1ms per pemanggilan tool |
| Server MCP remote (region yang sama dengan API) | 1-5ms per pemanggilan tool |
| Server MCP remote (region berbeda dari API) | 10-50ms per pemanggilan tool |
Untuk sebagian besar kasus penggunaan agen AI, saat inferensi LLM memakan waktu 500ms-5s, overhead MCP dapat diabaikan.
Manajemen koneksi
HTTP langsung: Aplikasi Anda mengelola koneksi ke setiap API eksternal. Ini berarti menangani connection pool, logika retry, dan rate limiting per API.
MCP: Aplikasi Anda mengelola satu koneksi per server MCP. Server mengelola koneksi API eksternal. Jika Anda memiliki 10 tool yang tersebar di 3 server MCP, Anda mengelola 3 koneksi, bukan 10.
Kapan menggunakan MCP
Banyak integrasi tool
Jika aplikasi AI Anda perlu terhubung ke 5+ layanan eksternal, MCP mengurangi beban integrasi. Alih-alih menulis dan memelihara klien API kustom untuk setiap layanan, Anda terhubung ke server MCP (banyak di antaranya tersedia sebagai proyek open-source).
Portabilitas lintas platform AI
Jika Anda membangun server MCP untuk tool Anda, server tersebut berfungsi dengan klien MCP apa pun: Claude Desktop, Cursor, Windsurf, aplikasi kustom, dan platform seperti Quickchat AI. Dengan HTTP langsung, Anda perlu mengimplementasikan ulang definisi tool untuk format setiap platform.
Penemuan tool dinamis
MCP mendukung penemuan tool saat runtime melalui tools/list. Aplikasi AI dapat terhubung ke server dan mengetahui tool apa yang tersedia tanpa konfigurasi hardcoded. Ini berguna untuk skenario saat tool sering berubah atau dapat dikonfigurasi oleh pengguna.
Pemisahan tanggung jawab
Jika tim yang berbeda memiliki tool yang berbeda, MCP menyediakan batas yang jelas. Tim yang memiliki integrasi Salesforce membangun dan memelihara server MCP Salesforce. Tim aplikasi AI terhubung ke server tersebut tanpa perlu memahami API Salesforce. Pembaruan pada API Salesforce ditangani di server MCP tanpa menyentuh aplikasi AI.
Kapan menggunakan HTTP langsung
Satu atau dua integrasi
Jika agen AI Anda hanya perlu memanggil satu API (misalnya, pencarian database), overhead menjalankan server MCP tidak diperlukan. Panggilan HTTP langsung lebih sederhana dan memiliki lebih sedikit komponen bergerak.
Anda juga tidak perlu menulis request secara manual. Builder API Action dengan bahasa biasa membaca REST API yang terdokumentasi, menghasilkan method, URL, parameter, dan deskripsi, lalu memungkinkan Anda menguji respons nyata sebelum mengaktifkannya.
Kontrol maksimum atas request
Server MCP mengabstraksikan detail HTTP. Jika Anda memerlukan kontrol presisi atas pembuatan request (header tertentu, parameter query, penandatanganan request, atau autentikasi non-standar), HTTP langsung memberi Anda kontrol tersebut tanpa harus berhadapan dengan lapisan abstraksi.
Operasi yang sensitif terhadap latensi
Jika setiap milidetik penting (misalnya, agen suara real-time yang pemanggilan tool-nya harus selesai dalam batas waktu ketat), menghapus lapisan MCP menghilangkan satu hop.
Panggilan HTTP non-AI
Jika panggilan HTTP tidak dipicu oleh agen AI (misalnya, cron job backend yang menyinkronkan data), MCP tidak relevan. MCP dirancang khusus untuk komunikasi AI-ke-tool. Layanan backend biasa sebaiknya menggunakan klien HTTP biasa.
Pendekatan hybrid
Banyak sistem produksi menggunakan keduanya. Polanya:
- MCP untuk integrasi tool yang dipanggil agen AI selama percakapan (pencarian CRM, pembuatan tiket, query knowledge base)
- HTTP langsung untuk operasi backend internal, webhook, dan komunikasi system-to-system
Beginilah cara kerja internal Quickchat AI. Platform ini mendukung HTTP Request Actions (panggilan API langsung dengan templating parameter) dan Remote MCP Actions (koneksi ke server MCP eksternal). Anda memilih pendekatan yang tepat untuk setiap integrasi:
| Jenis integrasi | Pendekatan yang direkomendasikan |
|---|---|
| Panggilan API sederhana dengan parameter yang diketahui | HTTP Request Action |
| Integrasi kompleks dengan beberapa tool terkait | Remote MCP Action |
| Layanan pihak ketiga dengan server MCP yang sudah ada | Remote MCP Action |
| API internal dengan autentikasi kustom | HTTP Request Action |
| Tool yang dapat dikonfigurasi pengguna | Remote MCP Action |
Untuk perbandingan mendetail tentang cara kerjanya dalam praktik, termasuk perbedaan antara GPT Actions dari OpenAI dan MCP, lihat GPT Actions vs MCP.
Kerangka keputusan
Gunakan flowchart ini untuk memilih:
- Apakah agen AI memanggil tool? Jika tidak (ini operasi backend), gunakan HTTP langsung.
- Berapa banyak tool eksternal yang Anda perlukan? Jika 1-2, HTTP langsung lebih sederhana. Jika 3+, pertimbangkan MCP.
- Apakah server MCP siap pakai tersedia untuk layanan tersebut? Jika ya, menggunakannya menghemat waktu pengembangan.
- Apakah Anda membutuhkan integrasi yang berfungsi di beberapa platform AI? Jika ya, MCP menyediakan portabilitas.
- Apakah latensi kritis (anggaran sub-100ms untuk pemanggilan tool)? Jika ya, benchmark overhead MCP dan putuskan berdasarkan hasilnya.
- Apakah tim yang berbeda memiliki integrasi yang berbeda? Jika ya, model satu server per integrasi milik MCP membantu membatasi kepemilikan.
Dalam praktiknya, jika Anda membangun agen AI yang perlu berinteraksi dengan layanan eksternal, MCP semakin menjadi pilihan default. Ekosistem server siap pakai sudah cukup besar sehingga Anda sering dapat mulai tanpa menulis kode server sama sekali.
Bacaan lanjutan
- Hubungkan AI Agent Anda ke Remote MCP Server: Berikan tool live kepada agen Anda, langkah demi langkah
- Cara kerja Model Context Protocol. MCP Dijelaskan: Pengantar MCP
- GPT Actions vs MCP: Perbandingan dengan pendekatan OpenAI
- Spesifikasi MCP: Spesifikasi protokol resmi
- HubSpot AI Actions: Contoh AI actions berbasis HTTP dalam praktik
- Insiden OpenAI Hugging Face, apa yang sebenarnya terjadi: Insiden dijelaskan langkah demi langkah, dan apa arti hacking sebenarnya