2026 yılında, bir kod aracısını Obsidian kasasına bağlamak artık egzotik bir fikir değil. Muhtemelen, şu anda var olan en hafife alınan bilgi yönetimi düzenlemesi. Yine de, bunu yapan hemen hemen herkes ilk adımda takılıp kalıyor: Claude Code'u bir klasöre yönlendirip markdown dosyalarını okumasına ve yazmasına izin vermek. Çalışıyor. Ama bu sadece başlangıç ve bir sonraki adım olan MCP'nin neden önemli olduğunu anlamak, önce zaten sahip olduğumuz şeyi ve nerede bozulduğunu anlamayı gerektiriyor.
MCP olmadan zaten mümkün olan şeyler
Claude Code doğrudan bir kasayı işaret ettiğinde, dosya sistemine erişimi olan herhangi bir aracı gibi çalışır: klasör yapısını okur, ilgili içeriği bulmak için grep ve glob kullanır ve ona verdiğiniz kurallara (YAML ön yüzü, wikilinkler, içerik türüne göre klasör hiyerarşisi) saygı göstererek markdown dosyalarını yazar veya düzenler. Herhangi bir eklenti, veritabanı veya API yok: sadece düz metin ve onu muhakeme ile okuyup yazmayı bilen bir aracı.
Sistem iyi tasarlandığında sonuç, göründüğünden daha güçlüdür. Gerçek, varsayımsal olmayan bir referans olarak: yakından takip ettiğim bir kasa, tam olarak bu yöntemle, 78 ham kaynaktan (makaleler, belgeler) 180 birbirine bağlı wiki sayfasına (83'ü kavram sayfası, geri kalanı araçlar, kişiler, karşılaştırmalar ve kaynak özetleri) ulaştı ve tüm çapraz referanslar, her yeni içerik girdiğinde aracının kendisi tarafından güncelleniyor. Kimse tek bir sayfayı elle yazmadan.
Doğrudan dosya erişiminin sınırı
Ancak bu modelin yapısal bir sınırı var, sadece bir performans sınırlaması değil. Claude Code'un kasanızın nasıl organize edildiğini önceden bilmesi gerekir: hangi klasörün değişmez olduğu, ön yüz kuralının ne olduğu, kavramların araçlara kıyasla nerede yaşadığı. Pratikte her yeni kasa, sistem isteminde sıfırdan açıklanması gereken farklı bir entegrasyondur.
Ayrıca, aracı bir kasaya "ne yapma kapasiten var?" diye soramaz. Sadece zaten var olanı okuyabilir ve genel dosya işlemlerini (okuma, yazma, metinle arama) yürütebilir. Aracının her seferinde bu mantığı sıfırdan yeniden oluşturması, bağlam ve hata payını boşa harcaması gerekmeden, ona türetilmiş bir işlemi (bu notun geri bağlantı grafiğini ver, şu Dataview sorgusunu çalıştır, bana hangi sayfaların yetim olduğunu söyle) göstermenin bir yolu yoktur.
MCP'nin derinlemesine neyi çözdüğü
MCP (Model Context Protocol), Anthropic'in Kasım 2024'te tam olarak bu sorunu çözmek için başlattığı açık standarttır: yapay zeka modelleri ile harici sistemler arasındaki entegrasyon. MCP'den önce, N adet AI asistanının M farklı araca veya veri kaynağına bağlanması gerekiyorsa, N×M özel entegrasyon gerekliydi: bir uygulama Notion'ı desteklemek istediğinde sıfırdan inşa ediyordu; bir başkası aynı şeyi istediğinde yine sıfırdan inşa ediyordu. MCP bu N×M'i N+M'e dönüştürür: genel istemciler (uygulama başına bir tane) ve genel sunucular (sistem başına bir tane) inşa edilir ve herhangi bir istemci, özel bir entegrasyon olmadan herhangi bir sunucuyla konuşur.
Doğru benzetme USB-C'dir: eskiden her çevre biriminin kendi konektörü vardı; USB-C ile cihazın sadece protokolü konuşması gerekir, bir Mac'e mi yoksa bir PC'ye mi bağlı olduğunu umursamaz.
Mimarinin üç katmanı vardır. Ana bilgisayar (host), ne istendiğini yorumlayan ve harici veri veya araçlara ihtiyaç duyup duymadığına karar veren kullanıcıya yönelik uygulamadır (Claude Code, Claude Desktop veya özel bir aracı). İstemci (client), ana bilgisayarın içinde yaşar ve her sunucuyla birebir bağlantıyı yönetir, soyut istekleri somut MCP mesajlarına çevirir ve oturumun yaşam döngüsünü yönetir. Sunucu (server), protokolü gerçek bir sisteme, bu durumda bir Obsidian kasasına bağlar ve MCP isteklerini yerel işlemlere çevirir.
İki özellik bunu kozmetik bir soyutlama katmanından daha fazlası yapar. Birincisi, dinamik yetenek keşfidir: bağlantı sırasında istemci, sunucuya ne yapma kapasitesinde olduğunu sorar ve sunucu gerçek zamanlı olarak yanıt verir. Sunucu yarın yeni bir işlev eklese, istemcinin onu kullanmak için yeniden programlanması gerekmez. İkincisi, zeka ve veri arasındaki ayrıştırmadır: Obsidian için MCP sunucusunu inşa eden kişinin hangi modelin onu kullanacağını bilmesi gerekmez ve aracıyı inşa eden kişinin model değiştirdiğinde entegrasyonunu yeniden inşa etmesi gerekmez.
Bir MCP sunucusu üç tür ilkel (primitive) değişken sunar. Kaynaklar (Resources), modelin okuyabildiği ancak değiştiremediği verilerdir: bir notun içeriği, arama sonuçları, geri bağlantı grafiği. Araçlar (Tools), modelin aktif olarak çağırabildiği eylemlerdir: not oluşturma, etiket güncelleme, yapılandırılmış bir sorgu yürütme. İstemler (Prompts), yeniden kullanılabilir ve parametrelendirilebilir talimat şablonlarıdır, örneğin "bu kaynağı özetle ve ilgili wiki sayfasını oluştur" işlemini, her seferinde yeniden yazılması gereken serbest metin olarak değil, adlandırılmış bir işlem olarak sunar.
Özellikle Obsidian'a uygulandığında
Obsidian için özel olarak inşa edilmiş MCP sunucuları, açık kaynak ekosisteminde zaten mevcuttur ve genellikle Obsidian'ın kendi yerel REST API eklentisi tarafından desteklenir. Bu sunucular, aracının önceden tam klasör yapısını bilmesine gerek kalmadan, kasa üzerinde anlamsal arama, not oluşturma ve düzenleme, etiket ve meta veri yönetimi veya bağlantı grafiğini okuma gibi işlemleri sunar.
Pratikte değişen şey ince ama önemlidir: MCP olmadan Claude Code, kasanızı ona tek tek açıkladığınız kurallarla yönetir. MCP ile kasanız, Claude Code'un tıpkı bir API veya veritabanını çalıştırdığı gibi çalıştırabileceği bir araç haline gelir ve yeteneklerini önceden ezberlemek yerine bağlantı anında keşfeder. Ve aynı bağlantı, yalnızca Claude Code için değil, diğer MCP istemcileri için de çalışır: aynı sunucu, Obsidian tarafında tek bir satır kod değiştirmeden, başka bir uygulamada farklı bir aracı besleyebilir.
Pratik çerçeve: üç olgunluk seviyesi
Kendi düzeninizin nerede olduğunu belirlemek için kullandığım çerçeve şudur:
Seviye 0: bağlamın manuel olarak kopyalanıp yapıştırılması. Her konuşma sıfırdan başlar; kullanıcı notlarının ilgili parçalarını sohbete yapıştırır. Belirli görevler için işe yarar, ancak ölçeklenmez.
Seviye 1: doğrudan dosya erişimi olan aracı. Bugün Claude Code + Obsidian kurulumlarının çoğu bu seviyededir, bu makaledeki 78→180 sayfa örneği dahil. Aracı, bir talimat dosyasında açıklanan kuralları izleyerek kasayı doğrudan okur ve yazar. Zaten seviye 0'dan önemli ölçüde daha güçlüdür ve tek bir aracı tarafından yönetilen tek bir kasa için uzun süre yeterli olabilir.
Seviye 2: MCP üzerinden bağlanan aracı. Kasa, dinamik olarak keşfedilebilir yeteneklere sahip, farklı modeller ve uygulamalar arasında yeniden kullanılabilir bir sunucu olarak sunulur. Birden fazla aracı, birden fazla kasa veya dosya dosya okuma ve yazmanın ötesine geçen işlemleri sunma ihtiyacı olduğu anda mantıklı hale gelir.
Yapay zeka yönetimli bir kasadan yararlanmak için doğrudan seviye 2'ye atlamak gerekli değildir. Seviye 1, hiçbir sistemin olmamasına kıyasla zaten gerçek bir sıçramadır. Ancak MCP'nin neyi çözdüğünü anlamak, bunun nereye gittiğini anlamaktır: "yapay zekam notlarımı okuyabilir"den "bilgim, herhangi bir yapay zekanın çalıştırabileceği bir sistemdir"e.
Sizin kendi düzeniniz şu anda hangi seviyede? Yorumlarda bana söyleyin. Yeterli ilgi olursa, bir sonraki yazı Obsidian için ilk MCP sunucunuzu nasıl kuracağınıza dair adım adım bir kılavuz olacak.
Ve eğer bu sizin için faydalı olduysa, beni @chesny 'den takip edin
Bu, sistemleri okumayı bırakıp onları çalıştırmaya başlayan aracılar hakkındaki bir serinin sadece ilk makalesi.
