Membangun MCP untuk CMS: Menghubungkan AI Agent dengan Sistem Manajemen Konten

Membangun MCP untuk CMS: Menghubungkan AI Agent dengan Sistem Manajemen Konten

Model Context Protocol (MCP) membuka cara baru bagi AI assistant dan AI agent untuk berinteraksi dengan aplikasi. Jika sebuah CMS (Content Management System) menyediakan MCP server, AI tidak hanya dapat menjawab pertanyaan tentang konten, tetapi juga menjalankan pekerjaan nyata: mencari artikel, membuat draft, memperbarui metadata, mengelola kategori, hingga menerbitkan konten sesuai izin yang diberikan.

Namun, membangun MCP untuk CMS bukan sekadar membungkus REST API menjadi beberapa tool. Integrasi yang baik harus memikirkan keamanan, batas kewenangan, validasi, konsistensi data, dan pengalaman editorial.

Artikel ini membahas konsep, arsitektur, desain tool, implementasi bertahap, serta praktik keamanan untuk membangun MCP server yang terhubung dengan CMS.

1. Apa itu MCP dan mengapa CMS membutuhkannya?

Model Context Protocol (MCP) adalah protokol terbuka yang menstandarkan cara aplikasi menyediakan konteks dan kemampuan kepada aplikasi AI. Dalam arsitektur MCP, server dapat mengekspos tiga jenis kemampuan utama:

• Tools: aksi yang dapat dipanggil AI, misalnya membuat artikel atau mencari konten.
• Resources: data yang dapat dibaca sebagai konteks, misalnya daftar kategori, skema konten, atau dokumentasi CMS.
• Prompts: template instruksi yang membantu menjalankan alur kerja tertentu.

Tanpa MCP, integrasi AI dengan CMS sering dibuat secara khusus untuk satu model atau satu aplikasi. Setiap integrasi membutuhkan konektor dan format pemanggilan sendiri. MCP menyediakan kontrak yang lebih konsisten sehingga berbagai MCP client dapat menggunakan kemampuan CMS yang sama.

Contoh sederhana: editor meminta AI, “Buat draft artikel tentang keamanan API, masukkan ke kategori Security, dan jangan publikasikan dulu.” AI dapat menggunakan tool MCP untuk mencari kategori, membuat artikel, lalu mengembalikan tautan draft kepada editor.

2. Arsitektur MCP untuk CMS

Prinsip desain yang disarankan adalah menempatkan MCP server sebagai lapisan integrasi dan kontrol, bukan memberikan akses database langsung kepada AI.

Alur umumnya:

1. Pengguna memberikan instruksi melalui MCP client atau AI assistant.
2. MCP client mengirim permintaan ke MCP server.
3. MCP server memeriksa identitas, izin, dan validitas parameter.
4. MCP server memanggil API internal CMS atau service layer.
5. CMS menjalankan aturan bisnis dan menyimpan perubahan ke database.
6. MCP server mengembalikan hasil terstruktur kepada AI client.

Secara konseptual:

User / Editor
     |
     v
AI Assistant / MCP Client
     |
     | MCP (tools, resources, prompts)
     v
MCP Server for CMS
     |-- Authentication & Authorization
     |-- Input Validation
     |-- Audit Log & Rate Limit
     |
     v
CMS Service Layer / REST API
     |
     v
CMS Database + Media Storage

Mengapa tidak langsung mengakses database? Karena aturan seperti status publikasi, workflow persetujuan, sanitasi HTML, relasi kategori, dan pengelolaan media seharusnya tetap dijalankan oleh CMS. Akses database langsung berisiko melewati aturan tersebut dan membuat perubahan yang sulit diaudit.

3. Tentukan kemampuan MCP berdasarkan pekerjaan editorial

Hindari membuat satu tool besar seperti manage_cms yang menerima banyak parameter dan melakukan berbagai tindakan. Tool yang terlalu umum membuat perilaku sulit diprediksi dan izin sulit dibatasi.

Lebih baik buat tool kecil dengan tujuan yang jelas.

Pisahkan operasi yang berisiko. Membuat draft tidak sama dengan menerbitkan artikel. AI yang memiliki izin membuat draft belum tentu boleh mengubah atau menerbitkan konten.

Contoh kontrak tool

Contoh konseptual skema input untuk tool create_post:

{
  "title": "Panduan Keamanan API untuk CMS",
  "content_markdown": "# Keamanan API\n...",
  "excerpt": "Praktik penting untuk melindungi API CMS.",
  "categories": ["Security"],
  "tags": ["API", "CMS"],
  "status": "draft"
}

