Ajanın zaten kodu yazabiliyor, testleri çalıştırabiliyor ve pull request açabiliyor. Genelde yapamadığı tek şey, az önce kurduğu şeyin resmini sana vermek. Mimariyi düzyazıyla anlatır, sen başını sallarsın, sonra yine birinin bir tuval açıp onu elle çizmesi gerekir. Diyagramlar için bir MCP sunucusu bu boşluğu kapatır. Birkaç satırlık config ile ajanın gerçek bir LetDraw diyagramı üreten bir araca kavuşur; ASCII bir eskiz değil, açıp düzenleyebileceğin ve paylaşabileceğin gerçek, düzenlenebilir bir pano.
Bu, işin pratik versiyonu: tek paragrafta MCP nedir, ardından bağlamak için gereken adımlar ve deneyeceğin ilk prompt.
Tek paragrafta MCP
Model Context Protocol, bir yapay zekâ ajanının dış araçları çağırması için küçük, standart bir yöntemdir. Bir araç bir kez tanımlanır (adı, ne yaptığı ve girdilerinin yapısı); sonra MCP'yi bilen herhangi bir ajan onu çağırmaya karar verip sonucu okuyabilir. LetDraw, diyagram üretmeyi tam olarak bu tür bir araç olarak sunan bir MCP sunucusu ile gelir. Ajanın LetDraw'un bir şeyi nasıl çizdiğini bilmesi gerekmez; "bu açıklamadan bir diyagram oluştur" gibi bir aracı çağırır ve bitmiş panonun linkini geri alır.
1. Adım: bir API token'ı oluştur
MCP sunucusu senin adına hareket eder, bu yüzden bir kimlik bilgisine ihtiyaç duyar. LetDraw'da Hesap → API Anahtarları bölümünü aç ve kişisel bir API token'ı oluştur. Onu bir kez kopyala ve ajanının config'inin okuyabileceği bir yerde sakla; bir ortam değişkeni idealdir. Ona bir parola gibi davran; ona sahip olan herkes senin adına diyagram oluşturabilir.
# from Account → API Keys LETDRAW_API_TOKEN="ld_live_xxxxxxxxxxxxxxxxxxxx"
2. Adım: MCP sunucusunu ekle
Ajanını LetDraw MCP sunucusuna yönlendir ve token'ı ilet. MCP'yi bilen istemcilerin çoğu, kullanabilecekleri sunucuları listeleyen küçük bir JSON bloğu okur. Yapı hep aynıdır: bir ad, nasıl başlatılacağı ve hangi ortamla çalışacağı.
{
"mcpServers": {
"letdraw": {
"command": "npx",
"args": ["-y", "@letdraw/mcp"],
"env": { "LETDRAW_API_TOKEN": "${LETDRAW_API_TOKEN}" }
}
}
}
Ajanı yeniden başlat; LetDraw araçlarını otomatik olarak keşfeder: bir açıklamadan, bir kod parçasından ya da bir compose veya Kubernetes dosyasından diyagram oluşturmak gibi. Her birini elle bağlamazsın; MCP onları senin yerine duyurur.
3. Adım: bir diyagram iste
Şimdi eğlenceli kısım. Araç sade ifadelerle tanımlandığı için onu sade bir dille yönetirsin. Ajan onu ne zaman çağıracağına karar verir ve girdileri isteğinden doldurur.
You: Draw the architecture for the service you just scaffolded ,
API, worker, Postgres and Redis, and give me the link.
Agent → calls letdraw.create_diagram({
"description": "API service behind a load balancer, a queue
feeding a background worker, Postgres primary with a
read replica, Redis cache in front of the API"
})
Agent: Done → https://letdraw.com/?doc=abc123 (open to edit)
Ajan diyagramı çizmez. Bir diyagram ister ve sana üzerinde çalışmaya devam edebileceğin bir tuval verir.
Bunu bir gösteri numarası olmaktan çıkarıp işe yarar kılan da bu son ayrıntı. Sonuç normal bir LetDraw panosu; yani yapay zekâ sana bir ilk taslak verir ve kontrol sende kalır. Linki aç, bir kutuyu sürükle, modelin biraz yanlış kurduğu tek ilişkiyi düzelt, bilmediği şeyi ekle ve paylaş. Sıkıcı yerleştirmeyi ajan yaptı; muhakemeyi sen.
docker-compose.yml dosyasının diyagramını çiz" ya da "bu Kubernetes manifestlerinin diyagramını çiz" demek modele üzerinde çalışacağı bir yapı verir; böylece ilk taslak çok daha az temizlik ister.Yapay zekâ ajanı için diyagram aracı en çok nerede işe yarar
Üretilmiş bir diyagram tam da dokümantasyonun var olma ihtimalinin en düşük olduğu anda en değerlidir: kodun yazıldığı ya da değiştiği an. MCP sunucusunu bir kez bağla; "bir de mimariyi çiz" bir görevin sonunda söylenen sıradan bir cümleye dönüşsün. Resim, tasarım herkesin kafasında tazeyken gelir; atılıp gidecek değil düzenlenebilir bir şeydir ve ekip arkadaşlarının hiçbir şey kurmadan açabileceği bir tuvalde yaşar. Ajanın işi zaten yapıyordu; artık gösterebiliyor da.
Bir token oluştur, config'i ekle ve ajanından ilk diyagramını iste.