Berikut tool knowledge base yang didapat chat Claude atau Claude Code dari server MCP osFoundry. Tool ini diambil dengan tools/list tanpa autentikasi pada 2026-11-08 dan dipangkas ke bagian yang relevan di sini:
{"name": "search_knowledge_base",
"description": "Search current published articles in one granted knowledge base. Results cite the article ID and updated time; this is a live database read.",
"inputSchema": {"required": ["knowledge_base_id", "query"],
"properties": {"query": {"type": "string", "minLength": 2, "maxLength": 200},
"limit": {"type": "integer", "minimum": 1, "maximum": 20}}},
"annotations": {"readOnlyHint": true}}
{"name": "read_knowledge_article",
"description": "Read one current published article by ID from a granted knowledge base and return a stable citation.",
"inputSchema": {"required": ["knowledge_base_id", "article_id"]},
"annotations": {"readOnlyHint": true}}
{"name": "edit_knowledge_article",
"description": "Replace article content and optionally its title. Supply the version from read_knowledge_article; concurrent changes are rejected.",
"inputSchema": {"required": ["knowledge_base_id", "article_id", "content",
"expected_version", "idempotency_key"]},
"annotations": {"readOnlyHint": false, "destructiveHint": true, "openWorldHint": true}}
{"name": "poll_resource_events",
"description": "Resume from an event sequence for one granted channel, Note, knowledge base, record, or session.",
"inputSchema": {"required": ["resource_type", "resource_id"],
"properties": {"after_sequence": {"type": "integer", "minimum": 0},
"limit": {"type": "integer", "minimum": 1, "maximum": 100}}},
"annotations": {"readOnlyHint": true}}
Kalau deskripsinya dibaca bersamaan, desainnya kelihatan dengan sendirinya. Hasil pencarian membawa ID artikel dan waktu update. Pembacaan mengembalikan "a stable citation" (sitasi yang stabil). Edit butuh "the version from read_knowledge_article" (versi dari read_knowledge_article). Lalu ada event log per knowledge base yang bisa dilanjutkan dari nomor sequence. Waktu update di sitasi dan versi yang wajib disebut saat edit, dalam praktiknya, adalah jenis nilai yang sama: client osFoundry sendiri untuk tool ini, connected-cloud-tools.ts di aplikasi desktop, memberi tipe expected_version untuk edit_knowledge_article sebagai format: date-time.
Jadi sitasi bukan cuma penunjuk untuk pembaca. Sitasi adalah cap versi yang bisa dicek agent belakangan dan, tepat setelah membaca, dikirim balik sebagai token compare-and-swap. Di bawah ini apa yang didapat dari pendekatan itu, diukur pada sebuah rebuild.
Apa yang sebaiknya ada di dalam sitasi?
Tiga kandidat:
| Sitasi | Tetap valid setelah judul diganti | Menunjukkan isi sudah berubah | Bisa dipakai sebagai versi untuk edit |
|---|---|---|---|
| Judul artikel | tidak | tidak | tidak |
| ID artikel | ya | tidak | tidak |
| ID artikel + waktu update | ya | ya | ya, kalau masih baru |
Judul adalah yang ingin dilihat pembaca manusia, jadi menggoda untuk menyitasi pakai judul saja lalu mencarinya lagi nanti. Cara itu hanya bisa mendeteksi artikel yang diganti namanya atau dihapus. Artikel yang teksnya berubah dengan judul yang sama terlihat baik-baik saja. ID mengatasi masalah ganti nama. Waktu update-lah yang membuat sitasi basi bisa dicek.
Rebuild-nya
Tidak ada binary Claude yang dijalankan di sini. kb_store.py mengimplementasikan keempat tool di atas sqlite dengan nama, argumen wajib, dan batas yang sama dengan aslinya (query 2–200 karakter, limit sampai 20 untuk pencarian dan sampai 100 untuk event). Hanya artikel yang sudah dipublikasikan yang bisa dicari atau dibaca. Bentuk JSON-nya buatan rebuild ini sendiri, karena server aslinya hanya mengembalikannya ke client yang terautentikasi. Sitasinya {knowledge_base_id, article_id, updated_at}. Setiap penyimpanan menulis event {sequence, type, article_id, updated_at}, dan edit_knowledge_article adalah compare-and-swap pada updated_at dengan tabel idempotensi, dalam satu transaksi BEGIN IMMEDIATE.
sim.py mensimulasikan satu hari kerja tim support:
- 400 artikel, 120 pertanyaan, dan 300 penyimpanan oleh orang selama 8 jam.
- Popularitas mengikuti kurva Zipf (s = 0.9). 10 artikel teratas mendapat 36.7% pertanyaan dan 36.7% penyimpanan, karena artikel yang paling sering ditanyakan orang adalah artikel yang terus diperbaiki orang.
- Dari semua penyimpanan, 85% mengubah isi, 10% juga mengganti judul, dan 5% membatalkan publikasi.
- Untuk setiap pertanyaan, "Claude" yang di-script memanggil
search_knowledge_base, membaca dua hasil teratas denganread_knowledge_article, dan menyimpan kedua sitasinya. - Setiap jam, ia mengecek semua sitasi yang sudah diberikan sejauh itu dengan tiga cara.
Seed 1–5, Python 3.9.6 di Apple M1, hanya stdlib. Seluruh run memakan waktu 25.7 s.
Seberapa cepat sitasi menjadi basi?
Lima seed, masing-masing 120 jawaban, dua sitasi per jawaban:
| Jam | Sitasi sejauh ini | Basi | Jawaban dengan sitasi basi | Terdeteksi oleh cek judul saja |
|---|---|---|---|---|
| 1 | 152 | 24 (15.8%) | 56.6% | 5 dari 24 |
| 2 | 298 | 61 (20.5%) | 61.7% | 17 dari 61 |
| 4 | 580 | 165 (28.4%) | 72.1% | 56 dari 165 |
| 6 | 914 | 250 (27.4%) | 69.4% | 84 dari 250 |
| 8 | 1,200 | 369 (30.8%) | 80.2% | 152 dari 369 |
Di akhir hari, hampir sepertiga dari semua sitasi menunjuk ke artikel yang sudah berubah sejak dibaca Claude, dan empat dari lima jawaban punya setidaknya satu sitasi seperti itu. "Berubah" bukan berarti "salah": sebuah edit bisa saja menyentuh paragraf yang tidak pernah dipakai jawaban itu. Tapi tidak ada yang bisa tahu yang mana tanpa melihat, dan waktu di dalam sitasi itulah yang memberi tahu Claude di mana harus melihat.
Sebagian besar penyebabnya adalah popularitas. Run kontrol menyebar 300 penyimpanan yang sama secara merata ke semua 400 artikel: 13.9% sitasi menjadi basi (167 dari 1,200) dan 46.7% jawaban (280 dari 600). Makin sering knowledge base kamu dipakai, makin besar kemungkinan artikel yang disitasi Claude adalah artikel yang sedang diedit.
Cek judul saja menemukan 152 dari 369 sitasi basi, 41.2%. Semuanya penggantian judul atau pembatalan publikasi. Cek ini tidak pernah melihat edit isi.
Baca ulang setiap artikel yang disitasi, atau polling log?
Biaya cek per jam sepanjang hari, dijumlahkan dari kelima seed (40 kali cek):
| Strategi | Panggilan | Data yang dikembalikan | Per cek |
|---|---|---|---|
| Cari ulang setiap judul yang disitasi | 2,426 | 3,342 KiB | 60.6 panggilan, 83.5 KiB |
| Baca ulang setiap artikel yang disitasi | 2,264 | 3,445 KiB | 56.6 panggilan, 86.1 KiB |
poll_resource_events dari cursor |
40 | 153 KiB | 1.0 panggilan, 3.8 KiB |
Kedua strategi berbasis ID menemukan persis 369 sitasi basi yang sama dengan ground truth. Script-nya memeriksa hal itu dengan assert di setiap cek. Bedanya ada di biaya. Baca ulang bertambah sesuai jumlah artikel yang sudah disitasi dan membayar teks lengkapnya setiap kali. Polling bertambah sesuai jumlah perubahan yang terjadi. Kurang dari 100 perubahan per jam muat dalam satu halaman, jadi setiap cek cukup satu panggilan, dan Claude hanya membaca ulang artikel yang berubah. Cursor-nya cuma satu integer yang disimpan antar giliran. Sebelum polling pertama, agent butuh sequence awal, yaitu 0 atau sequence terakhir yang ia simpan bersama sitasinya.
Apa yang terjadi kalau Claude mengedit dengan versi dari sitasi?
Eksperimen kedua memakai hari yang sama. Setelah setiap jawaban, Claude mengedit artikel pertama yang ia sitasi, dengan mengirim updated_at dari sitasi sebagai expected_version, setelah jeda tertentu. Lima seed, 150 edit per jeda:
| Jeda setelah membaca | Ditolak, versi sudah berubah | Ditolak, publikasi dibatalkan | Retry setelah baca ulang |
|---|---|---|---|
| 20 s | 0 (0.0%) | 0 | — |
| 15 min | 30 (20.0%) | 2 | 30 dari 30 tersimpan |
| 1 h | 57 (38.0%) | 3 | 57 dari 57 tersimpan |
| 4 h | 85 (56.7%) | 14 | 85 dari 85 tersimpan |
Sitasi adalah versi edit yang bagus selama beberapa detik dan versi yang buruk setelah satu jam. Penolakan itu tanda sistemnya bekerja: kalau tidak ditolak, setiap penulisan itu akan menimpa teks terbaru milik seseorang dengan konten yang dibangun dari pembacaan lama. Perbaikannya mekanis. Baca lagi, terapkan ulang perubahan ke isi yang ada, tulis dengan versi baru. Semua retry berhasil.
Idempotency key juga dicek. Setelah setiap edit yang berhasil, panggilan yang sama dengan key yang sama dikirim sekali lagi. 409 dari 409 mengembalikan hasil pertama yang ditandai sebagai replay dan tidak menulis event baru.
Kenapa osFoundry hanya menjawab dari artikel yang sudah dipublikasikan?
Karena sitasi seharusnya menunjuk ke sesuatu yang sudah diputuskan seseorang sebagai jawaban. Di aplikasi desktop, tab Publishing pada sebuah artikel bertuliskan "Published articles are used by this workspace's AI assistant and search. They are not visible outside the workspace." (artikel yang dipublikasikan dipakai oleh asisten AI dan pencarian di workspace ini, dan tidak terlihat dari luar workspace). Draft tidak terlihat oleh search_knowledge_base maupun read_knowledge_article, dan artikel yang publikasinya dibatalkan langsung hilang dari keduanya di panggilan berikutnya. Di rebuild, pembatalan publikasi menulis event seperti penyimpanan lainnya. 19 dari 600 edit dengan jeda di atas mengenai artikel yang publikasinya sudah dibatalkan, dan cek melaporkan sitasi seperti itu sebagai hilang, bukan berubah.
Kenapa tool edit ditandai open-world?
edit_knowledge_article adalah satu-satunya tool knowledge base dengan openWorldHint: true. Efeknya tidak berhenti di percakapan. Artikel yang disimpan menjadi sumber jawaban berikutnya untuk semua asisten dan pencarian lain di workspace. Anotasi ini memberi tahu client bahwa panggilan ini mengubah state bersama, dan Claude Code akan meminta konfirmasi sebelum menjalankannya kecuali kamu sudah mengizinkannya. osFoundry menambahkan pengaman sendiri saat chat yang terhubung bekerja dari layar Knowledge Base di dalam aplikasi: connected-browser-run.ts meminta persetujuan untuk setiap penulisan ke cloud dan tidak menawarkan izin untuk satu sesi penuh.
Kalau kamu membangunnya sendiri
- Taruh versi di dalam sitasi, jangan cuma ID. Pakai nilai yang sama dengan yang diterima tool edit kamu sebagai
expected_version, supaya satu kali baca langsung memberi keduanya. - Simpan event log per knowledge base dengan sequence yang monoton, dan biarkan agent melanjutkan dari sebuah nomor. Satu integer state di client menggantikan baca ulang semua yang pernah ia sitasi.
- Jawab hanya dari konten yang dipublikasikan, dan catat pembatalan publikasi sebagai event, supaya sitasi bisa kembali sebagai "hilang" dan bukan sekadar "berbeda".
- Jadikan edit sebagai compare-and-swap atas seluruh isi dengan idempotency key yang wajib. Tulis di deskripsi tool agar model membaca ulang sebelum mengedit, karena versi dari sitasi berumur satu jam gagal kira-kira empat dari sepuluh kali.
- Tandai tool tulis sebagai destructive dan open-world, dan pertahankan juga persetujuan per panggilan di sisi kamu.
Apa yang dimaksud osFoundry dengan retrieval dan grounding ada di entri glosarium RAG. Cara knowledge base-nya diorganisasi ada di halaman knowledge base.
Top comments (0)