Cara Membuat API dengan Cursor Composer 2.5

Cursor Composer 2.5 cukup cepat dan murah untuk meminta agen menulis klien API, tipe, dan pengendali rute. Masalahnya muncul saat kode menyentuh layanan nyata: model bisa menulis request yang terlihat rapi ke /v2/orders, padahal layanan Anda mengekspos /orders dan memakai payload berbeda. Kode terkompilasi, tetapi gagal saat dijalankan.

Coba Apidog hari ini

Panduan ini menunjukkan workflow yang lebih aman: hubungkan Composer 2.5 ke spesifikasi API nyata melalui MCP, minta ia menghasilkan kode berdasarkan kontrak tersebut, lalu verifikasi request di Apidog sebelum kode masuk ke branch tim. Jika Anda baru mengenal model ini, baca juga panduan Cursor Composer 2.5.

Mengapa model agentik sering salah menebak API

Composer 2.5 dirancang untuk tugas agen yang panjang dan multi-langkah. Anda bisa memintanya:

Tambahkan klien untuk layanan billing dan hubungkan ke alur checkout.

Model akan merencanakan perubahan, mengedit beberapa file, dan menjalankan test. Ini peningkatan dari Composer 2, dan berguna untuk pekerjaan implementasi nyata.

Masalahnya: jika kontrak API tidak tersedia di konteks, model akan mengisi kekosongan dengan pola umum yang pernah ia lihat:

• endpoint yang hampir benar, misalnya /api/users/{id} alih-alih /users/{userId};
• field request yang dibuat-buat atau salah nama;
• skema autentikasi generik, bukan skema aktual layanan Anda;
• status code dan response shape yang tidak sesuai server.

Prompt bisa membantu, tetapi menempelkan seluruh OpenAPI spec ke chat tidak stabil dan menghabiskan konteks. Solusi yang lebih tahan lama adalah memberi model akses terstruktur ke spesifikasi API.

Solusi: hubungkan Composer 2.5 ke spesifikasi API melalui MCP

Model Context Protocol (MCP) adalah standar terbuka untuk menyediakan tool dan data ke model AI. Cursor mendukung server MCP, dan server MCP Apidog mengekspos spesifikasi API Apidog Anda sebagai sumber terstruktur yang bisa dibaca model saat coding.

Hasilnya: Composer 2.5 tidak perlu menebak endpoint, schema, parameter, atau response. Ia bisa membaca kontrak aktual, lalu menghasilkan kode berdasarkan kontrak tersebut. Pola ini sama dengan pendekatan "vibe coding" dengan server MCP Apidog, tetapi diterapkan ke workflow implementasi API yang lebih lengkap.

Langkah 1: siapkan spesifikasi API di Apidog

Pastikan kontrak API Anda tersedia dan mutakhir di Apidog.

Yang perlu dicek:

1. Endpoint sudah sesuai layanan nyata.
2. Method HTTP benar.
3. Path parameter, query parameter, header, dan body request lengkap.
4. Response schema mencakup skenario sukses dan error.
5. Contoh request/response masih relevan.

Jika Anda sudah punya dokumen API, impor langsung ke Apidog dari OpenAPI atau koleksi Postman. Spesifikasi ini akan menjadi sumber kebenaran Composer 2.5, jadi kualitas output model bergantung pada akurasi kontrak tersebut.

Langkah 2: sambungkan server MCP Apidog ke Cursor

Cursor membaca konfigurasi MCP dari file proyek, biasanya:

.cursor/mcp.json

Contoh konfigurasi:

{
  "mcpServers": {
    "apidog-api-spec": {
      "command": "npx",
      "args": [
        "-y",
        "apidog-mcp-server@latest",
        "--project=<id-proyek-anda>"
      ],
      "env": {
        "APIDOG_ACCESS_TOKEN": "<token-akses-anda>"
      }
    }
  }
}

Gunakan command, project ID, dan token sesuai panduan pengaturan MCP Apidog, karena nilai tersebut spesifik untuk akun dan proyek Anda.

Setelah menyimpan file:

1. Tutup dan buka ulang Cursor.
2. Pastikan workspace yang aktif adalah proyek yang berisi .cursor/mcp.json.
3. Buka sesi agent baru agar Cursor memuat server MCP.

