Carbon'da API ve MCP: Üretim verisine erişim ile işlem yapma arasındaki sınır

Planlamacı sabah açık işlerin hangilerinde malzeme eksiği olduğunu görmek istiyor. Bunu ekrandan tek tek kontrol etmek yerine kendi raporunda toplamak makul. Aynı raporun eksik malzeme gördüğü her işi otomatik ertelemesi ise başka bir karar. İkisi de üretim yazılımıyla konuşmayı gerektiriyor, fakat ilki bilgi okurken ikincisi operasyonel kaydı değiştiriyor.

Carbon’un açık API ve MCP arayüzlerini değerlendirirken bu farkla başlamak gerekiyor. Bir arayüzün yapay zekâ ajanına açık olması, ajanın üretim planını kendi başına değiştirmesi gerektiği anlamına gelmez. Asıl değer, sistemdeki iş bilgisinin başka bir uygulamaya taşınabilmesi ve gerektiğinde tanımlı bir işlemin, doğru kimlikle, izlenebilir biçimde çağrılabilmesidir.

İki arayüz, aynı iş sorusu

API, başka bir programın Carbon’la tanımlı kurallar üzerinden veri alışverişi yapmasını sağlar. Örneğin kurum içi bir malzeme hazırlık ekranı, belirli bir iş için gereken kalemleri sorgulayabilir. Carbon’un proje belgeleri, uygulamanın kullandığı üretim işlemlerini HTTP üzerinden sunduğunu, girişleri doğruladığını ve işlem yapan kimliğin yetkilerini uyguladığını belirtiyor. Webhook desteği de olayları başka sistemlere bildirmek için ayrı bir yol sunuyor.

MCP ise yapay zekâ araçlarının aynı işlemleri araç olarak kullanabildiği bir bağlantı biçimi. Bir kullanıcı “Bugün hangi işler malzeme bekliyor?” diye sorarsa, bağlı bir ajan erişim izni olan verileri sorgulayıp yanıt oluşturabilir. Carbon’un tanımına göre MCP araçları da bağlanan kullanıcı ya da anahtarın yetki sınırına tabidir. Bu, ajanın sınırsız erişimi olduğu anlamına gelmez; hangi aracı hangi kapsamda çağırabildiği kurulumla belirlenmelidir.

Burada “yapay zekâ destekli” ifadesi sonuç değil, arayüz tercihidir. İyi bir doğal dil yanıtı, arkadaki iş emrinin güncel veya doğru olduğunu tek başına kanıtlamaz. API ve MCP üretim verisine ulaşma yolunu açar. Verinin anlamı, güncelliği ve değişiklik yetkisi hâlâ işletmenin sorumluluğundadır.

Malzeme bekleyen bir işin kısa hikâyesi

Varsayımsal bir atölye düşünelim. Bir kabin siparişinin kesilmiş parçaları hazır, ancak montajda kullanılacak bağlantı elemanlarından biri henüz depoya girmemiş. Planlamacı bu işi sabah toplantısında konuşacak. Önce işin numarası, malzeme gereksinimi, stok kaydı ve beklenen giriş tarihi bir arada görülmeli. Bir API bağlantısı bu verileri planlama ekranına getirebilir. MCP kullanan bir asistan da aynı bilgilere dayanarak toplantı için kısa bir özet hazırlayabilir.

İşin “malzeme eksik” olması, teslim tarihinin kendiliğinden değişeceği anlamına gelmez. Aynı malzemenin başka bir depoda bulunması, kısmi montajın mümkün olması ya da müşterinin önceliğinin değişmesi gibi durumlar olabilir. Bir sonraki adımı insanın onayına bırakmak, teknolojiye güvensizlik değil, kararın bağlamını korumaktır.

