Her yerde çalışan tek bir API sunucusu oluşturduğunuzu hayal edin, LSP bunu kod yazanlar için yaptı, MCP sırada mı?

2016'dan önce, IDE'lerde programlama dillerini desteklemek karmaşıktı.

Her editör, desteklemek istediği her dil için kendi araç setini oluşturmak zorundaydı.

Sözdizimi vurgulama, otomatik tamamlama, linting, hepsi özel olarak oluşturulmuştu.

Bu, parçalı bir deneyime yol açtı.

JavaScript gibi bir dil bir editörde sorunsuz hissedilebilirken, başka bir editörde eksik olabilirdi.

Ve VIM gibi terminal tabanlı bir editör kullandıysanız,
Çoğu zaman sınırlı araçlarla veya hiç araç olmadan kalıyordunuz.

Bu, @Microsoft'un Language Server Protocol'ü (LSP) tanıtmasıyla değişti.

Editörler ve diller entegrasyonları sıfırdan oluşturmak yerine,
LSP, onların iletişim kurması için standart bir yol oluşturdu.

Diller artık tek bir LSP sunucusu sağlayabilir,
Ve bir LSP istemcisine sahip herhangi bir editör bağlanabilirdi.

Yani, "VSCode için bir Go eklentisi" ve "Sublime için bir Go eklentisi" oluşturmak zorunda kalmak yerine,

Sadece bir Go LSP sunucusu oluştururdunuz ve her yerde çalışırdı. Geliştiriciler için bu, editörler arasında daha tutarlı özellikler anlamına geliyordu.

Dil bakımcıları için, yeni araçları destekleme işini basitleştirdi.

Ve editörler için, bir gecede uzun bir dil listesinin kilidini açtı.

Bugün, LSP, sözdizimi vurgulama ve otomatik tamamlama gibi araçların sorunsuz hissetmesini sağlayan şeydir,

Hangi dili kullandığınız veya hangi editörü tercih ettiğiniz önemli değil.

İşte LSP öncesi ve sonrası kurulumlar arasındaki farkı gösteren basit bir görsel:

Bugün, LSP, geliştirme araçlarının nasıl çalıştığını sessizce dönüştürdü.

Niş programlama dilleri bile artık popüler editörlerde harika geliştirici deneyimleri sunabiliyor.

VSCode veya Cursor gibi IDE'lerle doğrudan anlaşma yapmaları gerekmiyor,
Sadece bir LSP sunucusu oluşturuyorlar ve içerdeler.

Geliştirici tarafında, bu değişim de önemli.

Artık bir IDE'yi dil desteğine göre seçmiyoruz.

Editörün güçlü yönlerine göre seçim yapıyoruz,
Cursor'ın arayüzü veya AI yetenekleri gibi.

Bununla birlikte, LSP benimsenmesi evrensel değil.

JetBrains veya Apple'ın Xcode'u gibi bazı ekosistemler hala kendi protokollerini tercih ediyor.

Ancak çoğu için LSP, editörlerin ve dil araçlarının bağlanmasının standart yolu haline geliyor.

Şimdi, 2025'te MCP sohbete giriyor.
Ve bize çok tanıdık geliyor.

LSP'nin yapısının ona ilham vermiş olması şaşırtıcı olmazdı.

İşte karşılaştırma:
"Programlama dillerini" Stripe veya Supabase gibi üçüncü taraf API'leriyle değiştirin,
Ve "IDE'leri" AI sohbet istemcileri, @Cursor, Claude, @OpenAI, @vercel veya @LangChainAI ile değiştirin.
MCP'nin görünümü bu.

MCP tutarsa, etkisi çok büyük olabilir.
Supabase'in her AI istemcisi için ayrı entegrasyonlara ihtiyacı olmazdı.

Sadece bir @supabase MCP sunucusu oluştururdu,
Ve herhangi bir MCP uyumlu istemci bağlanabilirdi.
Bu, küçük ekipler için de oyun değiştirici olabilir.
Herhangi bir AI platformundaki kullanıcılara, tam özellikli araçlar sunabilirlerdi,
Beş farklı entegrasyonu sürdürmeden.

Hatta entegrasyon pazarlarını bile gereksiz hale getirebilir.
Deneyim platformlar arasında yerel ise,
Neden herhangi biri eklentilere manuel olarak göz atıp kursun ki?

Son kullanıcılar en çok fayda sağlardı.

Hangi AI aracını kullanırlarsa kullansınlar, tutarlı bir deneyim elde ederlerdi.

MCP'nin gerçek potansiyele sahip olduğunu düşünüyoruz.

Ve @AnthropicAI'nın @State_Of_Mika ile birlikte öncülük etmesiyle,
Üçüncü taraf API'lerini LLM'lerle bağlamanın yeni standardı haline gelebilir.

LSP'nin benzer bir zorluğu nasıl çözdüğünü merak ediyorsanız,
gMika yorumunu yapın, size rehberi gönderelim.