Articles · AI

Kenapa MCP Penting: Dari AI yang Menjawab ke AI yang Benar-Benar Bisa Bekerja

MCP bukan sekadar cara baru memanggil function. Ia membuat capability software lebih terstruktur, aman, testable, dan dapat digunakan banyak AI tanpa membangun integrasi berulang.

19 September 2026Rahman Fakhru6 min read

#AI #mcp #function calling #ai agents #developer tools

On this page · 16

AI makin pintar menjawab pertanyaan, menulis kode, membaca dokumen, dan membantu mengambil keputusan. Tapi ada perbedaan besar antara AI yang pintar menjawab dan AI yang benar-benar bisa bekerja di sistem kita.

Model bisa menjelaskan cara membuat invoice, tetapi belum tentu bisa membuat invoice di aplikasi kita. Model bisa menyarankan update status project, tetapi belum tentu tahu user mana yang sedang login, permission apa yang berlaku, atau kapan sebuah aksi harus menunggu approval manusia.

Di titik inilah Model Context Protocol (MCP) menjadi penting.

#MCP bukan sekadar tool calling

Function calling sebenarnya bukan hal baru. Kita bisa memberi model function seperti:

create_project({ title, client, deadline })

Lalu model memilih function tersebut ketika dibutuhkan.

Masalah muncul ketika setiap AI dan aplikasi punya cara integrasi sendiri. Kita akhirnya membuat konektor terpisah untuk ChatGPT, Claude, Cursor, Codex, agent internal, dan automation lain.

MCP mencoba membuat lapisan ini menjadi lebih standar:

AI / Agent
   ↓
MCP Client
   ↓
MCP Server
   ↓
Auth + Permission + Policy
   ↓
Existing Application Functions
   ↓
Database / External Services

Nilai terbesarnya bukan sekadar protokol. MCP memaksa kita mendesain bagaimana AI boleh berinteraksi dengan software secara terstruktur.

#1. Function calling menjadi kontrak publik

Begitu sebuah function menjadi MCP tool, nama, schema, description, permission, dan output-nya menjadi bagian dari contract yang dipakai agent.

Contoh:

projects_list
projects_get
projects_create
projects_set_status
projects_archive

Model harus bisa memahami:

kapan tool digunakan,
kapan tidak digunakan,
dari mana sebuah ID diperoleh,
apakah tool read-only,
apakah ada side effect,
apakah aman diulang,
dan apakah aksinya irreversible.

Description seperti “Update project” terlalu ambigu.

Yang lebih berguna:

Gunakan tool ini untuk mengubah status project yang sudah ada. Ambil project_id dari projects_list atau projects_search. Jangan gunakan untuk membuat project baru.

Tool description adalah bagian dari UX untuk model.

#2. Tidak semua function harus menjadi tool

Project nyata bisa punya ratusan query, mutation, server action, dan helper. Tidak semuanya layak diberikan ke AI.

Sebuah capability bisa menjadi:

Tool — dipilih dan dipanggil model.
Resource — data readable dengan identity/alamat stabil.
Prompt atau Skill — workflow berulang yang butuh panduan.
Internal function — tetap hanya dipakai backend.
Tidak diekspos — terlalu rendah-level atau terlalu berbahaya.

create_invoice bisa menjadi tool yang bagus.

Sebaliknya, execute_raw_sql, run_shell_command, atau update_anything biasanya terlalu lebar untuk diberikan langsung kepada agent.

Semakin powerful tool, semakin besar blast radius jika model salah memahami instruksi.

#3. MCP bukan backend kedua

MCP yang sehat seharusnya tipis:

MCP Tool
→ validate arguments
→ resolve authenticated user
→ check permission
→ call existing domain/service function
→ normalize result
→ redact sensitive data
→ audit
→ return result

Yang perlu dihindari:

MCP Tool
→ business logic versi kedua
→ database

Kalau web app dan MCP punya business logic berbeda, keduanya akan drift.

Aplikasi utama mungkin sudah menolak suatu aksi, sementara tool MCP lama masih mengizinkannya.

MCP seharusnya memakai source of truth yang sama dengan aplikasi utama.

#4. Identity tidak boleh berasal dari argumen model

Bayangkan tool:

invoice_create({
  user_id: "...",
  company_id: "...",
  amount: 1000000
})

Jika user_id dan company_id menentukan otorisasi, kita sedang mempercayakan identity kepada model.

Itu berbahaya.

Identity seharusnya datang dari authenticated server context:

credential
→ authenticated user
→ organization membership
→ permissions
→ allowed capability

Tool cukup menerima data bisnis yang memang dibutuhkan.

Ini sangat penting untuk aplikasi multi-user dan multi-tenant.

#5. Scope harus berlaku saat list dan call

Misalnya server punya scope:

read
write

User dengan scope read seharusnya:

tidak melihat write tool di tools/list;
tetap ditolak jika mencoba memanggil write tool secara langsung.