Langkah 3: pastikan Composer 2.5 bisa membaca spesifikasi

Buka Cursor, pilih model composer-2.5, lalu mulai dengan prompt read-only:

Menggunakan server MCP apidog-api-spec, daftar endpoint di resource orders dan field yang wajib dikirim saat membuat order.

Jika koneksi benar, model akan mengembalikan endpoint dan field dari spesifikasi Anda.

Jika model menjawab dengan pola umum seperti /orders, orderId, atau items tanpa detail yang cocok dengan spec, jangan lanjut coding dulu. Periksa:

• nama server MCP di mcp.json;
• token akses Apidog;
• project ID;
• apakah Cursor sudah di-restart;
• apakah model berada di mode agent yang bisa memakai tool MCP.

Langkah 4: minta Composer 2.5 membuat kode berdasarkan kontrak

Setelah MCP aktif, berikan tugas implementasi dengan menyebutkan sumber kebenaran secara eksplisit.

Contoh prompt:

Gunakan server MCP apidog-api-spec sebagai sumber kebenaran.

Tulis klien TypeScript untuk API orders:
- implementasikan createOrder dan getOrder;
- cocokkan request body dan response schema secara tepat;
- gunakan endpoint, method, header, dan parameter dari spesifikasi;
- tambahkan handling untuk response validasi 422 yang didefinisikan di spec;
- jangan membuat field atau endpoint yang tidak ada di spesifikasi.

Contoh bentuk output yang ingin Anda arahkan:

export async function createOrder(input: CreateOrderRequest): Promise<CreateOrderResponse> {
  const response = await fetch("/orders", {
    method: "POST",
    headers: {
      "Content-Type": "application/json"
    },
    body: JSON.stringify(input)
  });

  if (response.status === 422) {
    const error = await response.json();
    throw new ValidationError(error);
  }

  if (!response.ok) {
    throw new Error(`Failed to create order: ${response.status}`);
  }

  return response.json();
}

Jangan pakai snippet ini sebagai kontrak final. Endpoint, header, request type, dan error shape harus tetap diambil dari spesifikasi Anda melalui MCP.

Langkah 5: review diff dengan fokus API contract

Setelah Composer 2.5 selesai, jangan hanya melihat apakah test lokal lulus. Review perubahan dengan checklist berikut:

• Apakah path endpoint sama persis dengan spesifikasi?
• Apakah method HTTP benar?
• Apakah required header ikut dikirim?
• Apakah path parameter dan query parameter memakai nama yang benar?
• Apakah request body tidak menambahkan field yang tidak ada di spec?
• Apakah response type sesuai schema?
• Apakah error response yang penting ditangani?

Jika ada bagian yang terlihat seperti tebakan, minta model memperbaikinya dengan instruksi spesifik:

Bandingkan ulang implementasi createOrder dengan schema di apidog-api-spec.
Perbaiki field request dan handling error agar hanya memakai kontrak yang ada di spesifikasi.

Verifikasi sebelum percaya: siklus pengujian Apidog

Menghubungkan model ke spesifikasi mengurangi halusinasi, tetapi tidak menggantikan verifikasi. Spesifikasi bisa tertinggal dari layanan yang berjalan, dan model masih bisa salah membaca edge case.

Gunakan siklus berikut.

1. Jalankan request yang dihasilkan

Ambil endpoint, header, dan payload yang dipakai kode Composer 2.5, lalu kirim sebagai request nyata di Apidog.

Periksa:

• status code;
• response body;
• header autentikasi;
• validasi payload;
• error response;
• environment variable seperti base URL dan token.

2. Simpan request valid sebagai test

Jika request sudah valid, simpan sebagai skenario test otomatis. Tujuannya agar regresi berikutnya tertangkap oleh CI atau test suite, bukan oleh pengguna.

Contoh skenario yang layak disimpan:

• create order berhasil;
• create order gagal karena payload tidak valid;
• get order berhasil;
• get order untuk ID yang tidak ada;
• request tanpa token;
• request dengan role yang tidak memiliki akses.

3. Mock endpoint yang belum tersedia

Jika backend belum selesai, gunakan mock server Apidog untuk mengembalikan response realistis. Dengan begitu, frontend atau service consumer bisa tetap berjalan tanpa menunggu implementasi backend.

