Kapan Bisnis Perlu MCP dan Kapan Cukup API Biasa

Founder sebuah SaaS B2B membuka meeting dengan satu kalimat yang sekarang makin sering terdengar.

“Kita bikin MCP server aja sekalian. Biar AI-ready.”

CTO-nya tidak langsung menolak. Ia cuma bertanya:

“AI-ready untuk siapa, dan problem integration apa yang kita selesaikan?”

Pertanyaan itu menyelamatkan banyak waktu.

MCP atau Model Context Protocol memang makin penting sebagai standard untuk menghubungkan AI application dan agent ke external system. MCP memberi cara terstruktur agar client menemukan dan menggunakan tools, resources, serta capability lain dari server.

Tetapi MCP tidak membuat API biasa obsolete.

API tetap menjadi fondasi mayoritas business integration. Bahkan banyak MCP server pada akhirnya membungkus API yang sudah ada. Jadi keputusan yang sehat bukan “API atau MCP, siapa masa depan?” melainkan “di layer mana MCP memberikan value tambahan yang nyata?”

Mulai dari API yang sudah bekerja

Kalau bisnis punya REST atau GraphQL API yang stabil, authenticated, well-documented, dan dipakai integrator dengan baik, jangan merobohkannya hanya karena MCP sedang naik.

API punya keunggulan besar: mature tooling, predictable contract, monitoring yang mapan, rate limiting, gateway, SDK, caching, developer familiarity, dan integration ecosystem yang sudah terbentuk bertahun-tahun.

Untuk machine-to-machine system yang deterministic, API sering sudah cukup.

Contoh:

sistem ERP mengirim invoice ke accounting service,
warehouse mengirim stock update ke marketplace,
mobile app mengambil daftar transaksi,
backend menghitung ongkir lewat shipping API.

Tidak ada alasan otomatis untuk memindahkan semua interaction itu ke MCP.

MCP masuk ketika consumer-nya adalah AI host atau agent

Perbedaan mulai terasa ketika sistem Anda ingin dipakai oleh banyak AI application yang perlu memahami capability secara konsisten.

Bayangkan sebuah platform HR punya 40 endpoint API.

Untuk engineer manusia, dokumentasi endpoint itu masih manageable.

Untuk AI host, pertanyaannya berbeda. Capability mana yang relevan untuk task user? Input apa yang aman? Tool mana yang read-only? Output apa yang structured? Bagaimana host menemukan fungsi yang tersedia tanpa custom adapter untuk setiap platform?

Di sini MCP menawarkan abstraction yang lebih dekat dengan kebutuhan AI.

MCP server dapat mengekspos tool dengan nama, deskripsi, input schema, dan output yang dapat digunakan host untuk orchestration. Ia juga dapat menyediakan resource atau capability lain yang sesuai dengan model MCP.

Bukan karena HTTP API tidak bisa melakukan hal yang sama secara teknis. Bisa.

Value MCP ada pada standardization di layer AI integration.

Satu API, banyak AI host

Use case paling masuk akal muncul ketika bisnis ingin capability yang sama dapat dipakai lintas beberapa AI environment.

Misalnya perusahaan software accounting ingin produknya bisa diakses dari berbagai AI client.

Tanpa standard layer, perusahaan mungkin membuat integration A untuk host pertama, integration B untuk host kedua, integration C untuk agent framework ketiga.

Setiap integration punya mapping tool sendiri, auth quirks sendiri, discovery sendiri, dan maintenance sendiri.

MCP mencoba mengurangi fragmentation itu dengan kontrak yang sama.

Jadi salah satu signal kuat untuk membangun MCP server adalah:

Anda melihat banyak consumer AI yang berbeda menginginkan akses ke capability yang sama.

Kalau consumer cuma satu aplikasi internal dan integration sudah stabil, benefit-nya mungkin belum sebanding.

Skenario satu: cukup API biasa

Ambil bisnis logistik yang punya endpoint internal untuk calculate_shipping_cost.

Endpoint hanya dipakai checkout backend milik perusahaan sendiri. Payload jelas, latency critical, call path deterministic, dan tidak ada kebutuhan discovery oleh AI.

