MCP, bir modeli dış veri kaynaklarına ve tool'lara bağlamanın standart bir yolu. Anthropic tarafından açık kaynak olarak yayımlandı ve bugün ekosistemin ortak bir port'a en yakın şeyi.

Önceden her entegrasyon, uygulamanın içinde yaşayan ısmarlama bir adapter'dı. Sonrasında uygulama tek bir protokol konuşuyor ve her entegrasyon onun arkasında bir server — değiştirilebilir, yeniden kullanılabilir, sistemin sahibi tarafından bir kez yazılmış.

Altta yatan problem basit. Bir modelin bilgisi sabit bir depo ve canlı sistemlerden yalıtılmış — dolayısıyla her entegrasyon ısmarlama bir köprü istiyor.

N × M

N model, M tool, her çift kendi protokolünü konuşuyor. Bu, iki maliyeti olan bir kaos: boşa giden geliştirme eforu ve daha kötüsü, boşa giden bakım eforu — her biri kendi takvimine göre bozulan M entegrasyon.

Ortaya tek bir protokol koyunca bu N + M'ye iniyor:

Üç rol var ve birbirine karıştırmak kolay. Host uygulamanın kendisi. Her bağlantı için bir client tutuyor. Her client tek bir server ile konuşuyor.

Çoğu insanın yazdığı tek parça server. Capability'leri dışa açıyor ve arkasında ne varsa onunla konuşuyor — yerel bir veritabanı, bir web API, bir dosya sistemi.

Pratikte iki transport var ve seçim aslında "aynı makine mi, değil mi" sorusundan ibaret.

SSE'den neden uzaklaşıldı

Orijinal uzak transport, server'ın istekleri geri itebilmesi için uzun ömürlü bir server-sent-events stream'ini açık tutuyordu. Bu her bağlantıyı sticky yapıyordu — önüne düz bir load balancer koyamıyordun ve kopan bir stream session'ı da götürüyordu.

Kullanıcı, modelin tek başına cevaplayamayacağı bir şey sorduğunda aslında ne oluyor.

İki yarı

• Discovery. Client server'a ne sunduğunu soruyor ve açıklamalı bir liste alıyor. Model bu açıklamaları dokümantasyon okur gibi okuyor.
• Invocation. Model birini seçiyor, client onu çağırıyor, server asıl işi yapıp modelin okuyabileceği bir şey döndürüyor.

Bir server üç şey dışa açar. Önemli olan fark, bunları kullanmaya kimin karar verdiği.

Wire üzerindeki metotlar

Discovery ile kullanım ayrı çağrılar ve her birinin bir list tarafı, bir de eylem tarafı var: tools/list sonra tools/call, resources/list sonra resources/read, prompts/list sonra prompts/get.

Protokol başta iki yönlüydü: server, modeli ödünç almak, kullanıcıya bir şey sormak ya da workspace root'larını okumak için client'ı geri çağırabiliyordu.

Bunların hepsi açık tutulan çift yönlü bir stream istiyordu — stateless çekirdeğin kaldırdığı şey tam olarak bu.

Elicitation'ın yerine ne geldi

Multi Round-Trip Requests. Server, soruyu açık bir stream'den aşağı itmek yerine ihtiyaç duyduğu şeyle birlikte resultType: "input_required" döndürüyor. Client cevapları topluyor ve onları ekleyerek orijinal çağrıyı yeniden deniyor.

Model kodunu asla görmüyor. Gördüğü şey bir isim, bir açıklama ve bir schema — kalite de tam orada yaşıyor.

Bozulma biçimleri

• Tool çorbası. Kısa, kuru isimli kırk tool. Model yanlış seçiyor ve üstüne ne kadar prompt engineering yaparsan yap kötü bir menüyü düzeltmiyor.
• Yutulan hatalar. Hata durumunda boş sonuç döndüren bir tool, modele cevabın "hiçbir şey" olduğunu öğretiyor.
• Sayfalanmamış dönüşler. Koca bir JSON dokümanını olduğu gibi boşaltan tek bir tool, patlayan context window'un en yaygın sebebi.

Bu tool'ları tüketen döngü başlı başına bir konu — AI bahçesindeki bir agent bir döngüdür notuna bak.

Bir server kulağa geldiğinden küçük. Ne yapabildiğini bildiriyor, sonra her primitive için iki tür çağrıya cevap veriyor: listele ve birini yap.

Bir tool'un biçimi

Yaygın bir kafa karışıklığı: MCP function calling'in yerini almıyor. Onun üstünde oturuyor.

Model tool çağrısını hep yaptığı gibi yapmaya devam ediyor. MCP bir üst seviyedeki soruyu cevaplıyor: o tool listesi nereden geldi ve başka kim kullanabilir?

Her MCP server, modelin context'ine giren yeni bir güvenilmeyen metin parçası ve modelin ulaşabildiği yeni bir yetki kümesi demek. İkisi de saldırı yüzeyi.

İnsanları şaşırtan

Tool açıklamaları context'tir. Bir server açıklamanın içine talimat koyabilir ve model onları seninkileri okuduğu gibi okur. Invariant Labs bunu somut olarak gösterdi: ikinci bir server'daki zehirlenmiş bir açıklama, masum görünen bir çağrı üzerinden modele bir kullanıcının bütün WhatsApp geçmişini sızdırtmaya yetti.

Confused deputy, somut haliyle

Bir agent meşru olarak geniş bir veritabanı credential'ı tutuyor. Bir prompt injection onu bu credential'ı deploy edenin hiç niyetlenmediği bir şey için kullanmaya ikna ediyor. Server hack'lenmedi — tam olarak kendisinden isteneni yaptı.

Uzak server'lar için authorization oyunun tamamı. Spec OAuth 2.1'de karar kılıyor ve sıkılaştırdığı detaylar tam da sömürülen detaylar.

Bilmeye değer iki sıkılaştırma

• Issuer doğrulama (RFC 9207). Credential'lar onları basan issuer'a bağlanıyor; bu, authorization server'lar arasındaki bir sınıf mix-up saldırısını kapatıyor.
• CIMD, Dynamic Client Registration'ın yerini alıyor. Artık desteklenen yol Client ID Metadata Documents; DCR resmen deprecated.

2026-07-28 spec'i, MCP çıktığından beri yapılan en büyük değişiklik ve büyük ölçüde tek bir fikir: protokolü stateless yap ki normal bir HTTP servisi gibi işletilebilsin.

Asıl engel neden state'ti

Bir handshake ve bir session id varken her istek, konuşmayı başlatan instance'a düşmek zorundaydı. Bu da sticky session, düz round-robin yok ve kopan bir stream'in session'ı götürmesi demek.