Menyembunyikan tool bukan security boundary.

Permission tetap harus diperiksa ketika function benar-benar dijalankan.

#6. Error juga bagian dari desain agent

“500 Internal Server Error” hampir tidak membantu agent mengambil keputusan.

Agent perlu tahu apakah harus:

mencoba ulang,
meminta login,
meminta scope tambahan,
meminta approval,
memperbaiki arguments,
menunggu service/device online,
atau berhenti karena policy melarang aksinya.

Contoh kategori error yang lebih berguna:

AUTHENTICATION_REQUIRED
INSUFFICIENT_SCOPE
APPROVAL_REQUIRED
POLICY_DENIED
VALIDATION_ERROR
RATE_LIMITED
TIMEOUT
UPSTREAM_ERROR

TIMEOUT mungkin boleh retry.

POLICY_DENIED tidak boleh dicari jalan belakangnya.

APPROVAL_REQUIRED berarti berhenti dan menunggu manusia.

Agent yang baik bukan hanya tahu cara bertindak, tetapi juga tahu kapan harus berhenti.

#7. Testing MCP berbeda dengan testing API biasa

API bisa lolos semua unit test tetapi tetap buruk dipakai model.

Selain handler test, kita perlu menguji apakah AI memilih tool yang benar.

Empat bentuk test yang berguna:

#Direct

“Tampilkan semua project aktif.”

Expected: model memilih tool list project.

#Indirect

“Sekarang kita lagi ngerjain apa saja?”

User tidak menyebut nama tool, tetapi model tetap harus menemukan capability yang benar.

#Follow-up

“Buka project kedua tadi.”

Model harus memakai ID dari hasil sebelumnya, bukan mengarang ID.

#Negative

“Apa itu project management?”

Expected: tidak ada tool call.

Negative test sama pentingnya dengan positive test. Agent yang selalu memanggil tool juga bukan agent yang bagus.

#8. MCP membuat aplikasi menjadi agent-ready

Dulu pertanyaan utamanya:

“Apakah aplikasi ini punya API?”

Sekarang muncul pertanyaan baru:

“Apakah aplikasi ini punya capability surface yang bisa dipahami agent?”

API biasanya didesain untuk developer.

MCP tool juga harus didesain supaya model bisa:

memilih capability yang benar,
mengisi argument yang benar,
memahami result,
melakukan follow-up,
dan berhenti ketika policy mengharuskan.

Karena itu MCP menyentuh banyak area sekaligus:

API design,
authentication,
authorization,
schemas,
UX,
security,
observability,
testing,
documentation,
workflow design.

#9. Satu server, banyak client

Idealnya kita tidak membuat:

ChatGPT Backend
Claude Backend
Cursor Backend
Codex Backend

Lebih sehat:

                 ChatGPT
                    ↓
Claude →      MCP Server      ← Cursor
                    ↑
                  Codex

Host boleh punya registration atau packaging berbeda, tetapi business capability-nya tetap sama.

Model boleh berganti tanpa harus membangun ulang seluruh integrasi.

#10. MCP bukan alasan memberi AI akses tanpa batas

Justru sebaliknya.

MCP adalah kesempatan untuk membuat akses AI menjadi lebih sempit dan eksplisit.

Untuk website pribadi, misalnya, AI yang ingin membuat artikel tidak perlu mendapat:

shell VPS,
Docker,
filesystem penuh,
DNS,
database admin,
atau root server access.

Cukup berikan capability yang relevan:

list_posts
get_post
create_post
update_post
delete_post

Bahkan delete bisa diberi policy lebih ketat daripada create/update.

Capability yang sempit lebih mudah diamankan, dites, diaudit, dan dipahami model.

#Jadi, kenapa MCP penting?

Bukan karena MCP sekadar cara baru memanggil function.

MCP penting karena ia memberi kita bahasa bersama untuk mendesain hubungan antara AI dan software.

Ia memaksa kita menjawab pertanyaan penting:

AI sebenarnya boleh melakukan apa?
Data siapa yang sedang diakses?
Tool apa yang seharusnya terlihat?
Kapan manusia perlu approval?
Apa yang terjadi ketika model salah?
Bagaimana kita tahu hasilnya benar?
Bagaimana satu capability dapat digunakan banyak agent tanpa membuat integrasi baru berulang kali?

AI sedang bergeser dari chatbot menjadi operator software.

Model bisa berubah. ChatGPT, Claude, Gemini, model lokal, atau model berikutnya bisa datang dan pergi.

Tetapi jika software kita sudah memiliki capability contract yang baik, authentication yang benar, permission yang jelas, error semantics yang berguna, dan testing yang kuat, kita tidak perlu membangun ulang semuanya setiap kali model berubah.

Itulah nilai terbesar MCP: bukan mengikat software ke satu AI, tetapi membuat software siap digunakan banyak AI dengan batas yang tetap kita kendalikan.