Bu senaryoda güvenli ilk sınır nettir: asistan işleri okur, hangi kayıtların eksik göründüğünü kaynaklarıyla listeler ve son veri yenilenme anını gösterir. İş emri tarihi, satın alma talebi veya stok miktarı üzerinde yazma yetkisi almaz. Bu aşama işe yarıyorsa, daha sonra belirli işlemler için ayrı bir onay akışı tasarlanabilir. “Ajan bağlandı” diye tüm işlemlere aynı anahtarı vermek, sıradan bir raporlama ihtiyacını üretim değişikliği yetkisine dönüştürür.

Yetki yalnızca giriş ekranı değildir

Carbon’un belgelerinde API ve MCP işlemlerinin yetkiyle sınırlandırıldığı anlatılıyor. Uygulamada bunu sınamak için rol adı okumak yetmez. Planlama için açılan kimlik hangi şirketin hangi kayıtlarını görebiliyor? Bir tedarikçi hesabı başka siparişlere erişebiliyor mu? İptal, tarih değiştirme ve stok düzeltme işlemlerine aynı erişim anahtarıyla ulaşılabiliyor mu? Bunlar gerçek kullanım senaryolarıyla test edilmelidir.

Kimlik bilgilerini bir sohbet penceresine yapıştırmamak, bağlantı anahtarını güvenli saklamak ve erişimleri görevle sınırlamak temel önlemlerdir. Bir deneme ortamında okuma izniyle başlamak, hem yanlış işlem riskini hem de “sisteme bağlandık, artık her şey otomatik” beklentisini azaltır. Üretim ortamında hangi işlem ne zaman, kimin adına yapıldı sorusunun cevabı da saklanmalıdır. Ajanın hazırladığı öneri ile sistemde gerçekten oluşmuş değişiklik birbirine karıştırılmamalıdır.

Bir başka ayrıntı lisans kapsamıdır. Carbon’un güncel proje açıklaması API anahtarı ve MCP özelliklerinin barındırılan Business ve Enterprise planlarında sunulduğunu, kendi sunucusunda bu özellikleri kullanmak için ticari lisans gerektiğini söylüyor. Kaynak kodun erişilebilir olması, her dağıtım biçiminde tüm bağlantı özelliklerinin aynı koşullarla kullanılabileceği anlamına gelmez. Bir entegrasyon projesinin bütçesinde ve mimarisinde bu koşullar baştan kontrol edilmeli.

Denemeyi nasıl sınırlandırmalı?

Önce tek bir karar sorusu seçilebilir: “Montaja girecek işlerden hangilerinde malzeme hazırlığı tamamlanmadı?” Soru açık olursa hangi veri alanlarının ve hangi sorguların gerekli olduğu anlaşılır. Ardından birkaç örnek iş kaydıyla API sonucunu Carbon ekranındaki kayıtla karşılaştırmak gerekir. Eksik malzeme olarak görünen kalemin gerçekten o işin güncel reçetesinde bulunup bulunmadığı ayrıca doğrulanmalıdır.

İkinci aşamada aynı soru MCP bağlantısıyla sorulabilir. Asistandan yalnızca sonuç değil, kullandığı iş numaralarını ve sorgu zamanını da göstermesi beklenir. Hatalı veya eksik veriyle karşılaştığında kesin bir cevap üretmek yerine belirsizliği belirtmesi daha yararlıdır. Son test, değişiklik isteğidir: “Bu işi yarına taşı.” Okuma odaklı denemede bunun gerçekleşmemesi, sistemin çalışmadığı değil, seçilen yetki sınırının işlediği anlamına gelir.

Önceki Carbon’un bütünleşik üretim modeli yazısı farklı işlevlerin aynı sistemde bulunması fikrine bakıyordu. API ve MCP ise bu sistemin dış dünyayla konuşma kapısı. Kapıyı açmanın ölçüsü kaç otomasyon kurulabildiği değil; hangi bilgiye güvenildiği, hangi değişikliğe izin verildiği ve yanlış bir kararın nasıl durdurulduğudur.

Kaynaklar: Carbon proje deposu ve Luke van Enkhuizen’in üretim için açık kaynak araçlar derlemesi. Atölye örneği varsayımsaldır; lisans ve özellik koşulları kurulmadan önce yeniden doğrulanmalıdır.