MCP Sunucuları için CI Kontrolleri: Basit Liste Kontrolü Yeterli Değil

MCP sunucuları, artık sıradan altyapı bileşenleri gibi davranmaya başladı. Bu da onlar için basit varlık testi yerine, daha derinlemesine altyapı kontrollerinin gerektiği anlamına geliyor.

Ancak birçok geliştirici, MCP sunucularını test ederken hâlâ temel bir hata yapıyor: Sunucu başlatıldığında tools/list komutu temiz bir şema döndürüyor, o zaman her şey yolunda demektir.

Oysa bu yanıltıcı olabilir. Bir MCP sunucu initialize işlemini başarılı bir şekilde geçebilir, tüm beklenen araçları tanıtabilir ve yine de gerçek çağrıları her seferinde başarısızlığa uğratabilir. Yetkilendirme sorunları, kapsam sınırlamaları, ortam değişkenleri, aşağı akış izinleri veya salt okunur roller, herhangi bir anda hatalara neden olabilir.

Bu sorunları erkenden tespit etmek için mcp-probe@1.8.0 aracı, MCP sunucularını CI sürecinde daha güvenilir şekilde denetlemek amacıyla önemli iyileştirmeler aldı. Bu güncelleme, gerçek üretim senaryolarını simüle eden ve yalnızca süreçlerin başlatılmasını değil, asıl işlevselliğin de test edilmesini sağlayan yeni özellikler sunuyor.

Uyarılar Artık CI Sürecini Durdurabiliyor

Varsayılan olarak, mcp-probe araçları uyarıları 0 çıkış kodu olarak işaretliyor. Bu, mevcut kullanıcıların beklenmedik CI kesintileri yaşamamasını sağlıyor. Ancak üretim ortamında çalışan sistemlerde daha sıkı kontroller gerekebiliyor:

mcp-probe --config mcp-probe.config.json --fail-on-warn

--fail-on-warn bayrağıyla birlikte, yetkilendirme akışındaki aksaklıklar, izin uyarıları veya eksik hazırlık alındılar, iş akışını doğrudan durdurabiliyor. Çünkü birçok MCP başarısızlığı, tam bir çöküş değil, aksine bozulmuş bir durum olarak ortaya çıkıyor:

• OAuth akışının tarayıcı yönlendirmesi, ajan tarafından tamamlanamaz hale gelebilir.
• Sunucu başlar ancak her araç çağrısı 401 yanıtı döndürür.
• Veritabanı aracı, yönetici kimlik bilgileriyle çalışsa da salt okunur rolle başarısız olur.
• İş akışı bir denetimden bahseder ancak aslında üretim sınırlarını test etmez.

Doktor Kontrolü Artık Gerçek İş Akışını Doğruluyor

mcp-probe doctor komutu, daha önce bir GitHub Actions iş akışının varlığını kontrol ediyordu. Ancak bu da yeterli değildi. Yeni sürümde, gerekli bayrakların aynı adımda yer alması zorunlu hale geldi:

Bu geçerli:

- run: npx @k08200/mcp-probe@latest --config mcp-probe.config.json --github-summary --fail-on-warn

Bu geçersiz:

- run: npx @k08200/mcp-probe@latest --config mcp-probe.config.json
- run: npx @k08200/mcp-probe ./server.js --github-summary --fail-on-warn

Bayraklar iş akışında yer alıyor olabilir, ancak tek bir adımın olmaması, asıl yapılandırmanın CI özetleriyle ve sıkı uyarı işlemleriyle birlikte test edilmediği anlamına geliyor. Bu da "bir denetimimiz var" ile "güvendiğimiz denetim gerçekten çalışıyor" arasındaki farkı ortaya koyuyor.

Araç Çağrı Kapsamı Artık Beklenen Araçlara Bağlı

Yapılandırma tabanlı kontroller için, beklenen araç katalogunu şu şekilde bildirebilirsiniz:

{
  "servers": [
    {
      "name": "datadog",
      "target": "
      "transport": "http",
      "headers": {
        "Authorization": "Bearer ${DATADOG_MCP_TOKEN}"
      },
      "expectedTools": ["logs_query"],
      "forbiddenTools": ["delete_dashboard", "rotate_api_key"],
      "toolsFile": "./datadog.tools.json"
    }
  ]
}

expectedTools ve toolsFile birlikte ayarlandığında, her beklenen aracın yanında örnek girdi de sağlanması gerekiyor. Bu sayede CI, yalnızca "araç tanıtıldı mı?" değil, "ajanın bağımlı olduğu aracın anlamlı bir kuru çalıştırma örneği sunuldu mu?" sorusunu da yanıtlıyor.

Yan Araç Girdileri Gerçek Sözleşmenin Taşıyıcısı

Otomatik olarak üretilen girdiler, genellikle şema doğrulamasıyla sınırlı kalıyor. Gerçek hazırlık kontrolleri ise anlamlı girdilere dayanıyor:

{
  "tools": {
    "logs_query": {
      "input": {
        "query": "service:web status:error",
        "timeframe": "1h"
      },
      "expect": {
        "status": "pass",
        "not_error_code": [401, 403],
        "requiredFields": ["source", "freshness"],
        "maxRows": 100
      }
    }
  }
}

Veritabanı tabanlı MCP sunucuları için bu doğrulamalar kritik önem taşıyor:

• Salt okunur rol çalışıyor mu?
• Satır sınırları uygulanıyor mu?
• Geniş dışa aktarımlar veya yönetici eylemleri engelleniyor mu?
• Engellenen yazmalar, ajanların kurtarma yapmasına yetecek kadar yapılandırılmış mı?
• Yanıtlar kaynak ve tazelik gibi köken bilgileri içeriyor mu?
• Yanıtlar gizli bilgileri, yığın izlerini veya ham iç sistemleri sızdırıyor mu?

Kurulum ve Kullanım

Aracı projenize eklemek için:

npm install -D @k08200/mcp-probe

Doğrudan çalıştırmak için:

npx @k08200/mcp-probe@latest doctor
npx @k08200/mcp-probe@latest --config mcp-probe.config.json --github-summary --fail-on-warn

MCP sunucularının CI sürecinde test edilmesi, yalnızca süreçlerin başlatılmasını değil, ajanların gerçekten kullanacağı arayüzlerin de doğrulanmasını gerektiriyor. Bu güncellemeyle birlikte, artık araçların ilan edilip edilmediğinden çok, gerçek kullanım senaryolarında nasıl performans gösterdiklerine odaklanabilirsiniz. Unutmayın: Bir MCP sunucusu CI’de yeşil olabilir, ancak üretimde tamamen farklı davranabilir.