"Mengapa saya harus menggunakan MCP padahal layanannya sudah punya API?" adalah pertanyaan yang paling sering kami terima dari developer yang baru pertama kali melihat direktori kami. Ini pertanyaan yang wajar, dan jawabannya cukup singkat: Anda tidak menggunakan MCP sebagai pengganti API. Anda menggunakannya di atas API, khusus untuk jenis pemanggil tertentu.
Pemanggil tersebut adalah model AI. Begitu Anda memahami apa yang dibutuhkan sebuah model yang tidak dibutuhkan oleh program biasa, perbedaan antara MCP dan API tidak lagi terasa samar. Panduan ini akan menjelaskannya melalui contoh konkret, tabel perbandingan, dan kasus-kasus di mana Anda sebaiknya tidak perlu menggunakan MCP sama sekali.
Poin penting
- MCP tidak menggantikan API. Sebagian besar MCP server hanyalah lapisan tipis di atas API yang sudah ada.
- Perbedaannya terletak pada pemanggilnya: API melayani kode yang ditulis oleh developer, sedangkan MCP melayani model yang menemukan tool secara runtime.
- Function calling adalah sisi yang berhadapan dengan model; MCP menstandarisasi cara tool dideskripsikan, ditemukan, dan diakses di berbagai aplikasi.
- Gunakan API secara langsung jika tidak ada model yang mengambil keputusan, gunakan function calling untuk satu fitur di satu aplikasi, dan gunakan MCP jika banyak aplikasi atau agent membutuhkan tool tersebut.
Jawaban singkat dalam satu paragraf
Sebuah API, baik itu REST, GraphQL, atau gRPC, adalah cara satu perangkat lunak meminta perangkat lunak lain untuk melakukan sesuatu. API mengasumsikan bahwa pemanggil sudah tahu endpoint mana yang harus dituju, apa yang harus dikirim, dan bagaimana cara autentikasi, karena seorang developer sudah menulis kode tersebut. MCP adalah sebuah protokol agar aplikasi AI dapat menemukan tool pada saat runtime dan memanggilnya atas nama sebuah model. Sebuah MCP server mempublikasikan daftar tool lengkap dengan deskripsi bahasa manusia yang sederhana dan input schema, model kemudian memilih salah satunya, dan server akan melakukan pemanggilan API yang sebenarnya. Sebagian besar MCP server yang akan Anda temukan di HostedMCP adalah tepat seperti itu: sebuah layer tipis di atas API yang sudah ada sebelumnya.
Contoh konkret: refund di Stripe
Misalkan Anda ingin asisten AI dapat menangani perintah "refund transaksi terakhir untuk pelanggan ini".
Jika hanya menggunakan API, seseorang harus menulis integrasi tersebut untuk si asisten. Mereka harus mendefinisikan function schema yang dipahami oleh model, lengkap dengan nama dan deskripsinya. Mereka juga harus mengelola API key, mencari data pelanggan, menampilkan daftar transaksi, memilih yang terbaru, membuat refund, dan mengubah error code dari Stripe menjadi sesuatu yang bisa ditindaklanjuti oleh model. Setelah itu, semua itu harus di-deploy di dalam satu aplikasi. Ketika tim support menginginkan fitur yang sama di Claude dan tim developer menginginkannya di Cursor, pekerjaan yang sama harus diulang kembali dengan format dan codebase yang berbeda.
Dengan MCP, semua kode penghubung (glue code) tersebut dipindahkan ke dalam satu server. Server ini akan mengumumkan tool seperti list_charges dan create_refund, lengkap dengan deskripsi yang ditulis khusus untuk model. Server ini juga yang menyimpan API key atau token OAuth. Client MCP apa pun, seperti Claude, Cursor, ChatGPT, atau VS Code, dapat terhubung ke server tersebut dan mendapatkan perilaku yang sama. API Stripe tidak berubah sama sekali. Yang berubah adalah siapa yang harus menulis bagian khusus AI tersebut, dan seberapa sering pekerjaan itu dilakukan.
Perbandingan Side by side
| Traditional API | MCP | |
|---|---|---|
| Siapa yang memanggilnya | Kode yang ditulis developer | Model AI, melalui host app |
| Cara pemanggil mengetahui apa yang tersedia | Membaca docs saat build time | Bertanya ke server saat runtime (tools/list) |
| Deskripsi ditulis untuk | Developer | Model: apa fungsi tool tersebut dan kapan harus digunakan |
| Format pesan | Bervariasi: REST, GraphQL, gRPC | JSON-RPC 2.0 untuk setiap server |
| Auth | API keys, OAuth, atau apa pun yang dipilih layanan tersebut | Env vars untuk local server, OAuth 2.1 untuk remote server |
| Cakupan aksi | Segala sesuatu yang diekspos oleh API | Hanya tool yang dipilih untuk ditawarkan oleh server |
| Satu integrasi bekerja di | Satu app | Setiap MCP client |
| Latensi tipikal | Satu network hop | Satu extra hop melalui server |
Ada dua baris yang layak mendapatkan perhatian lebih dari biasanya.
Discovery adalah perbedaan yang sebenarnya. Sebuah program yang memanggil API tidak pernah bertanya "apa yang bisa Anda lakukan?" saat runtime; developer sudah mengetahuinya. Sebuah model perlu bertanya, di setiap sesi, dan ia membutuhkan jawaban dalam kata-kata yang bisa ia proses secara logika. Itulah sebabnya deskripsi tool MCP ditulis seperti sebuah saran ("Gunakan ini untuk menemukan open pull requests yang menyentuh path tertentu") alih-alih seperti dokumentasi referensi.
Scope adalah fitur keamanan. API key untuk sebuah layanan biasanya memberikan akses ke semua hal yang diizinkan oleh key tersebut. Sebuah MCP server dapat memutuskan aksi mana saja yang tersedia. Server analytics yang bersifat read-only cukup dengan tidak menyertakan tool delete. Anda tidak bisa mendapatkan jaminan yang sama hanya dengan memberi tahu model "tolong jangan hapus apa pun".
MCP vs function calling
Function calling, atau tool use sebagaimana disebut oleh beberapa vendor, adalah sebuah fitur dari model API: Anda mencantumkan fungsi-fungsi dalam request Anda, dan model dapat menjawab dengan "panggil fungsi ini dengan argumen berikut". Hal ini sering kali tertukar dengan MCP karena pada akhirnya MCP menggunakan fitur tersebut.
Berikut adalah cara keduanya bekerja bersama. Host app Anda, misalnya Claude Code, terhubung ke MCP server dan mengumpulkan tool mereka. Saat mengirimkan request ke model, host akan meneruskan tool tersebut sebagai definisi fungsi. Ketika model meminta untuk memanggil salah satunya, host akan mengarahkan panggilan tersebut ke MCP server yang tepat dan mengirimkan hasilnya kembali. Jadi, function calling adalah sisi yang berhadapan dengan model, sedangkan MCP adalah standar untuk segala sesuatu di sisi lainnya: bagaimana tool dideskripsikan, ditemukan, diotorisasi, dan diakses di berbagai vendor.
Jika Anda sedang membangun satu fitur, di satu aplikasi, dengan satu model, menggunakan function calling biasa akan lebih praktis dan sudah cukup memadai. MCP akan memberikan keuntungan saat tool yang sama harus bisa bekerja di banyak aplikasi, atau saat Anda ingin pengguna membawa AI client mereka sendiri.
| Function calling | MCP | |
|---|---|---|
| Apa itu | Fitur dari satu model API | Sebuah protokol antara AI apps dan tool servers |
| Di mana tool didefinisikan | Dalam request aplikasi Anda ke model | Di server terpisah yang bisa diakses oleh client mana pun |
| Bekerja di | Aplikasi yang Anda buat | Setiap MCP client |
| Discovery | Anda mengirimkan daftar di setiap request | Client bertanya ke server saat runtime |
| Terbaik untuk | Satu fitur, satu aplikasi, satu model | Tool yang dibagikan di berbagai aplikasi, agents, dan vendor |
Kapan API menjadi pilihan yang tepat
Lewati penggunaan MCP jika tidak ada model yang terlibat. Web frontend, aplikasi mobile, nightly sync job, atau integrasi partner sebaiknya langsung berkomunikasi dengan API Anda. Menambahkan layer MCP dalam skenario ini tidak memberikan keuntungan apa pun dan justru menambah satu hop tambahan.
Lewati MCP jika Anda membutuhkan kontrol presisi pada setiap pemanggilan. Proses payment capture, bulk delete, atau apa pun yang memerlukan jalur kode buatan manusia lengkap dengan test dan audit trail, harus berada di dalam kode normal yang memanggil API, meskipun AI membantu Anda menulis kode tersebut.
Dan lewati MCP jika model hanya membutuhkan data yang sudah Anda miliki. Jika aplikasi Anda mengambil data record customer lalu menempelkannya ke dalam prompt, itu bukanlah sebuah tool, melainkan context, dan tidak memerlukan server.
| Situasi | Gunakan |
|---|---|
| Web atau mobile frontend memanggil backend Anda | API |
| Nightly sync atau integrasi partner | API |
| Payments, bulk deletes, atau apa pun yang butuh audit trail | API, melalui kode yang sudah di-test |
| Aplikasi Anda sudah memiliki datanya dan menempelkannya ke prompt | Tidak keduanya; itu adalah context, bukan tool |
| Satu fitur AI di dalam satu aplikasi yang Anda kontrol | Function calling |
| Model harus memutuskan apa yang perlu dicari atau dilakukan | MCP |
| Customer Anda menggunakan Claude, Cursor, dan ChatGPT | MCP, idealnya sebuah hosted server |
| Beberapa internal agent membutuhkan sistem yang sama | Satu shared MCP server |
Kapan MCP menjadi pilihan yang tepat
Gunakan MCP saat sebuah model harus memutuskan apa yang perlu dilakukan. Agent yang bertugas mencari informasi, membuat ticket, melakukan query ke database, atau mengecek status deploy membutuhkan tools, dan MCP adalah standar untuk memberikan tools tersebut kepada mereka.
Ini juga merupakan pilihan tepat jika Anda ingin produk Anda bisa berjalan di berbagai AI tools milik orang lain. Jika customer Anda menggunakan Claude, Cursor, dan ChatGPT, satu MCP server dapat menjangkau semuanya. Itulah alasan mengapa perusahaan seperti GitHub, Linear, Notion, dan Stripe merilis MCP server mereka sendiri. Di HostedMCP, Anda dapat menelusuri server resmi berdasarkan product dan melihat mana yang di-host secara cloud versus yang dijalankan secara lokal.
Selain itu, MCP sangat membantu saat Anda menjalankan beberapa agent secara internal. Menggunakan satu MCP server per sistem yang dibagikan ke setiap agent jauh lebih mudah untuk diamankan dan diperbarui dibandingkan harus menyalin kode tool ke dalam setiap agent.
Keamanan juga berbeda
API dan MCP server menghadapi ancaman yang berbeda, terutama karena adanya model dalam prosesnya.
Pada API, pemanggilnya adalah kode Anda, dan ia melakukan apa yang Anda tulis. Dengan MCP, pemanggilnya adalah sebuah model yang membaca teks yang tidak terpercaya: halaman web, email, atau komentar issue. Sebuah komentar issue yang ditulis dengan hati-hati dapat mencoba meyakinkan model untuk memanggil tool yang seharusnya tidak boleh diakses. Itulah yang disebut prompt injection, dan inilah alasan mengapa host yang baik akan meminta konfirmasi sebelum menjalankan tool yang mengubah data, serta mengapa server sebaiknya hanya mengekspos set tool paling minimal yang memang dibutuhkan.
Spesifikasi MCP juga mengambil sikap tegas terkait token. Di bawah praktik terbaik keamanannya, sebuah server tidak boleh menerima token yang tidak diterbitkan untuk server tersebut, dan tidak boleh meneruskan token pengguna ke layanan lain. Anti-pattern ini memiliki nama, token passthrough, dan ini adalah salah satu hal pertama yang perlu Anda periksa dalam kode server sebelum Anda mempercayainya. Untuk server jarak jauh, otorisasi mengikuti OAuth 2.1, dan revisi 2026-07-28 memindahkan registrasi client ke Client ID Metadata Documents. Informasi lebih lanjut dapat Anda temukan di panduan keamanan MCP kami.
Perhatian
Perlakukan setiap argumen yang diterima oleh tool MCP sebagai input yang tidak terpercaya. Model yang memilih argumen tersebut mungkin saja telah membaca halaman web atau komentar issue yang ditulis untuk mengarahkannya.
Performa dan biaya
Beberapa orang terkadang khawatir bahwa MCP itu lambat. Sebuah local server hanya menambah satu panggilan proses pada mesin yang sama, sementara remote server hanya menambah satu HTTP round trip. Keduanya sangat kecil jika dibandingkan dengan waktu beberapa detik yang dihabiskan model untuk menulis jawabannya.
Biaya yang sebenarnya penting adalah context. Setiap tool yang dimuat oleh host menyertakan deskripsi dan schema yang harus dibaca oleh model, dan setiap hasil tool akan masuk ke dalam percakapan. Sebuah server dengan delapan puluh tool yang verbose dapat menghabiskan sebagian besar context window bahkan sebelum Anda mengajukan pertanyaan apa pun. Itulah salah satu alasan mengapa kami menampilkan daftar tool lengkap di setiap halaman server di HostedMCP: Anda bisa melihat seberapa besar sebuah server sebelum melakukan install, dan memilih server yang lebih kecil jika server yang lebih fokus sudah cukup untuk kebutuhan Anda.
Mengubah API menjadi MCP server yang mumpuni
Jalan pintas yang menggoda adalah membuat satu tool untuk setiap endpoint dari file OpenAPI. Ada tool yang bisa melakukan hal tersebut secara otomatis, dan itu berguna untuk prototipe cepat. Namun, cara ini jarang menghasilkan server yang bagus. Coba buka beberapa listing yang berisi ratusan tool yang hampir identik, dan Anda akan melihat masalahnya: model harus membaca setiap tool tersebut, padahal sebagian besar hanya memetakan endpoint yang tidak akan pernah ditanyakan dalam percakapan.
Model tidak berpikir dalam bentuk endpoint. Model berpikir dalam bentuk tugas. "Cari pelanggan yang mengirim email tentang invoice 1042 dan tunjukkan tiga tagihan terakhir mereka" adalah satu tugas yang mencakup beberapa endpoint. Server yang bagus menawarkan tool pada level tersebut: find_customer yang menerima email, nomor invoice, atau nama, dan recent_charges yang mengembalikan ringkasan singkat yang mudah dibaca, alih-alih JSON mentah dengan empat puluh field.
| Tool berbasis endpoint | Tool berbasis tugas |
|---|---|
GET /customers?email= |
find_customer yang menerima email, nomor invoice, atau nama |
GET /charges?customer= yang mengembalikan 40 field |
recent_charges yang mengembalikan ringkasan singkat yang mudah dibaca |
| Satu tool per endpoint, totalnya ratusan | Beberapa tool saja yang sesuai dengan apa yang ditanyakan orang |
| Deskripsi hasil copy-paste dari dokumentasi referensi | Deskripsi yang menjelaskan kapan harus menggunakan tool tersebut |
Beberapa kebiasaan berikut akan memberikan perbedaan besar.
-
Tulis deskripsi untuk model. Jelaskan kegunaan tool tersebut dan kapan harus menggunakannya, bukan sekadar apa yang dikembalikannya. "Gunakan tool ini sebelum membuat refund untuk memastikan tagihan tersebut milik pelanggan yang bersangkutan" jauh lebih berharga bagi model daripada sekadar daftar field.
-
Kembalikan data sesedikit mungkin. Batasi respons hanya pada field yang benar-benar akan dilihat oleh manusia, dan gunakan paginasi dengan cursor yang jelas. Setiap field tambahan akan memakan context dan meningkatkan risiko model salah membaca data.
-
Buat tool yang berbahaya menjadi jelas. Beri nama secara gamblang, seperti
delete_project, dan gunakan hint read-only atau destructive yang disediakan oleh spec, sehingga host dapat meminta konfirmasi. Lebih baik lagi, jangan sertakan aksi destruktif pada versi pertama. -
Validasi semuanya. Argumen berasal dari model yang membaca teks yang tidak terpercaya. Periksa tipe data, rentang (range), dan kepemilikan (ownership) di dalam server, sama seperti yang Anda lakukan pada endpoint publik lainnya.
Jadi, mana yang sebaiknya Anda bangun?
Jika Anda belum memiliki API, bangunlah API terlebih dahulu. Aplikasi, script, dan partner Anda pasti akan membutuhkannya, dan MCP server tanpa API yang solid di baliknya cenderung akan menjadi API kedua yang kualitasnya lebih buruk.
Jika Anda sudah memiliki API dan ingin tool AI menggunakan produk Anda, tambahkan MCP server di depannya. Mulailah dengan beberapa tool yang sesuai dengan apa yang sebenarnya diminta oleh pengguna, tulis deskripsi yang ditujukan untuk model (bukan untuk developer), dan tawarkan baik sebagai local package maupun sebagai hosted endpoint jika memungkinkan. Panduan kami tentang membangun MCP server akan memandu Anda menggunakan TypeScript dan Python dengan SDK terbaru.
Jika Anda hanya membutuhkan satu fitur AI di dalam satu aplikasi yang Anda kontrol, function calling sudah cukup untuk saat ini, dan Anda bisa meningkatkan fungsi-fungsi tersebut menjadi MCP server di kemudian hari tanpa harus mengubah API yang ada di baliknya.
Langkah selanjutnya
Untuk melihat bagaimana ini bekerja secara praktis, coba buka beberapa server yang membungkus API populer, seperti GitHub server atau salah satu Postgres servers, lalu bandingkan daftar tool mereka dengan dokumentasi API aslinya. Anda akan menyadari bahwa banyak bagian yang sengaja tidak disertakan. Jika Anda baru mengenal protokol ini, mulailah dengan mempelajari apa itu MCP, dan jika Anda hanya ingin mencobanya, client guides kami menyediakan config yang tepat untuk editor Anda.