MHS, MCP’nin yerine geçmiyor: İki standardın sınırı burada

Model Hardware Standard (MHS) ile Model Context Protocol (MCP) rakip veya birbirinin yerine geçen iki standart değildir. MHS, programlanabilir fiziksel cihazın durumlarını, işlemlerini ve çalışma sınırlarını ortak bir sürücü modeliyle tanımlar; MCP ise bir yapay zekâ uygulamasının sunulan yeteneklere erişmesini sağlayan protokoldür.

Bu nedenle bir MHS sürücüsünün işlemleri MCP üzerinden çağrılabilir, fakat MHS yalnızca MCP’den ibaret değildir. Aynı cihaz yeteneklerine komut satırı veya kod dosyaları ve API’ler üzerinden de ulaşılabilir; katmanların ayrılması erişim tasarımını, güvenlik kontrollerinin yerini ve arızanın hangi bileşende aranacağını belirler.

İki standart aynı katmanda değil

MHS’nin temel sınırı yazılım ile fiziksel cihaz arasındadır. Anthropic’in MHS araştırma önizlemesi, standart sürücünün cihazları ortak bir biçimde keşfedilebilir hâle getirdiğini, read ve write gibi temel işlemler sunduğunu ve güvenlikle ilgili sınırları cihaz referansına taşıdığını açıklıyor. Aynı duyuru, donanımı kontrol etmek için MCP, komut satırı ve kod dosyaları ya da API’ler olmak üzere üç mekanizma sayıyor.

MCP’nin sınırı ise ajan uygulaması ile çağrılabilir yazılım yetenekleri arasındadır. Bağımsız teknik katman karşılaştırması, MCP’yi MHS yeteneklerine ulaşan desteklenmiş yollardan biri olarak konumlandırıyor; erişim protokolünün tek başına cihazı doğru tanımlamadığını, güvenli kılmadığını veya MHS uyumlu hâle getirmediğini vurguluyor.

MHS, cihaz tarafındaki sözleşmeyi; MCP, bu sözleşmeye ulaşan protokol yolunu tanımlar. MCP bağlantısı belirsiz bir ölçüm birimini, eksik tamamlanma sinyalini veya yanlış cihaz durumunu düzeltemez. Ters yönde de eksiksiz bir MHS sürücüsü, ajan uygulamasının bağlantıyı nasıl kuracağını ve kullanıcıdan hangi izni alacağını tek başına belirlemez.

Ajan ile cihaz arasındaki veri akışı

MCP kullanılan bir kurulumda ajan doğrudan donanıma bağlanmaz. Resmî MCP mimarisi, bir host uygulamasının her MCP sunucusu için ayrı bir istemci oluşturduğunu; sunucuların araç, kaynak ve istem gibi yetenekler sunduğunu; istemcilerin araçları listeleyip tools/call ile çalıştırabildiğini gösteriyor. MHS ile kurulan sistemde MCP sunucusu veya bağdaştırıcı, seçilen araç çağrısını ilgili sürücü işlemine eşler.

1. Ajan veya orkestrasyon katmanı, iş akışındaki sıradaki işlemi seçer.
2. Host içindeki MCP istemcisi, sunucunun sunduğu araçları keşfeder ve seçilen aracı yapılandırılmış parametrelerle çağırır.
3. MCP sunucusu ya da bağdaştırıcı, isteği MHS sürücüsündeki uygun cihaz işlemine dönüştürür.
4. MHS sürücüsü, cihazın durumunu ve tanımlanmış çalışma sınırlarını dikkate alarak yerel donanım arayüzünü kullanır.
5. İşlem sonucu veya hata aynı zincir üzerinden geri döner; sonraki adımı ajan ya da orkestrasyon katmanı belirler.

Koşullu bir laboratuvar örneğinde ajan, sıvı aktarma cihazının hazır durumunu okuyup aktarımı başlatabilir. Aktarımın tamamlandığı sürücü üzerinden doğrulandıktan sonra robot koluna kabı taşıma görevi verilir. MCP aracın keşfini ve çağrının taşınmasını sağlar; “hazır” ve “tamamlandı” durumlarının fiziksel anlamı, izin verilen hızlar ve hareket sınırları ise cihaz entegrasyonunda tanımlanır.

Keşif, komut ve güvenlik kime ait?

“Keşif” iki katmanda farklı nesneleri ifade eder. MCP istemcisi, bağlı olduğu sunucunun hangi araçları ve diğer protokol yeteneklerini sunduğunu keşfeder. MHS sürücüsü ise fiziksel cihazı, cihazın mevcut durumunu, ölçebildiği değerleri ve gerçekleştirebildiği işlemleri standart bir yüzeyde sunar.

