ChatGPT uygulama dizini MCP server reddi: Sorun metadata ve inceleyen kişinin girişinde çıktı

Neredeyse hiç değişmeyen bir server için bir aylık inceleme

Eugeniya Ivanova'nın dev.to'daki birinci ağızan anlatımına göre, çalışan bir MCP server'ını ChatGPT'nin uygulama dizinine eklemek gibi rutin görünen bir işlem, 24 Ağustos'ta red ve 4 Eylül'de onayla sonuçlanan bir aylık bir sürece dönüştü. Dikkat çekici olan şu: düzeltmelerin neredeyse hiçbiri server'ın gerçek işlevselliğine dokunmadı. Emek, ChatGPT'nin tool'ları nasıl keşfettiğine, OpenAI'nin scanner'ının ne beklediğine, uygulamanın nasıl tanımlandığına ve bir inceleyicinin fiilen oturum açıp açamayacağına gitti.

Tool keşfi kimlik doğrulamadan önce çalışmak zorunda

İlk sorun gönderimden önce ortaya çıktı. Server bağlandığında ChatGPT connector'ı oluşturdu fakat hiçbir eylem bulunmadığını bildirdi; oysa aynı tool'lar Claude ve Cursor'da sorunsuz yükleniyordu. Caching ve SSE araştırıldı, elendi. Gerçek neden: server, tools/list isteğinin kendisi için token istiyordu. Claude önce kimlik doğrulaması yapıp sonra listeyi çekiyor, bu yüzden orada çalışıyordu. ChatGPT ise listeyi yetkilendirmeden önce çekiyor, boş bir sonuç alıyor ve uygulama kilitleniyor — refresh devre dışı, save gri — tek çıkış yolu silip yeniden oluşturmak kalıyor. Ivanova'nın yeni uçuş öncesi kuralı: tools/list, token olmadan tool'larla birlikte 200 dönmeli.

Scanner, spesifikasyonun opsiyonel bıraktığı annotation'ları istiyor

OpenAI'nin scanner'ı her tool'u inceleyip readOnlyHint, openWorldHint ve destructiveHint için açık değerler istedi. Dört salt-okunur tool'da destructiveHint eksikti; MCP spesifikasyonuna göre savunulabilir bir durum, çünkü bu hint yalnızca readOnlyHint false iken anlamlı. Scanner buna rağmen istedi; ekip destructiveHint: false ekledi ve yaklaşık kırk annotation değeri için gerekçeler yazdı. Tool'ların kendisi değişmedi.

Format tuhaflıkları olan bir domain doğrulaması

Domain doğrulaması, endpoint'in çıplak bir token string'i döndürmesini bekliyor — JSON sarmalayıcı yok, tırnak işareti yok. Ayrıca tek seferlik bir kontrol değil: endpoint üretimde kalmalı ve sonrasında da aynı şekilde yanıt vermelidir. Ekip artık OpenAI istediğinde bu string'i döndürmekten başka kalıcı bir görevi olmayan küçük bir endpoint sürdürüyor.

Tanım kayması gerçek bir hataydı, sadece server'da değil

Bulgulardan biri gerçekten ekibin kendi hatasıydı. Herkese açık repo 18 tool tanımlarken canlı server 16 tanesini sunuyordu ve repoda bulunan dört LinkedIn analytics tool'u MCP üzerinden hiç sunulmuyordu. Uygulama tanımı repoya dayandığından, MCP kullanıcılarının fiilen erişemediği analytics özellikleri vaat ediyordu. Ivanova bunları tanımdan ve sürüm notlarından çıkardı, ardından aynı bayat metni bir Zed extension'ın README'sinde ve Docker MCP Catalog için açık bir pull request'te buldu — Zed PR'si düzeltme öncesi bir commit'e atıf yapıyordu, yani birleştirilseydi güncel olmayan iddiayı başka bir kataloğa taşıyacaktı.

Red, inceleyicinin girişine kadar geldi

Uygulama 5 Ağustos'ta, sihirbazın tüm adımları tek seferde tamamlanarak gönderildi ve 24 Ağustos'ta, oturum açma veya OAuth akışının tamamlanamadığını belirten ve ek kurulum ya da doğrulama gerektirmeyen geçerli kimlik bilgileri isteyen bir mesajla reddedildi. Yeniden test hiçbir sorun göstermedi: dynamic client registration 201 döndürüyordu, /authorize onay ekranına ulaşıyordu, oturum açma sayfası captcha'sız düz bir e-posta ve parola formuydu, kimlik doğrulamasız tools/list tool'ları döndürüyordu ve API ile MCP erişimi ücretsiz katman dahil her planda açıktı.

Gerçek sorun, inceleyiciye verilen hesaptı. Ekibin kendi hesapları Google ile oturum açmayı kullanıyordu ve ikinci faktör telefonlarına düşüyordu — yabancı birinin kullanamayacağı kimlik bilgileri. Daha önceki iki Canva reddi de aynı nedenden dolayı başarısız olmuştu; yazar bunun bir sinyal olması gerektiğini kabul ediyor.

Onayı sağlayan şey neydi

Ekip, inceleyici için önceden doğrulanmış, e-posta ve parolayla giriş yapılan, kanalları bağlı ve halihazırda birkaç gönderi ile taslak bulunan özel bir hesap oluşturdu. Ayrıca sekiz test vakası sundular; beşi pozitif, üçü negatif. En faydalısı, sahte bir yayın hedefi üzerinden tam bir yazma yolu testiydi: gönderileri gerçek kurallarla aynı kurallara göre doğruluyor, aynı türde yanıt döndürüyor ve isteği herhangi bir yere yayınlamak yerine çöpe atıyor — yaklaşık otuz satır kod. Ivanova, bu düzeltmelerin çoğunu Claude'nun yardımıyla yazdığını, kendisinin kontrol ettiğini ve neyin değiştiğine karar verdiğini belirtiyor. Yeniden gönderim 24 Ağustos akşamı yapıldı; onay 4 Eylül'de geldi.

Neden önemli

MCP hızla bir dağıtım kanalına dönüşüyor ve ChatGPT'nin dizini, protokol spesifikasyonunun üzerine app-store tarzı bir inceleme uyguluyor. Bu anlatım, incelemeden geçmenin protokol doğruluğundan çok istemciye özgü davranışlara bağlı olduğunu gösteriyor: kimlik doğrulamadan önce keşif, spesifikasyonun ötesine geçen scanner dayatmalı metadata, titiz doğrulama formatları ve siz olmayan biri için çalışan bir inceleyici deneyimi. Ayrıca daha sessiz bir operasyonel riski de örneklendiriyor: bir ürünün tanımları repolara, extension README'lerine ve katalog gönderilerine yayıldıkça, ürünün fiilen sunduğundan uzaklaşıyor — ve inceleyiciler bunu fark edecek. Ivanova'nın gelecek sefere özet kontrol listesi basit: ürünü sizin gibi değil, inceleyici gibi gezinin.