Özellik algılama yalan söylüyor: WebMCP üzerinde ürün çıkarmaktan elde edilen pratik dersler

Deney neydi

dev.to'da bir yazıya göre bir geliştirici, bir web sayfasının bir yapay zekâ ajanına document.Context aracılığıyla tipli bir araç listesi verebilmesini sağlayan yeni standart WebMCP üzerine sekiz gün harcayarak bir parlamento prosedürü motoru inşa etti. Tasarım ilkesi alışılmadıktı: sırası gelmemiş bir eylem yalnızca gri renkte gösterilmemeli ya da runtime'da reddedilmemeliydi. getTools() listesinde tamamen bulunmamalı ve onu kaldıran kural boş yerin yanında gösterilmeliydi. Yazarın belirttiğine göre ilginç arızalar ancak bitmiş uygulama, kontrolünde olmadığı bir istemcide — ChatGPT'nin uygulama içi tarayıcısında — çalıştığında ortaya çıktı.

Varlık, yetenek değildir

İlk ders özellik algılamayla ilgili. En bariz kontrol — modelContext nesnesi üzerinde registerTool aramak — yalnızca özelliğin var olduğunu doğrular. Onu çağırmanın işe yarayıp yaramadığı ya da aynı arayüzden sarkan diğer yetenekler hakkında hiçbir şey söylemez.

ChatGPT'nin uygulama içi tarayıcısında dönen modelContext araçları kaydeder ve getTools()'u doğru yanıtlar, ama bir EventTarget değildir. toolchange olayı için addEventListener çağırmak bir TypeError fırlatır. Değişiklik olaylarına abone olmanın, araç kaydetmekten ayrı bir yetenek olduğu ortaya çıkar ve nesnenin biçimi hakkında hiçbir şey sizi uyarmaz.

Arıza modu çirkindi: istisna sayfa boyandıktan sonra düştü, yani uygulama tamamen render edildi ve sonra başlayamadığını duyurdu — canlı göründü, sonra kendini bozuk ilan etti. Düzeltme, her yeteneği kendi başına isteğe bağlı saymak, kendi try/catch bloğuna sarmak ve sonucu arayüzde belirtmekti. Uygulamanın durum bandı artık araçların kayıtlı olduğunu ama bu istemcinin modelContext'inin bir EventTarget olmadığını, dolayısıyla toolchange olayları olmadığını bildiriyor. Yazarın argümanı, kullanıcılara hangi mekanizmanın uygulamayı taşıdığını söylemenin sessiz bozulmadan iyi olduğudur.

Bildirimsel araçlar asenkron yerleşir

WebMCP'nin bildirimsel bir biçimi de var: bir form elemanına toolname özniteliği ekleyin ve tarayıcı onu bir araç olarak benimser; özniteliği kaldırmak aracı kaldırır. Yazarın uygulaması bilinçli olarak her iki mekanizmayı da kullandı, böylece tek bir durum değişikliği bir AbortSignal'i iptal ederek yedi aracı ve bir özniteliği silerek sekizinci aracı düşürebiliyordu.

Ama benimseme, tarayıcı DOM değişikliğini fark ettiğinde gerçekleşir ve await edilecek bir promise yoktur. toolchange'in tetiklendiği yerde bu görünmezdir — olay size araç yüzeyinin yerleştiğini söyler ve yeniden render edersiniz. Olay olmadığında, durum değişikliğini izleyen render getTools()'u bir tick erken okudu: panel 16 araç diyordu, API 17 diyordu ve tutarsızlık dört saniye sonra hâlâ ekrandaydı. Panel içindeki kayıtlardan değil getTools()'tan çizildiği için, bu tam olarak ürünün imkânsız olduğunu iddia ettiği sapmaydı.

Await edilecek bir şey olmadığından geçici çözüm polling: olay kullanılamıyorsa, sayı durana kadar her 50 milisaniyede bir getTools()'u yeniden kontrol etmek, en fazla on iki deneme (yaklaşık 600 milisaniye) ve yalnızca olay yokken kullanmak. Düzeltmeyi doğrulamak için yazar, yerel bir derlemeyi canlı origin altında servis etti — böylece origin-trial token hâlâ geçerliydi — ve istemcinin biçimini yeniden üretmek için modelContext'ten addEventListener çıkarıldı. Her iki biçim de ardından dört kontrol noktasında aynı araç sayılarını döndürdü; sıfır sapma ve sıfır sayfa hatasıyla.

Yukarı akışta zaten çözülmüş bir hata

Üçüncü sorun Chrome tarafında. Chrome 151'de executeTool'un ikinci argümanı bir JSON string'i olmalı; IDL'nin belirttiği nesneyi geçirmek, girdi argümanlarını ayrıştıramama konusunda bir hata döndürüyor. Bu, WebMCP deposunda yukarı akışta çözüldü; 243 numaralı issue 2026-08-17'de tamamlandı olarak kapatıldı, ama Chrome çözümü henüz sevk etmedi. Yazıdaki pratik tavsiye: string'i gönderin, nesne yolunu yedek olarak tutun; hem bugün hem de Chrome yakınsadığında doğru olursunuz.

Sayılar ve bir ürün dersi

Yazı ayrıca yayındaki uygulamadan ölçümler bildiriyor: getTools() ile ekranda gösterilen arasında 90 karşılaştırma, sıfır sapma; getTools() gidiş-dönüşleri p50 0.20 ve p95 0.30 saniye; ve 306 birim testi — tüm 152 geçerlilik hücresi dahil (7 aşama × 19 kapılı araç) — uygulamaya karşı değil kural tablosuna karşı doğrulandı.

Teknik olmayan ders daha pahalıya mal oldu. Yazar onu site yönetim kurulu üyesine sorunun gerçek olup olmadığını sordu. Altısı hayır dedi — bilinçli olarak katı Robert's Rules'ten kaçınıyorlar ve kural kitabının kendisi kabaca on iki üyeden küçük kurullar için prosedürü gevşetiyor, bu da çoğu site yönetim kurulunu kapsıyor. Gerçek kullanıcı, milyonlar yöneten bir birlikten tek bir sekreter çıktı; her öneriyi ve her üyenin oylunu isimle kaydediyor. Yayınlamadan önce yazarın elinde olmayan kanıtlarla desteklenen, daha dar bir hedef kitle.

Neden önemli

WebMCP hâlâ gelişmekte olan bir standart ve bu, sayfanızın tüketicisi kontrolünüzdeki olmayan bir tarayıcı içindeki bir yapay zekâ ajanıyken web platformu için inşa etmenin ne demek olduğuna dair faydalı bir saha raporu. Her iki teknik ders de WebMCP'nin ötesine geneller: bir varlık kontrolü bir yeteneğin çalıştığını kanıtlamaz ve tek bir arayüzden geliyormuş gibi görünen yetenekler — araç kaydetmek ile değişikliklere abone olmak — birbirinden bağımsız başarısız olabilir. Bugün modelContext üzerine inşa eden herkesin yetenek bazında algılama, dürüst bozulma mesajları ve — bildirimsel benimseme await edilebilir hale gelene ya da olay desteği evrensel olana kadar — sınırlı bir uzlaştırma döngüsüne ihtiyacı var. Benchmarklar ayrıca standardın temel vaadinin — ekran API ile anlaşamaz — ancak aktif olarak savunursanız geçerli olduğunu gösteriyor.