Pola ini cocok dengan workflow dalam agen AI dan pengujian API: model membantu membuat draf kode, lalu Apidog dipakai untuk validasi, testing, dan mocking.

Contoh workflow end-to-end

Misalnya Anda menambahkan fitur refund ke layanan pembayaran.

1. Endpoint dan schema refund sudah ada di proyek Apidog dari fase desain.
2. Server MCP Apidog sudah terhubung ke Cursor.
3. Anda memilih composer-2.5.
4. Anda memberi prompt:

Gunakan apidog-api-spec sebagai sumber kebenaran.

Bangun klien refund dan React hook untuk memanggilnya.
Ikuti schema persis dari spesifikasi, termasuk header idempotency-key yang diwajibkan.
Tambahkan handling untuk response 409 saat request duplikat.

1. Composer 2.5 membaca kontrak nyata, lalu menulis klien, tipe, hook, dan test.
2. Anda membuka Apidog dan mengirim request create-refund.
3. Anda memverifikasi perilaku idempotensi dan response 409.
4. Anda menyimpan request sukses dan request duplikat sebagai skenario test.

Bug yang dihindari: klien lupa mengirim idempotency-key, lalu request refund ganda terjadi di staging. Dengan MCP + verifikasi, kesalahan seperti ini lebih mudah ditangkap sebelum merge.

Prompt template yang bisa langsung dipakai

Gunakan template berikut saat meminta Composer 2.5 mengimplementasikan fitur API:

Gunakan server MCP apidog-api-spec sebagai satu-satunya sumber kebenaran untuk kontrak API.

Tugas:
- implementasikan <nama-fitur>;
- gunakan endpoint, method, parameter, header, request body, dan response schema dari spesifikasi;
- jangan membuat endpoint, field, enum, atau status code yang tidak ada di spesifikasi;
- tambahkan type TypeScript untuk request dan response;
- tambahkan handling error untuk status code yang didefinisikan di spesifikasi;
- jalankan test yang relevan jika tersedia;
- setelah selesai, jelaskan file yang diubah dan asumsi apa pun yang masih perlu diverifikasi di Apidog.

Untuk review ulang:

Audit implementasi ini terhadap apidog-api-spec.
Cari mismatch pada endpoint, method, header, parameter, request body, response type, dan error handling.
Perbaiki mismatch yang ditemukan.

Pertanyaan yang sering diajukan

Apakah Composer 2.5 mendukung MCP?

Ya. Composer 2.5 dapat memakai tool agent Cursor, termasuk server MCP. Pilih model melalui model picker, lalu konfigurasikan server MCP di proyek Anda. Panduan Composer 2.5 menjelaskan cara memilih model.

Apakah saya harus memakai Apidog untuk MCP dengan Composer 2.5?

Anda memerlukan sumber spesifikasi terstruktur. Server MCP Apidog adalah jalur yang dibahas di sini karena spesifikasi, testing, dan mocking berada di tempat yang sama. Opsi lain juga tersedia dalam rangkuman server MCP terbaik untuk Cursor.

Apakah spesifikasi API menghentikan semua halusinasi model?

Tidak sepenuhnya. MCP mengurangi kategori kesalahan terbesar: endpoint, schema, parameter, dan response yang ditebak. Namun, Anda tetap perlu menguji request terhadap layanan nyata atau mock, karena spesifikasi bisa bergeser dari implementasi.

Apakah workflow ini berguna untuk proyek kecil?

Ya, jika model menyentuh API nyata. Setup-nya hanya file konfigurasi, tetapi manfaatnya berlaku untuk setiap request yang dihasilkan: kode mengikuti kontrak Anda, bukan tebakan umum.

Intinya

Composer 2.5 bisa mempercepat pekerjaan API, tetapi hanya aman jika model menulis kode berdasarkan kontrak nyata. Hubungkan spesifikasi API melalui server MCP Apidog, minta Composer 2.5 memakai spec sebagai sumber kebenaran, lalu unduh Apidog untuk mengirim request, memverifikasi response, dan menyimpan skenario yang valid sebagai test otomatis atau mock. Kombinasi kontrak + verifikasi adalah cara mengubah kecepatan agen menjadi fitur yang siap dikirim.