Membangun MCP server untuk endpoint ini kemungkinan tidak memberi value signifikan.

API biasa sudah tepat.

Kalau nanti customer support agent perlu menghitung ongkir saat menjawab user, perusahaan masih bisa membuat tool wrapper internal tanpa langsung menjadikan seluruh logistics platform sebagai MCP ecosystem.

Skenario dua: MCP mulai masuk akal

Sekarang bisnis yang sama ingin merchant memakai capability logistik dari berbagai AI assistant.

Merchant bisa berkata:

“Cari lima shipment yang delay lebih dari dua hari, kelompokkan penyebabnya, lalu buat draft pesan untuk customer.”

AI host perlu menemukan tool untuk shipment search, tracking detail, status update, dan mungkin communication workflow.

Kalau platform ingin capability tersebut reusable lintas host, MCP memberi surface yang lebih natural.

Di sini MCP bukan menggantikan shipping API.

MCP menjadi AI-facing layer di atas API.

API tetap menangani business logic dan data contract internal. MCP server menerjemahkan capability itu ke bentuk yang lebih gampang ditemukan dan dipanggil AI host.

Jangan expose endpoint satu per satu tanpa desain

Salah satu kesalahan awal ketika perusahaan membuat MCP adalah membungkus setiap endpoint menjadi satu tool secara mekanis.

Hasilnya bisa 150 tool dengan nama teknis, parameter yang terlalu granular, dan semantics yang hanya dimengerti engineer backend.

AI tidak otomatis mendapat experience bagus hanya karena semuanya “terstandardisasi”.

Tool surface harus didesain berdasarkan job yang masuk akal.

Misalnya API punya endpoint:

GET /customers/{id},
GET /orders,
GET /orders/{id}/items,
POST /notes,
POST /notifications.

Tidak selalu berarti Anda harus mengekspos lima tool persis seperti itu.

Bisa jadi AI-facing workflow yang lebih berguna adalah tool “prepare_customer_case_summary” yang menggabungkan read operations tertentu dengan policy yang jelas.

Tetapi jangan juga membuat tool terlalu magical sampai sulit diaudit.

Balance-nya adalah capability yang cukup meaningful untuk model, tetapi tetap punya boundary action yang jelas.

MCP masuk akal ketika discovery penting

API documentation biasanya ditujukan untuk developer yang sengaja datang, membaca docs, lalu coding integration.

MCP punya pola discovery capability yang lebih dinamis bagi host.

Ini penting kalau AI host harus bisa mengetahui apa yang server tawarkan pada runtime.

Kalau business model Anda ingin menjadi bagian dari ecosystem agent, machine-readable capability discovery punya nilai strategis.

Tetapi lagi-lagi, discovery tidak sama dengan demand.

Membuat MCP server tidak berarti otomatis akan dipakai agent, apalagi membuat brand otomatis muncul dalam AI answer. Tidak ada jaminan seperti itu.

MCP menyelesaikan interoperability problem, bukan distribution problem secara otomatis.

Kapan MCP justru menambah beban

Ada beberapa kondisi di mana tim sebaiknya menahan diri.

Pertama, business logic belum stabil.

Kalau API sendiri berubah tiap minggu, menambah MCP layer hanya membuat dua kontrak yang sama-sama bergerak.

Kedua, authorization belum matang.

MCP tool yang bisa melakukan action sensitif harus punya policy, scope, confirmation, dan audit yang jelas. Jangan expose “refund_order” ke AI sebelum tim benar-benar mengerti siapa boleh memanggilnya dan dalam kondisi apa.

Ketiga, tidak ada AI consumer yang nyata.

Kalau seluruh argumen hanya “competitor sudah bikin”, hitung opportunity cost.

Keempat, tim belum punya observability.

Tool call dari agent perlu bisa dilacak: siapa requester, capability apa yang dipanggil, dengan scope apa, result apa, error apa, dan apakah user consent diperlukan.

Kelima, API sebenarnya cukup sederhana dan hanya dipakai satu integrator.

Dalam kondisi ini, wrapper standard bisa jadi lebih banyak maintenance daripada value.

