MCP Monitor
AI agent'lara araç sunan Model Context Protocol sunucularını izleyin; kimlik doğrulama hatalarını, akış kopukluklarını ve protokol kaymalarını agent'lardan önce yakalayın.
MCP (Model Context Protocol) sunucuları AI agent'lara tool, resource ve prompt sunar. AI asistanları, özel agent'lar ve yeni agent çerçevelerinin çoğu yeteneklerini genişletmek için MCP sunucularına bağlanır: dosya sistemine erişim, veritabanı sorguları, dahili API çağrıları.
Bir MCP sunucusu çöktüğünde AI agent'lar yüksek sesle hata vermez; sessizce bir yeteneği kaybeder. Yalnızca HTTP yanıt kodlarını sayan bir izleme hattı bu sorunu görmez. MCP monitör asıl protokole dokunur: bir tools/list isteği gönderir ve sunucunun bir araç kataloğuyla yanıt verdiğini doğrular.
Ne zaman kullanmalı?
- Kendi altyapınızdaki MCP sunucuları: kendi ortamınızda çalışan dahili araç katalogları.
- Tedarikçi MCP uç noktaları: agent iş akışlarında üçüncü taraf MCP'lerine (DeepWiki, GitHub, Linear) bağımlıysanız.
- Gateway veya proxy sağlığı: agent'lar MCP'ye gateway üzerinden ulaşıyorsa zayıf halka gateway'dir.
- Regresyon yakalama: deploy sonrası MCP sunucunuzun beklenen yüzeyi hâlâ açtığını doğrulamak.
Desteklenen taşıma türleri
MCP spesifikasyonu üç taşıma listeler. UptimeWarden ağdan erişilebilir iki tanesini destekler:
| Taşıma | URL deseni | Davranış |
|---|---|---|
| HTTP (Streamable HTTP veya JSON cevabı) | https://server.example.com/mcp | Varsayılan. Monitör tools/list isteği gönderir; sunucu JSON veya event-stream yanıtı döner. |
| Server-Sent Events | https://server.example.com/sse veya URL event-stream içeriyor | Monitör akışı açar ve ilk frame'i okur. Sunucu data: veya event: satırları yayınlamalıdır. |
| STDIO | ./server.py, ./server.js | Desteklenmiyor. STDIO yerel süreç gerektirir, uzaktan erişilemez. Monitör net bir "STDIO not supported" hatası döner. |
Taşıma seçimi otomatiktir: URL'de /sse veya event-stream varsa SSE, yoksa HTTP kullanılır.
Kontrol nasıl çalışır?
HTTP sunucular için:
- URL'e
tools/lististeği gönder. - MCP'nin gerektirdiği başlıkları ekle; her kontrol için benzersiz bir oturum başlığı dahil.
- HTTP 2xx bekle.
- Sunucu JSON yerine event-stream döndüyse ilk 1 KB'ı oku;
data:veyaevent:içeriyorsa geçer. - Aksi hâlde JSON'u parse et.
resultalanı bulunmalıdır. JSON-RPC hata cevapları genelde down sayılır; ancak oturum hataları (Session not foundveyaMcp-Session-Id header is required) sunucunun yanıt verdiğini kanıtladığı için up olarak değerlendirilir.
SSE sunucular için monitör akışı açar ve ilk data frame'ini bekler.
Monitör oluşturma
-
Monitörler → Yeni Monitör.
-
Tip olarak MCP seçin.
-
Alanları doldurun:
- İsim: Örneğin
GitHub MCP server - URL: MCP sunucu uç noktası (
https://...). SSE tabanlı sunucular genelde/sse, HTTP Streamable sunucular genelde/mcpile biter. - Zaman aşımı: Varsayılan 10 sn. Soğuk başlangıcı yoğun sunucular için 30 sn'ye çıkarın.
- Kontrol Sıklığı: Minimum aralık plana bağlıdır; güncel değerler için fiyatlandırma sayfasına bakın.
- İsim: Örneğin
-
Kaydet.
Dahili uç noktalara ulaşmak
UptimeWarden varsayılan olarak yalnızca public MCP uç noktalarına bağlanır. Dahili veya özel MCP sunucuları için ortamınızda kendi agent'ınızı çalıştırın; özel ağ erişimi her agent için ayrı ayrı etkinleştirilebilir.
"Up" gerçekte neyi test eder?
Standart kontrol sunucunun protokol handshake'ini kabul ettiğini ve bir araç kataloğu döndürdüğünü doğrular. Yapmadıkları:
- Her tool'u tek tek listelemek.
- Bir tool'u çağırmak.
- "İstek reddedilmedi" ötesinde kimlik doğrulamayı denetlemek.
MCP sunucunuz tool bazlı yetkilendirme arkasındaysa ve bir tool bozuksa monitör yine de up raporlar. Daha derin doğrulama için bozuk tool çağrısını synthetic test olarak çalıştırın (MCP monitörünün kapsamı dışı).
Kimlik doğrulamalı uç noktalar
Çoğu public MCP sunucusu bearer token ister (örneğin bir API anahtarı veya oturum token'ı). MCP monitör şu an özel Authorization başlığı eklemez; yalnızca MCP'nin gerektirdiği oturum başlığını gönderir. Seçenekler:
- Public-readable uç noktalar: kimlik doğrulamasız DeepWiki tarzı sunucular doğrudan çalışır.
- Token korumalı uç noktalar: kimlik doğrulamasız bir
/healthveya/mcp/pingsürümü açın ve monitörü oraya yönlendirin. - Gateway korumalı uç noktalar: birçok ekip MCP'sini bir kimlik doğrulama gateway'i arkasına koyar. Gateway'i HTTP monitörle, MCP'yi de kimlik doğrulamanın ağ katmanında enjekte edildiği bir iç agent'tan izleyin.
Sık görülen hata mesajları
| Hata | Olası neden |
|---|---|
STDIO-based MCP endpoints are not supported in remote mode | URL bir dosya sistemi yolunu gösteriyor. STDIO MCP'ler uzaktan izlenemez. |
MCP HTTP request failed: connection refused | Sunucu çalışmıyor veya port yanlış. |
HTTP 401 / HTTP 403 | Sunucu tools/list üzerinde kimlik doğrulama istiyor. Yukarıya bakın. |
HTTP 400: Bad Request | Sunucu MCP Streamable HTTP alt kümesini konuşmuyor. Taşıma değiştirmek için URL'e /sse ekleyin. |
| Akış açılıyor ama veri yok | Sunucu ayakta ama event'leri doğru yayınlamıyor. Sunucu loglarına bakın. |
SLA ve bildirimler
- Down: Adımlardan herhangi biri başarısız.
- Recovery: Bir sonraki kontrol tamamlanır.
- Multi-location consensus: Desteklenir.
- SLO takibi: Desteklenir.
Sık sorulan sorular
S: Bu, bireysel bir tool'u mu çağırır?
C: Hayır; yalnızca tools/list çağrılır (protokol seviyesi sağlık kontrolü). Gerçek bir tool çağrısı yan etkiye yol açabilir (e-posta gönderimi, kart şarjı), bu nedenle kontrolü pasif tutuyoruz.
S: MCP'm Cloudflare Access arkasında. Ne yapmalıyım?
C: Cloudflare Access, servis token başlığı taşımayan istekleri reddeder. Access politikasında UptimeWarden'ın çıkış IP'lerini izinli listeye ekleyin veya Access'i atlayan dahili bir /health uç noktası açın.
S: Kontrol up diyor ama agent'ım tool çağırınca hata alıyor.
C: MCP monitör tool seviyesi sağlığı garanti etmez. Onu protokol seviyesi göstergesi olarak kullanın; tool doğrulaması için üstüne synthetic test koyun.
İlgili konular
- WebSocket Monitor: uzun ömürlü streaming protokolleri için
- HTTP Monitor: token kimlik doğrulamalı REST uç noktaları için
- Health Prediction: sorunları sizi uyandırmadan önce tahmin etme