• Cihaz sözleşmesi: Durumların, ölçümlerin, ayarların, işlemlerin ve donanıma özgü özelliklerin tanımlanması MHS sürücüsüne aittir.
• Protokol erişimi: MCP seçildiğinde bağlantı, yetenek keşfi, araç çağrısı ve yanıtın taşınması MCP host, istemci ve sunucu bileşenlerinin alanındadır.
• Fiziksel güvenlik: Sıcaklık, hız veya hareket aralığı gibi cihaz limitleri, komut donanıma ulaşmadan önce cihaz entegrasyonu tarafında uygulanmalıdır.
• İş akışı kararı: İşlemlerin sırası, beklenen durumlar, yeniden deneme koşulları ve insan onayı ajan ya da orkestrasyon katmanında yönetilir.

MCP bağlantısındaki kimlik doğrulama ile cihazın fiziksel çalışma sınırı aynı kontrol değildir. İlki istemcinin bir sunucuya veya araca erişimini düzenler; ikincisi, erişim verilmiş olsa bile tehlikeli bir cihaz komutunu engellemeyi amaçlar. Güvenli bir üretim mimarisi her iki kontrolü de gerektirir ve birini diğerinin yerine koymaz.

MCP, CLI ve kod arasındaki seçim

MCP, ajan ortamı zaten MCP istemcisi barındırıyorsa ve yeteneklerin dinamik biçimde keşfedilmesi gerekiyorsa uygun bir erişim yoludur. Komut satırı bakım, tanılama veya mevcut otomasyon zincirleri için daha sade olabilir. Uzun süren, hızlı yürütülmesi gereken ya da önceden doğrulanmış bir sıra izleyen işlemler ise kod dosyaları veya API çağrılarıyla çalıştırılabilir.

Bu yolların aynı sistemde birlikte bulunması mümkündür. Örneğin ajan cihazın durumunu MCP üzerinden inceleyip parametreleri belirleyebilir, ardından tekrarlanabilir işlem dizisini bir kod dosyasına devredebilir; operatör de bakım sırasında aynı sürücüyü CLI üzerinden sorgulayabilir. Buradaki mimari koşul, erişim yollarının ortak cihaz anlamlarını koruması ve sürücünün uyguladığı sınırları aşan ikinci bir kontrol yüzeyi oluşturmamasıdır.

Erişim yolunu değiştirmek cihaz entegrasyonunu ortadan kaldırmaz. MCP’den CLI’ye geçmek hatalı sensör verisini düzeltmez; MCP eklemek de sürücüde bulunmayan bir tamamlanma durumunu üretmez. Seçim, çağrıyı kimin yaptığına ve işlemin nasıl yürütüleceğine göre verilir; cihaz sözleşmesinin doğruluğu ayrı değerlendirilir.

Hata ayıklama sınırı nereden geçer?

Araç listede görünmüyorsa önce MCP sunucusunun yetenek bildirimi, istemci bağlantısı ve erişim yapılandırması incelenir. Araç görünüyor fakat çağrı sürücüye ulaşmıyorsa sorun sunucu-bağdaştırıcı eşlemesinde veya parametre dönüşümünde aranır. Sürücü çağrıyı alıyor ancak cihaz beklenmedik davranıyorsa durum modeli, birimler, yerel cihaz arayüzü, kalibrasyon ve fiziksel koşullar öne çıkar.

Başarılı bir MCP yanıtı, fiziksel işlemin bilimsel veya mekanik açıdan doğru tamamlandığını tek başına kanıtlamaz. Protokol çağrısı taşınmış ve sürücü tarafından kabul edilmiş olsa bile köpük, yanlış kalibrasyon veya mekanik engel sonucu bozabilir. Bu nedenle yazılım yanıtı ile cihazın gözlemlenebilir son durumu ayrı sinyaller olarak izlenmelidir.

MHS bugün nihai bir uyumluluk standardı değil, sınırlı katılımla açılmış ve açık kaynak sürümü henüz yayımlanmamış bir araştırma önizlemesidir. Mimari sınır yine de nettir: MHS cihazın ne olduğunu, ne yapabildiğini ve hangi fiziksel koşullarda çalışacağını tanımlar; MCP gerektiğinde ajanın bu yeteneklere ulaşmasını sağlar. İki standardı aynı katmana yerleştirmemek, erişim arızasıyla cihaz arızasını birbirinden ayırmayı mümkün kılar.