Server harus memvalidasi setiap field, membatasi panjang konten, memastikan kategori valid, dan menetapkan status default sebagai draft. Jangan mempercayai parameter hanya karena berasal dari AI client.

4. Implementasi MCP server dengan TypeScript

Untuk CMS yang memiliki API HTTP, MCP server dapat dibangun sebagai service terpisah menggunakan TypeScript. Pemisahan ini membuat integrasi lebih mudah dipelihara dan tidak mengikat protokol MCP pada bahasa pemrograman CMS.

Contoh berikut menggambarkan pola implementasi menggunakan SDK MCP. Ini adalah kerangka ilustratif; sesuaikan versi SDK, transport, dan autentikasi dengan lingkungan produksi.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const server = new McpServer({
  name: "cms-mcp-server",
  version: "1.0.0"
});

const CmsPostInput = z.object({
  title: z.string().min(5).max(160),
  content_markdown: z.string().min(1).max(100_000),
  excerpt: z.string().max(300).optional(),
  categories: z.array(z.string()).max(10).default([]),
  tags: z.array(z.string()).max(20).default([]),
  status: z.enum(["draft", "pending"]).default("draft")
});

server.registerTool(
  "create_post",
  {
    description: "Create a CMS post as draft or pending review",
    inputSchema: CmsPostInput.shape
  },
  async (input) => {
    const parsed = CmsPostInput.safeParse(input);

    if (!parsed.success) {
      return {
        isError: true,
        content: [{
          type: "text",
          text: "Invalid post input. Check the required fields and limits."
        }]
      };
    }

    // Panggil service layer CMS menggunakan kredensial
    // yang dibatasi khusus untuk identitas pemanggil.
    const post = await cmsClient.createPost(parsed.data);

    return {
      content: [{
        type: "text",
        text: JSON.stringify({
          id: post.id,
          title: post.title,
          status: post.status,
          url: post.editUrl
        })
      }]
    };
  }
);

Catatan penting: cmsClient pada contoh adalah adapter ke API CMS yang perlu Anda implementasikan. Jangan menaruh token rahasia di source code atau mengembalikannya dalam respons tool. Untuk operasi nyata, lakukan pemeriksaan izin sebelum memanggil service CMS.

5. Desain keamanan: bagian yang tidak boleh diabaikan

MCP server dapat melakukan perubahan langsung pada website. Karena itu, keamanan harus menjadi bagian dari desain sejak awal.

Authentication dan authorization

• Gunakan autentikasi yang sesuai dengan transport dan lingkungan deployment.
• Terapkan prinsip least privilege pada setiap identitas atau koneksi.
• Bedakan izin membaca, membuat draft, mengedit, mengunggah media, dan menerbitkan.
• Jangan menganggap instruksi dalam percakapan sebagai bukti bahwa pengguna berhak melakukan tindakan.
• Jika CMS mendukung role dan capability, petakan izin MCP ke aturan CMS tersebut.

Approval untuk tindakan sensitif

Terapkan alur persetujuan untuk tindakan yang berdampak ke publik, seperti publikasi, penghapusan, atau perubahan massal. Pilihan yang aman adalah membuat draft terlebih dahulu, menampilkan ringkasan perubahan, lalu meminta persetujuan editor sebelum publikasi.

Validasi dan sanitasi

• Validasi tipe, panjang, format, dan jumlah item pada setiap input.
• Sanitasi HTML dan URL untuk mencegah XSS.
• Batasi jenis, ukuran, dan dimensi file media.
• Cegah path traversal dan nama file berbahaya.
• Jangan menerima SQL, kode, atau instruksi shell dari input tool.
• Gunakan parameterized query jika service internal memang perlu menjalankan query.

Rate limit dan audit trail

Terapkan rate limit per pengguna dan per tool. Catat siapa melakukan apa, kapan, melalui koneksi mana, objek apa yang berubah, serta hasil operasinya. Jangan mencatat access token, password, atau data sensitif secara utuh.

Lindungi dari prompt injection

Konten CMS dapat berisi teks tidak tepercaya, termasuk instruksi yang sengaja dibuat untuk memanipulasi AI. Perlakukan isi artikel, komentar, metadata, dan dokumen sebagai data, bukan instruksi sistem. Tool harus tetap memeriksa izin di sisi server, terlepas dari apa pun yang diminta oleh konten tersebut.

6. Resources dan prompts: jangan hanya mengandalkan tools

MCP server CMS yang matang sebaiknya juga menyediakan resources dan prompts.

