| Sunucu | Nasıl Çalışır | Araçlar | Rezervasyon İhtiyaçları | Teklif Geçerliliği | Kapsam |
Warp warp-agent-mcp | npx üzerinden stdio | ~23 | API anahtarı | ~72 saat | Karayolu, kendi ağı |
| CargoAi CargoMART | barındırılan | arama, teklif, rezervasyon | hesap kimlik doğrulaması | kısa süre | Havayolu taşımacılığı |
| freightutils-mcp | npx üzerinden stdio | ~19 | yok (sadece okuma) | uygulanamaz | Hesaplamalar, referans |
| Easyship | barındırılan veya stdio | oranlar, etiketler, takip | API anahtarı | taşıyıcıya bağlı | Parsel |
Birkaç ay önce, Model Bağlam Protokolünün bir nakliye API'sine nasıl uyduğunu ve kendinizin çalıştırabileceği minimal bir sunucuyu içeren bir özet yazmıştım. MCP, Anthropic'in Kasım 2024'te yayınladığı açık standart ve nakliye sektörü bunu 2026'nın başlarına kadar yavaş benimsedi. O zamandan beri konuşmalar durdu ve nakliyeler başladı. Warp, 16 Nisan 2026'da warp-agent-mcp'yi MIT lisansı altında npm'e yayınladı, CargoAi, 5 Haziran 2026'da CargoMART sunucusunu başlattı ve açık kaynaklı ve parsel sunucuları da bunlara eşlik etti. Okumak istediğim devamı bu: gönderilenlerin gerçekte ne olduğunu, bu dördünün nerede anlaştığını ve tasarım seçimlerinin sessizce nerede ayrıldığını incelemek. Protokol temellerini görmediyseniz, o özete başlayın ve buraya geri dönün.
Gerçekten Gönderilen Sunucular
- Warp
warp-agent-mcp, 16 Nisan 2026'da npm'e ulaştı, MIT lisanslı, gerçek nakliye rezervasyonu için ilk MCP sunucusu olarak lanse edildi. Kapasite aramasından takip sorgusuna kadar uçtan uca işlem yapmak üzere tasarlandığı için arama, teklif verme ve takip etme işlemlerini kapsayan yaklaşık 23 araç sunuyor. - CargoAi CargoMART, 5 Haziran 2026'da gönderildi, bir ajanın Copilot, ChatGPT, Claude veya Gemini içinden havayolu taşımacılığı aramasını, tekliflendirilmesini ve rezervasyonunu yapmasını sağlıyor. Sadece karayolu değil, havayolu tarafının da hareket ettiğinin en açık işareti.
- freightutils-mcp açık kaynaklı seçenektir; yaklaşık 19 ücretsiz yardımcı araç içeren bir TypeScript paketidir. Canlı bir ağda işlem yapmaktan ziyade hesaplamalara ve referans verilerine odaklanır, bu da onu temiz bir kum havuzu yapar.
- Easyship, 550'den fazla kurye entegrasyonu üzerinden parsel ve küçük paket işlerini hedefler, oranları, etiket oluşturmayı ve takibi sunar. Paket odaklıdır, bu nedenle modelleme varsayımları ağır nakliyeden farklıdır.
Yan yana okunduğunda, dördü üç soruda farklılaşıyor: ajanın kimlik bilgileri olmadan ne yapabileceği, bir fiyatın ne kadar süreyle geçerli olduğu ve sunucunun nerede çalıştığı.
Araç Yüzeyi: Ajana Ne Yapmasına İzin Veriliyor
Her sunucu bir araç çantasıdır ve çanta size satıcının niyetini söyler. Warp'ın yaklaşık 23 aracı en geniş seti oluşturuyor çünkü kapasite aramasından takip aramasına kadar uçtan uca işlem yapmak üzere inşa edilmiş. CargoMART, havayolu rezervasyon yolculuğuna odaklanıyor, arama, teklif ve rezervasyon sunuyor. freightutils, 19 yardımcı programıyla hesaplama ve arama alanında kalıyor. Easyship, oranlar, etiketler ve takip ile parsel oranı-etiket döngüsünü optimize ediyor.
Bunları bir nakliye iş akışına eşlediğimde, araçlar dört işe ayrılıyor: kapasite bulma, fiyatlandırma, bu kapasiteye onay verme ve hareketini izleme. İlk ikisi sadece okuma yaptığı için düşük risklidir. Onay vermek gerçek dünyaya yazar ve para harcar. İzleme yine sadece okuma yapar ancak yüksek değerlidir çünkü insan zamanının çoğu hala durumu takip etmekle geçer.
Bir ajan, MCP tools/list yöntemi aracılığıyla bir sunucunun ne sunduğunu keşfeder ve tools/call ile bir araç çağırır, bu nedenle okuduğu isimler önemlidir. Bir sevk görevlisinin tanıdığı sonuçları tanımlayan get_quote, book_shipment veya get_tracking gibi adlar, gerçek bir ajanla temas halinde hayatta kalır. Ham uç noktaları sızdıran adlar, modeli boru tesisatını düzenlemeye zorlar ve burada uydurma parametreler ortaya çıkar. Warp ve CargoMART, her ikisi de sonuç şeklinde adlara eğilimlidir, bu da onların bir REST spesifikasyonundan yeniden düzenlenen değil, ajanlar için tasarlandıklarının sessiz bir sinyalidir.
Kimlik Doğrulama: açık fiyat teklifi, kilitli rezervasyon
Ciddi sunucular arasındaki paylaşılan desen, benim de kendim seçeceğim modeldir. Fiyat teklifi ve referans araçları açıktır veya sürtünmesi azdır, çünkü bir ajanın bir hattı fiyatlandırmasına izin vermek zararsız ve gerçekten kullanışlıdır. Rezervasyon, iptal ve bir faturayla ilgili her şey bir API anahtarının veya tam bir OAuth akışının arkasında yer alır. Örneğin Warp, anahtarını yerel bir yapılandırma dosyasından ~/.warp/config.json öğesinden okur, bu nedenle rezervasyon araçları yalnızca kimliği doğrulanmış olduğunuzda etkinleşir.
{
"mcpServers": {
"warp": {
"command": "npx",
"args": ["-y", "warp-agent-mcp"],
"env": { "WARP_API_KEY": "your_key_here" }
}
}
}Anahtar olmadan ajan hala keşfedebilir ve fiyat teklifi verebilir. Anahtarla birlikte ajan sizin adınıza para harcayabilir. Masaüstü kullanımı için bir yapılandırma dosyasındaki statik bir anahtar kabul edilebilirdir. Rezervasyon yapmayan bir üretken ajan için statik bir anahtar bir risktir ve COMPROMISED veya iptal edemeyeceğiniz için PKCE'li OAuth 2.1 ve kapsamlı, geri alınabilir belirteçler istersiniz. Bir promp t-enjeksiyonunu para olayı haline getiren navlun rezervasyonu nedeniyle, bunu özel bir güvenlik makalesinde daha derinlemesine ele alacağım.
Teklif geçerliliği tuzağı
İşte navluna yeni başlayan ekipleri ısıran ayrıntı. Bir teklif bir fiyat değildir, süresi dolan bir fiyattır. Örneğin Warp'ın teklifleri, günler değil, yaklaşık 72 saatlik bir geçerlilik penceresi taşır. Pazartesi günü teklif veren ve Cuma günü rezervasyon yapmaya çalışan bir ajan başarısız olacaktır ve naif bir yeniden deneme döngüsü, jetonları tüketirken başarısız olmaya devam edecektir.
Bu nedenle sunucu, geçerliliği makine tarafından okunabilir hale getirmeli ve ajanınız buna uymalıdır. İyi uygulamalar açık bir son kullanma tarihi ve bir teklif referansı döndürür ve rezervasyon aracı her ikisini de kontrol eder. Daha zayıf olanlar çıplak bir sayı döndürür ve tahmin etmenizi sağlar. Bir sunucuyu değerlendirdiğinizde, bir hattı fiyatlandırın, bekleyin ve ardından eski teklife karşı rezervasyon yapmaya çalışın. Nasıl başarısız olduğu, ne kadar üretim sertleştirmesinin yapıldığını size söyler.
Taşıma: stdio ve barındırılan HTTP
Protokol, iki aktarım yöntemi tanımlar: stdio ve Streamable HTTP ve mesajlar her iki durumda da JSON-RPC 2.0'dır. npx ile başlatılan yerel bir stdio sunucusu, bir geliştiricinin masaüstü yardımcısı gibi Claude Desktop veya Cursor'ı kendi hesabına bağlaması için mükemmeldir. Kurulum basittir ve kimlik bilgileri asla makineden ayrılmaz. Barındırılan bir HTTP sunucusu bir hizmet olarak çalışır; bu, bir dizi ajanın erişimi paylaştığı, merkezi günlük kaydı istediğiniz ve API anahtarlarını dizüstü bilgisayarlara dağıtamadığınız durumlarda ihtiyacınız olan şeydir.
freightutils ve npx ile başlatılan sunucular yerel yolu zahmetsiz hale getirir. Üretim dağıtımları, kimlik doğrulama, hız sınırları ve denetim izi olan bir ağ geçidinin arkasındaki barındırılan HTTP'ye eğilimlidir. Hiçbiri yanlış değildir. Hata, bir stdio prototipini üretime göndermek ve ajanlarınızın ne rezervasyon yaptığının merkezi bir görünümünün olmadığını fark etmektir.
Çok taşıyıcılı bir pazar yeri sunucusunun neyi barındırması gerekir
Burada kendi perspektifim devreye giriyor, çünkü biz tek bir taşıyıcı yerine bir pazar yeri işletiyoruz ve modelleme sorunu gerçekten farklı. Tek taşıyıcılı bir sunucu bir soruyu yanıtlar: Bunu ağımda taşıyabilir miyim ve ne kadar? Bir pazar yeri sunucusunun daha zor bir soruya yanıt vermesi gerekir: birden çok taşıyıcı arasında, ajan hangi seçeneği seçmeli ve neden.
Bu, tek taşıyıcılı bir sunucunun asla ihtiyaç duymayacağı araçları gerektirir. Temsilci, sadece bir teklif almakla kalmayıp teklifleri karşılaştırabilmelidir. Fiyatı, nakliye süresini ve taşıyıcı kullanılabilirliğini birleştiren bir sıralama sinyaline ihtiyaç duyar, çünkü kimsenin hizmet vermediği bir rota üzerindeki en ucuz fiyat tuzağa düşürebilir. Dürüst kullanılabilirlik gerektirir, böylece temsilci zaten dolmuş kapasiteye taahhütte bulunmaz. Ve takip işleminin başarılı bir şekilde çözümlenmesi için, rezervasyonu yapılan sevkiyatın belirli bir taşıyıcı ve referansla geri eşleşmesi gerekir. Yoğun bir rotada, bir temsilci bir düzine teklif görebilir ve o gün sadece üç veya dördünü rezerve edebileceğini bulabilir ve verilerimizde, en ucuz teklif ile rezerve edilebilen en ucuz teklif arasındaki fark gerçektir ve tekrarlanmaktadır. Bu farkı gizleyen bir pazar yeri sunucusu, temsilciye bir haksızlık yapmış olur. Tekrar tekrar öğrendiğimiz ders, kullanılabilirlik olmayan fiyatın pazarlama olduğu, rezervasyon olmadığıdır.
Bir yük MCP sunucusu nasıl değerlendirilir
Eğer birini seçiyorsanız, açılış sayfası yerine canlı sunucuya karşı bu kısa kontrol listesini çalıştırın.
- Araç adları. Bir sevk memurunun tanıdığı sonuçları mı açıklıyorlar, yoksa ham uç noktaları mı açığa çıkarıyorlar?
- Kimlik bilgisi sınırı. Anahtar olmadan ne çalışır ve rezervasyon ne gerektirir? Otomatik kullanım için kapsamlı OAuth yoluna giden bir yol var mı?
- Teklif geçerliliği. Son kullanma tarihi açıkça döndürülüyor mu ve rezervasyon aracı eski bir teklifi temiz bir şekilde reddediyor mu?
- Taşıma. Masaüstü için yerel stdio, bir filo için barındırılan HTTP. Satıcı gerçekten ihtiyacınız olanı mı destekliyor?
- Kapsam dürüstlüğü. Tek taşıyıcı mı yoksa anlaşılacak mı ve anlaşılacaksa, temsilci tek bir opak sayı yerine kullanılabilirliği ve bir sıralamayı görebilir mi?
- Gözlemlenebilirlik. Bir temsilcinin sonradan ne teklif ettiğini ve rezerve ettiğini denetleyebilir misiniz?
Pazar, sadece bir çeyrekte düşünce yazılarından paketlere geçti, ki bu lojistik-teknoloji standartlarına göre bile hızlı. Eğer inşa ediyorsanız, özet artı bu ayrıştırma, bu hafta bir temsilciyi gerçek bir ağa bağlamak için yeterli olacaktır. Eğer satın alıyorsanız, yukarıdaki kontrol listesi bir rezervasyon motorunu bir demodan ayıracaktır. GetTransport gibi bir pazar yerinde, aynı ilkeler bir temsilcinin para harcamak için güvenilip güvenilemeyeceğini belirler ve bu güven, araç listesinin boyutuna değil, kullanılabilirlik ve geçerliliğe dayanır.
SSS
Yük MCP sunucusu nedir?
Yapay zeka asistanının Model Bağlam Protokolü aracılığıyla çağırabileceği araçlar olarak, teklif verme, rezervasyon yapma ve takip etme gibi yük işlemlerini sunan küçük bir hizmettir, böylece temsilci her taşıyıcı API'sini öğrenmek yerine bir kez entegre olur.
2026'da hangi yük MCP sunucuları mevcut?
Öne çıkanlar arasında yol yük rezervasyonu için Warp'ın warp-agent-mcp'i, kargo taşımacılığı için CargoAi'nin CargoMART'ı, hesaplamalar ve referans verileri için açık kaynak kodlu freightutils-mcp ve parsel oranları ve etiketleri için Easyship bulunmaktadır.
Bir yapay zeka temsilcisi API anahtarı olmadan yük rezervasyonu yapabilir mi?
Genellikle hayır. Çoğu sunucu, temsilcinin kimlik bilgileri olmadan teklif vermesine ve veri aramasına izin verir, ancak rezervasyon, iptal ve fatura işlemleri, yalnızca yetkili temsilcilerin para harcayabilmesi için kimliği doğrulanmış bir anahtar veya OAuth jetonu gerektirir.
Bir MCP sunucusu tarafından döndürülen yük teklifleri neden süresi doluyor?
Yük fiyatları kapasite ve yakıtla birlikte hareket eder, bu nedenle bir teklif kısa bir süre, bazen birkaç saat için geçerlidir. Sunucu bir son kullanma tarihi döndürür ve temsilci eski bir teklifi tekrar denemek yerine yeni bir teklif yeniden rezerve etmelidir.
Tek taşıyıcılı bir sunucunun aksine bir pazar yeri MCP sunucusu neyi sunmalıdır?
Temsilcinin taşıyıcılar arasındaki teklifleri karşılaştırmasına, fiyatı nakliye süresi ve kullanılabilirlik ile harmanlayan bir sıralama görmesine ve rezervasyonu belirli bir taşıyıcıya geri eşleştirmesine izin vermelidir, çünkü en ucuz teklif her zaman aslında rezerve edebileceğiniz teklif değildir.