Server MCP

Model Context Protocol (MCP) adalah standar terbuka yang memungkinkan agen AI berbicara dengan tools dan sumber data eksternal. DynoTable bisa bertindak sebagai MCP server — sehingga agen yang berjalan di terminal atau editor Anda (Claude Code, Cursor, Codex, dan lainnya) bisa bekerja dengan tabel DynamoDB Anda secara langsung, alih-alih Anda menyalin skema dan hasil bolak-balik ke dalam chat.

Saat terhubung, agen mendapatkan toolkit gated yang sama dengan yang dipakai asisten bawaan — membaca skema Anda, menjalankan query dan pembacaan item-tunggal, men-stage perubahan untuk ditinjau, membuka tampilan, dan mengekspor — lewat endpoint HTTP lokal loopback-only. Agen menemukan tabel Anda, meng-query-nya, dan mengusulkan editan tanpa pernah memegang kredensial AWS Anda.

Ini mati secara default. Mengaktifkannya, dan setiap koneksi individual, secara eksplisit berada di bawah kendali Anda — lihat Keamanan di bawah.

Aktifkan server

Buka Settings → MCP Server dan aktifkan. DynoTable memulai server yang terikat ke 127.0.0.1 (loopback saja — tidak pernah bisa dijangkau dari mesin lain) dan menampilkan perintah untuk menghubungkannya.

Settings → MCP Server: server berjalan pada port loopback lokal, dengan daftar klien yang terhubung dan tingkat akses mereka.
Settings → MCP Server: server berjalan pada port loopback lokal, dengan daftar klien yang terhubung dan tingkat akses mereka.

Ekspos profile

Server sudah aktif, tetapi tidak ada agen yang bisa terhubung sampai Anda mengekspos sebuah profile. Buka bagian MCP sebuah profile di Settings dan aktifkan Expose via MCP. Setiap profile yang diekspos mendapat perintah koneksi sendiri — sehingga Anda bisa menyiapkan satu koneksi per profile (mis. sebuah dynotable-dev dan sebuah dynotable-prod), masing-masing terisolasi-keras ke kredensial dan region profile tersebut. Sebuah koneksi hanya pernah melihat data dari profile yang diikatnya.

Baik profile berbasis-AWS maupun lokal (DynamoDB-Local) bisa diekspos. Mengekspos profile lokal memungkinkan agen menggerakkan tabel ber-seed lokal Anda lewat MCP — praktis untuk pengembangan. (Dua profile lokal pada port yang sama berbagi database lokal yang sama, jadi keduanya melihat tabel yang sama.)

Bagian MCP sebuah profile dengan “Expose via MCP” diaktifkan — blok koneksi per-profile menampilkan endpoint untuk ditambahkan ke klien Anda.
Bagian MCP sebuah profile dengan “Expose via MCP” diaktifkan — blok koneksi per-profile menampilkan endpoint untuk ditambahkan ke klien Anda.

Hubungkan klien

DynoTable berbicara MCP lewat streamable HTTP, jadi agen apa pun yang mendukung MCP bisa terhubung. Setiap profile yang diekspos menampilkan perintah koneksi sendiri di bagian MCP-nya — salin dari sana. Perintahnya menunjuk ke http://127.0.0.1:<port>/mcp?profile=<slug>: bagian ?profile=<slug> memberi tahu DynoTable profile mana yang Anda inginkan dan memilihnya lebih dulu di prompt persetujuan (itu hanya petunjuk — Anda tetap mengonfirmasi). Memakai slug profile di nama server (mis. dynotable-prod) menjaga koneksi dua profile tetap berbeda.

Contoh di bawah memakai prod sebagai slug; ganti dengan slug profile Anda dan port sebenarnya dari Settings.

Jalankan ini di proyek Anda — ini perintah persis yang ditampilkan di bagian MCP profile:

claude mcp add --transport http dynotable-prod "http://127.0.0.1:<port>/mcp?profile=prod"

Untuk menghubungkan profile kedua, ulangi dengan perintah profile tersebut (slug-nya sendiri). Setelah terhubung, mulai ulang atau muat ulang klien agar ia mengambil server baru.

Setujui koneksi

Pertama kali sebuah klien terhubung, DynoTable menampilkan prompt persetujuan di dalam aplikasi. Ia menyebutkan klien yang terhubung, membiarkan Anda memilih profile mana yang diikat koneksi (dipilih lebih dulu dari petunjuk ?profile=, dibatasi ke profile yang Anda ekspos), dan meminta Anda memberikan sebuah scope — atau menolak. Tidak ada yang diekspos sampai Anda menyetujui.

Prompt persetujuan di dalam aplikasi: klien yang terhubung meminta akses, dan Anda memberikan salah satu dari tiga scope atau menolak.
Prompt persetujuan di dalam aplikasi: klien yang terhubung meminta akses, dan Anda memberikan salah satu dari tiga scope atau menolak.

Scope

Sebuah scope menentukan tools mana yang bisa dilihat dan dipakai koneksi. Mereka kumulatif — setiap tingkat mencakup tingkat sebelumnya:

  • Read only — membaca skema Anda, menjalankan query, dan membaca item. Tanpa perubahan.
  • Read & stage — semua di Read only, plus men-stage perubahan untuk Anda tinjau dan commit (agen tidak pernah menulis ke DynamoDB secara langsung — ia dirutekan lewat staging).
  • Full access — semua di atas, plus membuka tampilan, menyetel filter, dan mengekspor hasil. Penulisan tetap lewat staging — bahkan pada Full access agen tidak bisa menulis ke DynamoDB secara langsung.

Koneksi mengikat profile yang Anda setujui di prompt — kredensial dan region-nya dipancangkan selama umur koneksi, sehingga ia membaca (dan men-stage penulisan ke) persis data profile tersebut. Nama klien di prompt dilaporkan-sendiri oleh agen yang terhubung, jadi profile dan scope yang Anda setujui adalah gate yang sebenarnya, bukan namanya.

Jika profile yang disetujui memakai MFA, agen diminta kode sekali-pakai langsung di sesinya sendiri — tidak perlu beralih kembali ke DynoTable. (Profile yang masuk lewat SSO tetap menyelesaikan sign-in itu di DynoTable.)

Kelola koneksi

Setiap klien yang disetujui tercantum di Settings → MCP Server. Cabut salah satu dari mereka kapan saja — klien yang dicabut diputus pada request berikutnya. Membatalkan ekspos sebuah profile langsung mencabut koneksinya juga. Mematikan server menghentikan semuanya.

Keamanan

  • Loopback saja. Server terikat 127.0.0.1; tidak ada yang di luar mesin Anda bisa menjangkaunya.
  • Mati secara default, persetujuan per koneksi. Tidak ada agen yang mendapat akses sampai Anda mengaktifkan server dan menyetujui koneksinya pada scope yang Anda pilih.
  • Kredensial tetap lokal. Koneksi memakai AWS profile Anda yang ada di mesin ini (Hubungkan ke AWS); kredensial tidak pernah dikirim ke agen.
  • Satu profile per koneksi. Setiap koneksi dipancangkan ke satu profile yang Anda setujui — ia tidak pernah bisa menjangkau tabel atau kredensial profile lain.
  • Penulisan lewat tinjauan. Bahkan pada Full access, perubahan di-stage untuk Anda commit — agen tidak bisa menulis ke DynamoDB sendiri.
  • Bisa dicabut. Cabut klien atau matikan server kapan pun Anda mau.

Diperbarui