Bir dil modeliyle uçak bileti aramayı deneyin. Model size on iki uçuşu düz metin olarak sıralar. Sonra siz "sadece sabah kalkanları göster" dersiniz, model listeyi yeniden yazar. Sonra "fiyata göre sırala" dersiniz, bir daha yazar.
Her filtreleme bir model çağrısı, her çağrı birkaç saniye ve yüzlerce token. Oysa bu iş için yirmi yıldır bir çözümümüz var: tablo başlığına tıklamak.
MCP Apps tam olarak bu boşluğu kapatıyor. 28 Temmuz 2026 spesifikasyonunun sürüm adayı, bu resmî uzantıyı yeni uzantı çerçevesinin önemli örneklerinden biri olarak öne çıkarıyor. Çünkü "AI sohbeti" ile "gerçek uygulama" arasındaki sınırı değiştiriyor.
Ne yapıyor
Kısaca: MCP sunucusu, tool sonucuyla birlikte bir HTML arayüzü gönderebiliyor. Host uygulama bunu sandbox'lı bir iframe içinde render ediyor.
Yani ucus_ara tool'u artık metin döndürmek zorunda değil. Sıralanabilir, filtrelenebilir, seçilebilir bir tablo döndürebiliyor. Kullanıcı üzerinde çalışıyor, modele hiç uğramadan.
Bu, ilk duyduğumda beni rahatsız etti. "Sunucu bana HTML gönderiyor ve ben çalıştırıyorum" cümlesi, güvenlik açısından kulağa kötü geliyor. Tasarımın nasıl bu endişeyi karşıladığına birazdan geleceğim, çünkü işin en düşündürücü kısmı orası.
Neden metin yetmiyordu
Temel MCP spesifikasyonu metin ve yapılandırılmış veriyle sınırlıydı. Bu, bir yıl boyunca üç somut sorun üretti.
Etkileşim maliyeti. Yukarıdaki uçuş örneği. Kullanıcının yapmak istediği her küçük ayar, bir model turu demek. Hem yavaş hem pahalı.
Veri yoğunluğu. Kırk satırlık bir tabloyu metin olarak modele koyup modelden size aktarmasını istemek, hem token israfı hem de okunması zor bir çıktı. Grafik gerektiren hiçbir şey mümkün değildi.
Form doldurma. Elicitation ile basit sorular sorabiliyordunuz ama sekiz alanlı bir sipariş formunu sohbet üzerinden doldurmak işkenceydi.
Ekosistem bu boşluğu kendi başına doldurmaya çalıştı. mcp-ui projesi topluluk tarafında yaygınlaştı ve MCP Apps aslında onun üzerine inşa edildi. Yani bu, masa başında tasarlanmış bir özellik değil, sahadan gelen bir ihtiyacın standartlaştırılmış hali.
Tasarımın kritik detayı: şablonlar önceden bildiriliyor
İşte güvenlik endişesine verilen cevap.
Tool'lar kullanacakları UI şablonlarını önceden beyan ediyor. Host, çalıştırma anında değil, önceden bu şablonları çekebiliyor, önbellekleyebiliyor ve güvenlik incelemesinden geçirebiliyor.
Bu ayrım önemli. "Sunucu her çağrıda bana rastgele HTML gönderiyor" ile "sunucunun gönderebileceği arayüzler bellidir ve önceden denetlenebilir" arasında dağlar kadar fark var. İkincisi, kurumsal bir güvenlik ekibinin onaylayabileceği bir model.
Pratik sonuçları:
- Host, şablonu bir kez indirip önbelleğe alabiliyor, her çağrıda ağdan çekmiyor
- Kurumsal bir dağıtımda güvenlik ekibi şablonları statik olarak inceleyebiliyor
- Bir şablon değiştiğinde bu bir sürüm değişikliği olarak görülebiliyor, sessiz bir davranış değişikliği olarak değil
İkinci kritik detay: her eylem aynı onay yolundan geçiyor
Render edilen arayüz, host ile MCP'nin her yerinde kullanılan aynı JSON-RPC temel protokolü üzerinden konuşuyor.
Bu cümlenin altını çizmek istiyorum, çünkü kolayca gözden kaçıyor ama tasarımın belkemiği burası.
Arayüzdeki bir butona tıkladığınızda, o eylem kendi özel kanalını kullanmıyor. Doğrudan bir tool çağrısıyla tamamen aynı denetim ve onay yolundan geçiyor. Yani:
- Aynı loglama
- Aynı yetkilendirme kontrolü
- Aynı kullanıcı onayı istemleri
Alternatif tasarımı düşünün: iframe'in kendi API'sine doğrudan bağlanabildiği bir dünya. O dünyada denetim izinizde bir delik açılırdı ve "modelin yaptığı işlem" ile "arayüzün yaptığı işlem" ayrı kategoriler haline gelirdi. Bu tasarım o deliği baştan kapatıyor.
Ne inşa edilir
Aklıma gelen ve Türkiye pazarında doğrudan karşılığı olan senaryolar:
Sipariş ve stok yönetimi. Bayi "elimde ne var" diye soruyor, karşısına filtrelenebilir bir stok tablosu geliyor. Ürünleri seçip sepete atıyor. Sepet onayı bir tool çağrısına dönüşüyor.
Randevu ve rezervasyon. Takvim arayüzü, bir metin listesinden karşılaştırılamayacak kadar iyi. "Bu hafta hangi saatler boş" sorusunun cevabı bir ızgara olmalı, cümle değil.
Rapor ve gösterge panelleri. Satış müdürü "geçen çeyrek nasıl geçti" diye soruyor. Model yorumu yazıyor, arayüz grafiği gösteriyor. İkisi birlikte, ayrı ayrı olduğundan çok daha iyi.
Uzun formlar. Sigorta teklifi, kredi başvurusu, servis kaydı. Modelin bildiği alanları önceden doldurulmuş halde gösteren bir form, sohbet üzerinden alan alan sormaktan hem hızlı hem az hatalı.
Veri doğrulama ve düzeltme. Model bir belgeden veri çıkarıyor, arayüz bunu düzenlenebilir bir tabloda gösteriyor, kullanıcı yanlışları düzeltip onaylıyor. Bu desen, belge işleme projelerinin çoğunda ihtiyaç duyulan ama sohbet arayüzünde bir türlü kurulamayan şeydi.
Ürün tarafında ne değişiyor
Burada teknik olmayan ama önemli bir mesele var.
MCP Apps'ten önce, bir MCP sunucusu yazmak bir "entegrasyon" işiydi. Sunucunuz veri sağlıyordu, kullanıcı deneyimini host uygulama belirliyordu. Sizin ürününüzün ekranı yoktu.
Şimdi ekranınız var. Bu, MCP sunucusu yazan şirketler için konumlanma açısından ciddi bir değişiklik. Ürününüzün markası, kullanım akışı ve tasarım dili, kullanıcı Claude Desktop'ta otururken bile görünür oluyor.
Türkiye'de SaaS satan şirketler için düşünmeye değer bir soru: müşterileriniz sizin web panelinize girmek yerine kendi AI asistanları üzerinden sisteminizi kullanmaya başlarsa ne olur? MCP Apps, bu geçişte ürününüzün tamamen görünmez bir arka uca dönüşmesini engelleyen şey.
Ne zaman kullanmamalı
Her tool sonucu arayüz olmak zorunda değil. Aşırıya kaçmak kolay.
Sonuç tek bir değerse metin bırakın. "Bugünkü dolar kuru" için tablo render etmeyin.
Kullanıcının yapacağı tek şey okumaksa metin bırakın. Etkileşim yoksa arayüzün kattığı değer yok, sadece render maliyeti var.
Model çıktıyı işleyip üzerine akıl yürütecekse, yapılandırılmış veri dönmeye devam edin. Arayüz kullanıcı içindir, model için değil.
Pratik olarak nasıl başlanır
MCP Apps bir uzantı, çekirdek spesifikasyonun parçası değil. Uzantılar artık ters DNS kimlikleriyle tanımlanıyor, istemci ve sunucu yeteneklerindeki extensions haritası üzerinden anlaşılıyor ve spesifikasyondan bağımsız versiyonlanıyor. Kendi ext-* depolarında, kendi bakımcılarıyla yaşıyorlar.
Bunun pratik anlamı: MCP Apps'i benimsemek için spesifikasyon sürümü beklemenize gerek yok, ve benimsememek de sizi geride bırakmıyor. İstemciniz uzantıyı desteklemiyorsa, sunucu normal tool sonuçlarına düşmeli. Bu geri düşme yolunu baştan tasarlayın.
Başlangıç için önerim:
- Mevcut tool'larınızdan hangisinin çıktısı bir tablo veya liste, onu belirleyin
- O tool için basit, tek dosyalık bir HTML şablonu yazın. Framework getirmeyin, sandbox içinde çalışıyorsunuz ve yükleme süresi doğrudan kullanıcı deneyimi
- Arayüzden yapılan her eylemi bir tool çağrısına bağlayın, kısayol aramayın
- Uzantıyı desteklemeyen istemciler için metin çıktısını koruyun
Kapanış
MCP'nin ilk iki yılı, dil modellerine veri ulaştırma problemiyle geçti. O problem büyük ölçüde çözüldü.
Şimdi sıradaki soru şu: kullanıcı o veriyle ne yapacak? Metin olarak okuyup üzerine cümle mi kuracak, yoksa dokunup çalışacak mı?
MCP Apps ikinci cevabı mümkün kılıyor. Sohbet arayüzünün her şeyi çözeceği fikrinden vazgeçip, doğru işe doğru arayüzü koyma fikrine geçiyoruz. Bence doğru yön.
MCP Apps ile bir şey inşa ettiyseniz duymak isterim. Özellikle form ve tablo senaryolarında karşılaştığınız sınırları merak ediyorum.