MCP'nin annotation varsayılanları, annotation içermeyen tool'ları örtük olarak yıkıcı hale getiriyor

Model Context Protocol spesifikasyonu, dört tool annotation'ına belgelenmiş varsayılanlar verir ve destructiveHint için bu varsayılan true'dur. 12 Eylül 2026'da yayımlanan bir dev.to analizi, bunun pratikte ne anlama geldiğini ele alıyor: Annotation olmadan yayımlanan bir MCP tool'u, davranışı konusunda tarafsız kalmış değildir. Şemanın kendi varsayılanlarına göre, tool kendisini fiilen salt-okunur değil, yıkıcı, idempotent olmayan ve açık dünya olarak ilan etmiştir.

Spesifikasyon ne diyor

dev.to yazısına göre, 2026-07-28 tarihli şemadaki (commit 271ecc9) ToolAnnotations arayüzü, varsayılanlara sahip dört boolean tanımlar. readOnlyHint eksik olduğunda, istemci tool'un ortamını değiştirdiğini varsaymalıdır. destructiveHint eksik olduğunda, tool yıkıcı güncellemeler yapabilir. idempotentHint eksik olduğunda, çağrıyı tekrarlamak daha fazla etki yaratır. openWorldHint eksik olduğunda, tool harici varlıklarla etkileşime girer.

Ancak bu arayüzün hemen üzerinde, tüm annotation özelliklerinin yalnızca ipucu olduğu, tool davranışının garanti edilmiş bir tanımı olmadığı ve istemcilerin asla güvenilmeyen sunuculardan gelen annotation'lara dayanarak tool kullanım kararları vermemesi gerektiğini belirten bir not bulunur. Şema böylece, aynı anda istemcilere güvenmemelerini söylediği alanlara varsayılanlar sunar ve bu iki yarım arasındaki boşluk sorunun kalbidir.

Bir ihmal, iki yorum

Bu, aynı sessizliğin iki meşru yorumunu bırakır. Belgelenmiş varsayılanları uygulayan bir istemci, annotation içermeyen bir tool'u yıkıcı olarak kapıya takacaktır. Eksik nesneyi bilgi eksikliği olarak okuyan bir istemci ise aynı çağrıyı doğrudan geçirecektir. İki istemci de hatalı davranmıyor.

Ayrıca ikinci dereceden bir kural daha vardır: destructiveHint yalnızca readOnlyHint false olduğunda anlam taşır. readOnlyHint true beyan eden ve destructiveHint'i atlayan bir tool doğru şeyi yaparken, hiçbir şey beyan etmeyen bir tool, readOnlyHint'in false varsayılanına düşer ve bu da destructiveHint'in true varsayılanını devreye sokar. Aynı ihmal bir durumda temiz, diğerinde yüklüdür ve onları ayıran şey, tool'un aynı şekilde boş bıraktığı ikinci bir alandır.

Sayım ne buldu

dev.to analizi bunu, atıf yaptığı iki saha raporuna sabitler. Eugeniya Ivanova'nın 7 Eylül tarihli, ChatGPT uygulama dizini incelemesini geçme rehberi, spesifikasyonun isteğe bağlı olarak işaretlediği annotation değerlerini açıkça isteyen bir tarayıcıyı anlatır; o, dört salt-okunur tool'a destructiveHint false ekleyerek ve yaklaşık kırk değer için gerekçeler yazarak, tool'ların kendisini değiştirmeden işi çözdü. 30 Ağustos'ta Himanshu Kumar, altı tool'a sahip konuşlandırılmış bir sunucuyu denetledi ve hiçbiri herhangi bir annotation beyan etmiyordu — değerlendirmesi, sunucunun yalan söylemediği, yalnızca sessiz kaldığı yönündeydi.

Yazar daha sonra, 7 Eylül 2026'da incelenen yedi kaynak ağacındaki her dosyada dört alan adının büyük-küçük harf duyarsız geçişlerini saydı. Referans modelcontextprotocol/servers deposu düzinelerce geçiş içeriyor (dört alan boyunca 61, 51, 51 ve 60). supermemoryai/supermemory her birinden altışar, mem0ai/mem0 neredeyse hiç göstermiyor ve dört ağaç — getzep/zep, getzep/graphiti, topoteretes/cognee ve MemoriLabs/Memori — MCP sunucuları içermelerine rağmen hiçbir alan adının geçişini içermiyor: zep 13 tool kaydeder, graphiti 13 çıplak @mcp.tool() dekoratörü açığa çıkarır ve Memori'nin sunucusu da sıfır okunan ayrı bir depoda yaşıyor.

Sayım dürüst uyarılarla geliyor. Supermemory'nin altı sayısı, on beş tool dosyası tarafından içe aktarılan dört hazır sabiti yansıtır; dolayısıyla literal sayım, annotation'lı tool'larını yaklaşık iki buçuk kat az sayar. Mem0'nun eksik destructiveHint'i aslında doğrudur, çünkü tek tool'u readOnlyHint true beyan eder ve alan bu durumda anlamsızdır. Graphiti en çarpıcı örnektir: on üç annotation'sız tool, hem açıkça yıkıcı işlemleri (clear_graph, delete_entity_edge, delete_episode) hem de açıkça güvenli olanları (search_nodes, get_episodes, get_status) kapsar. Varsayılanlara uyan bir istemci on üçünün hepsini aynı şekilde ele alır — ilk grup için doğru, ikinci grup için yanlış.

Pratik çıkarım, kaynak kodun iletim hattı olmadığıdır: Yazı, çalışan bir sunucunun tools/list yanıtını yoklamayı öneriyor — stdin üzerindeki üç JSON-RPC satırı bunu ortaya çıkaracaktır — böylece her tool'un gerçekte hangi alanları atladığı görülebilir.

Neden önemli

Ajan geliştiricileri için sezgiye aykırı olan kısım şudur: Annotation yayımlamak güvenli, minimal bir seçim değildir — belgelenmiş varsayılanlar altında bu, mümkün olan en yüksek sesli beyandır; yıkıcılık, idempotent olmama ve açık dünya erişimi iddia eder. İstemciler ve inceleme tarayıcıları varsayılanları uygulamaya başladıkça, annotation'sız her salt-okunur tool'un kapıya takılması ya da tehlikeli olarak gösterilme riski taşır. Öte yandan, spesifikasyon istemcilere güvenilmeyen sunuculardan gelen annotation'lara güvenmemelerini söylediği için, geliştiriciler ipuçlarının hiç uygulanacağına güvenemez. Ucuz çözüm, dört alanın tamamını her tool üzerinde açıkça beyan etmektir; bu, istemci hangi yorumu uygularsa uygulasin belirsizliği ortadan kaldırır.