MCP bukan security layer pengganti

Ada godaan menganggap protocol standard membuat integration otomatis aman.

Tidak.

MCP mengatur cara capability diekspos dan dipanggil, tetapi business authorization tetap tanggung jawab sistem.

Kalau tool “transfer_funds” menerima account dan amount, backend tetap harus memeriksa identity, authorization, transaction limit, risk control, idempotency, dan approval.

Model tidak boleh menjadi policy engine terakhir hanya karena ia yang memilih tool.

Dalam desain enterprise, MCP sebaiknya berada di depan service yang memang sudah punya security boundary yang sehat.

Jangan menjadikan MCP server sebagai jalan pintas untuk melewati governance API.

Hitung economics, bukan hype

Buat keputusan dengan model sederhana.

Berapa banyak AI client yang ingin Anda dukung?

Berapa biaya membuat adapter khusus per client?

Berapa banyak capability yang benar-benar layak diekspos?

Seberapa cepat capability berubah?

Apakah authentication dan authorization sudah siap?

Apakah MCP ecosystem consumer Anda cukup matang?

Berapa cost operational untuk server, monitoring, testing, versioning, dan incident response?

Kalau standardization menghemat integrasi di banyak consumer, MCP bisa punya ROI yang jelas.

Kalau tidak, API biasa mungkin lebih elegan.

API untuk system contract, MCP untuk AI-facing capability

Salah satu pattern paling realistis adalah tidak memilih salah satu.

Pertahankan API sebagai system-of-record integration contract.

Tambahkan MCP sebagai facade atau adapter untuk capability yang ingin diberikan kepada AI application.

Dengan pola ini, business logic tidak dipindahkan ke MCP server. MCP server memanggil service yang sudah ada, menerapkan mapping dan policy, lalu memberi tool surface yang sesuai bagi agent.

Keuntungannya, core system tidak harus berubah hanya demi mengikuti evolusi AI protocol.

Kalau MCP spec berubah, layer adapter bisa diperbarui tanpa menulis ulang accounting engine atau CRM.

Untuk perusahaan besar, separation seperti ini sering jauh lebih sehat.

Kapan “cukup API” adalah jawaban yang dewasa

Ada tekanan psikologis di teknologi: kalau tidak memakai protocol terbaru, takut terlihat ketinggalan.

Padahal maturity justru terlihat dari kemampuan berkata “belum perlu”.

Kalau use case deterministic, consumer jelas, API sudah stabil, tidak ada kebutuhan multi-host AI interoperability, dan cost wrapper lebih besar dari benefit, API biasa adalah keputusan yang valid.

Tidak ada bonus point karena arsitektur memiliki lebih banyak layer.

Kapan “sudah waktunya MCP” juga jelas

Sebaliknya, jangan menunggu terlalu lama jika beberapa signal muncul sekaligus:

customer mulai meminta integration ke AI assistant,
beberapa product team membuat wrapper tool sendiri untuk API yang sama,
capability perlu reusable lintas agent host,
AI-facing discovery mulai penting,
dan governance untuk tool access sudah siap.

Kalau itu terjadi, standard layer dapat mengurangi duplication dan mempercepat ecosystem integration.

Dari sudut GEO dan agentic visibility, MCP juga memperluas definisi presence.

Website yang bagus membantu brand dipahami.

API membantu system terintegrasi.

MCP dapat membuat business capability lebih mudah digunakan oleh AI host yang mendukung protocol tersebut.

Tiga hal ini bukan substitusi.

Mereka menjawab tahap yang berbeda.

Jadi ketika seseorang berkata, “Kita harus bikin MCP server karena 2026 semua bisnis akan agentic,” jangan langsung bilang iya atau tidak.

Tanya satu hal dulu:

“Integration cost apa yang sebenarnya ingin kita turunkan?”

Kalau jawabannya jelas, keputusan protocol biasanya ikut menjadi jelas.

Kalau jawabannya cuma “biar kelihatan AI-ready”, API yang sehat mungkin masih jauh lebih berharga daripada MCP server yang dibangun tanpa consumer.