Resources dapat menyajikan:

• Daftar kategori dan tag.
• Panduan editorial dan gaya penulisan.
• Skema custom post type dan custom fields.
• Status workflow dan aturan publikasi.
• Dokumentasi API internal yang aman untuk dibaca.

Prompts dapat menyediakan alur kerja yang konsisten, misalnya:

• Menyusun artikel SEO berdasarkan brief.
• Memeriksa kelengkapan artikel sebelum diajukan.
• Mengubah catatan menjadi draft artikel.
• Membuat ringkasan artikel untuk media sosial.

Dengan begitu, AI tidak perlu menebak struktur CMS atau aturan editorial setiap kali menjalankan tugas.

7. Strategi integrasi untuk berbagai jenis CMS

Arsitektur MCP sebaiknya tidak terlalu bergantung pada satu CMS. Buat adapter agar kemampuan inti dapat digunakan ulang.

Masing-masing CMS memiliki model konten, autentikasi, dan workflow berbeda. Adapter bertugas menerjemahkan kontrak MCP yang konsisten menjadi operasi spesifik CMS.

8. Testing dan acceptance criteria

Sebelum digunakan oleh editor, uji bukan hanya apakah tool berhasil dipanggil, tetapi juga apakah batas keamanan benar-benar bekerja.

Checklist minimum:

• MCP client dapat terhubung dan membaca daftar kemampuan.
• Pengguna tanpa izin tidak dapat membaca konten privat.
• Pengguna dengan izin draft dapat membuat draft, tetapi tidak menerbitkan.
• Input tidak valid ditolak dengan pesan yang aman dan jelas.
• HTML dan URL berbahaya disanitasi atau ditolak.
• Upload media memeriksa MIME type, ukuran, dan ekstensi.
• Rate limit aktif dan menghasilkan respons yang sesuai.
• Setiap perubahan tercatat di audit log.
• Kegagalan API CMS tidak menghasilkan laporan sukses palsu.
• Operasi berulang tidak membuat duplikasi yang tidak diinginkan.
• Token dan rahasia tidak muncul di log maupun respons tool.

Uji juga skenario ketika koneksi terputus setelah CMS berhasil menyimpan perubahan tetapi sebelum MCP client menerima respons. Gunakan idempotency key atau mekanisme deduplikasi untuk operasi yang perlu aman saat dicoba ulang.

9. Roadmap pengembangan MCP untuk CMS

Pengembangan dapat dilakukan bertahap agar risiko dan biaya implementasi tetap terkendali.

Tahap 1 — Read-only MCP

• Koneksi dan autentikasi.
• Search posts, get post, list categories, dan search media.
• Logging dan rate limiting.

Tahap 2 — Content authoring

• Create draft dan update draft.
• Validasi konten, kategori, tag, dan metadata.
• Integrasi dengan panduan editorial.

Tahap 3 — Editorial workflow

• Submit for review.
• Approval.
• Publish dan scheduling dengan izin khusus.
• Audit trail lengkap.

Tahap 4 — Advanced automation

• Analisis konten dan SEO.
• Rekomendasi internal linking.
• Pengelolaan media.
• Workflow multi-agent dengan pembatasan izin dan persetujuan manusia.

Mulailah dari kemampuan read-only, kemudian tambahkan kemampuan menulis. Jangan memulai MVP dengan akses penuh ke seluruh fungsi administrasi CMS.

10. Kesimpulan

MCP dapat mengubah CMS dari aplikasi yang hanya dioperasikan melalui dashboard menjadi platform yang dapat berkolaborasi dengan AI assistant dan AI agent. Editor dapat mencari, menyusun, memperbarui, dan mengelola konten melalui bahasa natural, sementara CMS tetap menjadi sumber kebenaran untuk data, workflow, dan hak akses.

Kunci keberhasilannya bukan jumlah tool yang tersedia, melainkan desain kontrak yang jelas, pemisahan izin, validasi di sisi server, audit trail, serta human approval untuk tindakan sensitif.

Rekomendasi: bangun MCP server sebagai service terpisah, gunakan API resmi atau service layer CMS, mulai dengan read-only dan draft workflow, lalu perluas secara bertahap. Dengan pendekatan ini, integrasi AI menjadi lebih aman, terukur, dan dapat dikembangkan untuk berbagai CMS.

---

Catatan: MCP SDK dan API CMS terus berkembang. Periksa dokumentasi resmi versi yang digunakan sebelum menerapkan contoh kode ini ke lingkungan produksi.