50 MCP aracı yazarken fark ettiklerim: fonksiyon çağrısı alışılmadık derecede yakın bir ilişkiymiş

Hafta sonu iki gün boyunca varlık yönetimi aracını SQLite tabanlı bir CLI ve MCP sunucusuna taşıma deneyimine
dayanarak, MCP araç tasarımının RPC’den belirleyici olarak nerede ayrıldığını derleyen bir yazı.
Yazar, 30’dan fazla CLI komutu ve 50’den fazla MCP aracı yazdı; ama hacim bunun tersini düşündürse de
en uzun süre uğraştığı şeyin kod değil, fonksiyon açıklamaları olduğunu fark etmesiyle söze başlıyor.

• Aynı fonksiyon CLI ve MCP’ye aynı anda açıldığında, imza/argümanlar/dönüş değerleri tamamen aynı olmasına rağmen iki arayüz farklı davrandı. Değişen tek şey çağıranın insan mı LLM mi olduğuydu
• İmza, bir fonksiyonun neyi aldığını açıklar; ama ne zaman çağrılması gerektiğini neredeyse hiç açıklayamaz. Fonksiyon adı sözlükteki tek satıra daha yakındır; bu yüzden kelimenin kendisi hangi cümlenin üstüne yerleşeceğini belirleyemez
• LLM çağıran için tek sorumluluk ilkesine (SRP) göre ince ince bölünmüş araçlardan çok, niyete doğrudan temas eden ağır araçlar daha doğaldır
• MCP, biçim olarak bakıldığında RPC soyuna aittir (JSON-RPC, imzalar, şemalar); ama belirleyici fark, güvenin yönünün tersine dönmesidir. RPC’de çağıran, çağrılanı güvenir; MCP’de ise aracı yapan tarafın çağırana (LLM’ye) güvenmesi gerekir
• İmza bir beyan, açıklama ise bir ricadır. Biri zorlayıcıdır, diğeri ikna edicidir. Araç tasarımına ikna dili girmeye başlamış durumda
• Bu yeni bir değişimden çok bir gerilemeye değil, bir geri dönüşe daha yakındır. Endüstriyel tasarım, mimarlık ve UX zaten uzun zamandır aynı yerdeydi; programlama ise şimdiye kadar alışılmadık derecede yakın olan uçta kalmıştı

İmzanın söylemedikleri

• Firma’nın add_txn (işlem), add_balance (varlık anlık görüntüsü), add_flow (gelir/gider) fonksiyonlarının imzaları son derece açıktı ve argüman tipleri de zod şemalarıyla sıkı biçimde tanımlanmıştı; buna rağmen LLM, kullanıcının ifadesinden hangi aracı çağırması gerektiğini sık sık karıştırdı
• Başta bunun LLM modelinden kaynaklandığı düşünüldü; ama asıl sorun imzanın kendisindeydi. add_txn adı, “kullanıcı alım satımdan söz ettiyse bu aracı kullan” gibi çağrı zamanını içinde barındırmıyor
• Açıklama kısmı "Use this when... Do NOT use this for..." biçiminde, çağrı zamanı ve diğer araçlarla sınırlar açıkça belirtilecek şekilde yazıldıktan sonra çağrılar ancak istikrar kazandı
• Fonksiyonun niyeti imzadan fonksiyon açıklamasına kaymış oldu. Çekiç sapı kullanım şeklini biçimiyle ima ettiği gibi, MCP fonksiyonunun açıklaması da LLM için fiilen aracın affordance’ına (Donald Norman) karşılık geliyor

SRP vs affordance ve güvenin yönü

• Başta tek sorumluluk ilkesine göre get_holdings, get_prices, get_pnl gibi küçük parçalara ayırmak istendi; ama kullanıcı “Portföyüm nasıl?” diye sorduğunda LLM’nin dört beş çağrıyı birleştirmesi gerekiyor, yanıt yavaşlıyor ve sapma ihtimali büyüyordu
• Sonunda show_portfolio, elde tutulan varlıklar/ortalama alış fiyatı/güncel fiyat/değerleme tutarı/birikimli kâr zarar bilgisini tek seferde döndüren ağır bir araç olarak tasarlandı. get_brief ise daha da ileri gidip makro göstergeler ve içgörüleri de tek seferde döndürüyor
• SRP, fonksiyon yazanın erdemidir; affordance ise aracı kullananın erdemidir. Çağıran insan olduğunda birleştirme yapılabilir; LLM olduğunda ise niyete doğrudan temas eden araç daha iyidir
• Yazma araçlarında güvenin yönü en net biçimde ortaya çıkıyor. add_txn içine "Always confirm with the user before recording" yazılınca LLM her seferinde sordu, kullanıcı da her seferinde “tamam” diye yanıtladı — doğal dil arayüzünün avantajı ortadan kalktı
• Sonunda sorumluluk yeniden "hemen kaydet, yalnızca belirsiz olduğunda sor, hata olursa geri alınabilir" şeklinde paylaştırıldı. Bu tür yönergeler aracın biçimsel açıklaması değil, çağırana verilen operasyon ilkeleri

Belki de fonksiyon çağrısı baştan beri istisnai bir durumdu

• İnsanlar aslında hep kendi yapmadıkları araçları kullandı. Çömlekçinin yaptığı kap, demircinin yaptığı bıçak, geliştiricinin yaptığı program; hepsi buna örnek
• Fonksiyon çağrısı ise çağıranla yazanın çok fazla bağlam paylaştığı, tip sistemi/IDE/dokümantasyonun da bu yakınlığı sürekli pekiştirdiği oldukça özel bir ilişki olabilir
• Çağıran insan değilse iki seçenek var. (1) LLM’ye daha fazla bağlam verip onu yakın bir çağıran haline getirmek, (2) araç tarafında bu mesafeyi kapatmak. MCP ikincisine daha yakın
• Arayüz tasarlama biçiminin kendisi sessizce değişiyor olabilir. Ağırlık merkezi imzadan açıklamaya, zorlamadan iknaya, yakınlık varsayımından mesafeyi kabul etmeye doğru kayıyor