Model Context Protocol (MCP) ile Ölçeklenebilir Ağ Uç Noktaları

Bir MCP sunucusunu bilgisayarınızda çalıştırmak kolay olabilir. Asıl sınav, aynı servise onlarca hatta binlerce istemci bağlandığında başlar. Trafik arttığında isteklerin doğru sunucuya ulaşması, yetkilerin korunması, gecikmenin kontrol altında tutulması ve bir sunucu örneği devre dışı kaldığında sistemin çalışmaya devam etmesi gerekir.

Model Context Protocol (MCP) ile Ölçeklenebilir Ağ Uç Noktaları tasarlarken konu yalnızca bir /mcp adresi yayınlamak değildir. Streamable HTTP, stateless çalışma modeli, load balancing, API Gateway, OAuth, rate limiting, cache, queue, gözlemlenebilirlik ve hata izolasyonu birlikte düşünülmelidir.

Bu rehberde MCP ile ölçeklenebilir ağ uç noktaları nasıl oluşturulur, Model Context Protocol Streamable HTTP ile uzak MCP sunucusu nasıl kurulur ve MCP sunucularında stateless mimari load balancing ve yatay ölçekleme nasıl ele alınır gibi soruları üretim ortamı açısından inceleyeceğiz.

Model Context Protocol (MCP) Nedir?

Model Context Protocol, yapay zekâ uygulamaları ile dış sistemler arasında standart bir iletişim modeli oluşturur. MCP; araçların, veri kaynaklarının ve yeniden kullanılabilir istemlerin istemcilere tanımlanmasını sağlar. 2026-07-28 sürümü JSON-RPC tabanlı, stateless ve self-contained request yapısını protokolün merkezine taşımıştır.

MCP Hangi Problemi Çözer?

Her yapay zekâ uygulaması için ayrı entegrasyon kodları yazıldığında bakım yükü hızla büyür. MCP ortak bir iletişim sözleşmesi sağlayarak araçların farklı host ve client uygulamaları tarafından daha düzenli biçimde kullanılmasına yardımcı olur.

MCP Host, Client ve Server Arasındaki İlişki

Host, kullanıcı deneyiminin ve model etkileşiminin bulunduğu uygulamadır. Client, host içinde belirli bir MCP server ile iletişim kurar. Server ise tools, resources ve prompts gibi yetenekleri yayınlar.

MCP Server Nedir?

MCP server, belirli yetenekleri protokol üzerinden sunan servistir. Örneğin bir server veritabanında arama yapabilir, başka bir servis iş kaydı oluşturabilir veya kurumsal dokümanları resource olarak sunabilir.

MCP Sunucu Uç Noktası (Endpoint) Nedir?

Remote MCP kullanımında endpoint, istemcilerin protokol mesajlarını gönderdiği ağ adresidir. Streamable HTTP kullanıldığında istemci MCP mesajlarını HTTP üzerinden bu adrese iletir.

MCP Endpoint URL'si

Basit bir yapı https://mcp.example.com/mcp biçiminde düşünülebilir. Üretim ortamında bu adresin arkasında çoğu zaman gateway, load balancer ve birden fazla MCP server replica bulunur.

MCP Endpoint ile Klasik REST API Endpoint Arasındaki Fark

REST API genellikle kaynak ve HTTP metodu merkezli tasarlanır. MCP ise JSON-RPC mesajları, capability bilgisi ve tool çağrıları gibi protokole özgü anlamlar taşır. Aynı HTTP endpoint'i farklı MCP metotlarını karşılayabilir.

Tools, Resources ve Prompts Nedir?

Tools çalıştırılabilir işlevlerdir. Resources bağlamsal veri sağlar. Prompts ise yeniden kullanılabilir mesaj veya iş akışı şablonlarını temsil eder. Server hangi özellikleri desteklediğini capability bilgileriyle belirtir.

Ölçeklenebilir MCP Ağ Uç Noktası Ne Anlama Gelir?

Ölçeklenebilir endpoint, trafik arttığında yalnızca daha güçlü bir makineye geçmek zorunda kalmadan kapasite artırabilen yapıdır. Model Context Protocol (MCP) ile Ölçeklenebilir Ağ Uç Noktaları oluştururken hedef, her isteğin sağlıklı herhangi bir replica tarafından işlenebilmesidir.

Tek Kullanıcılı Local MCP ile Production MCP Arasındaki Fark

Local MCP çoğunlukla tek kullanıcılı ve düşük trafiklidir. Production MCP ise authentication, authorization, timeout, rate limit, çoklu replica, loglama, monitoring ve hata kurtarma gerektirir.

Concurrent Client Sayısı

Aynı anda bağlı veya istek gönderen client sayısı kapasite planının temel girdilerinden biridir. Yüzlerce client'ın eş zamanlı çalışması CPU kullanımından çok downstream servis limitlerini zorlayabilir.

Request Throughput

Throughput, belirli sürede işlenebilen istek miktarını gösterir. Bir MCP endpoint için yalnızca toplam RPS değil, tool bazındaki trafik de izlenmelidir.

Latency

Kullanıcı deneyiminde ortalama latency tek başına yeterli değildir. p95 ve p99 değerleri özellikle yoğun trafik altında daha anlamlı sinyaller verir.

Availability

Tek MCP server kullanmak tek hata noktası oluşturabilir. Birden fazla replica, health check ve doğru load balancing politikası erişilebilirliği artırır.

Horizontal Scaling

Horizontal scaling, daha büyük tek makine yerine server replica sayısını artırır. Stateless MCP modeli bu yaklaşımı doğal biçimde destekler.

Fault Isolation

Bir tool veya downstream sistem çöktüğünde diğer tool'ların da durması istenmez. Ayrı worker pool, timeout ve circuit breaker yaklaşımı hata alanını daraltır.

Multi-Tenant Kullanım

Birden fazla kurum veya ekip aynı MCP altyapısını kullanıyorsa tenant kimliği her istekte açık biçimde taşınmalı ve authorization, cache, rate limit ile log kayıtlarında ayrıştırılmalıdır.

MCP 2026-07-28 ile Ölçeklenebilirlikte Ne Değişti?

2026-07-28 protokol sürümü MCP'nin sunucu ölçekleme modelinde önemli bir değişiklik getirdi. Protokol düzeyindeki session kaldırıldı, her request kendi gerekli protokol bilgilerini taşımaya başladı ve sıradan round-robin load balancing daha uygulanabilir hâle geldi.

Stateful Protokolden Stateless Protokole Geçiş

Önceki modelde bağlantıya bağlı bilgi daha önemliydi. Yeni modelde request, başka bir request'in işlendiği replica'ya bağlı kalmadan çalışabilir.

initialize Handshake'in Kaldırılması

2026-07-28 ile initialize ve initialized akışı kaldırılmıştır. Request'in ihtiyaç duyduğu sürüm ve client capability bilgileri doğrudan request içinde taşınır.

Mcp-Session-Id Yapısının Kaldırılması

Protokol seviyesindeki Mcp-Session-Id kaldırıldı. Bu sayede request routing için belirli bir server instance'a bağlı kalma gereksinimi önemli ölçüde azalır.

Her Request'in Self-Contained Olması

Request'in kendi protokol sürümünü ve capability bilgisini taşıması, herhangi bir sağlıklı instance'ın çağrıyı işleyebilmesini sağlar.

server/discover

server/discover, client'ın server tarafından desteklenen protokol sürümlerini, capability bilgilerini ve server kimliğini öğrenebilmesini sağlar. Server bu RPC'yi destekler ancak client'ın her bağlantıda çağırması zorunlu değildir.

Yeni Mimari Neden Horizontal Scaling'i Kolaylaştırıyor?

Request'ler protokol oturumuna bağlı olmadığında load balancer aynı client'ın ardışık çağrılarını farklı replica'lara gönderebilir. Bu da replica ekleme ve çıkarma süreçlerini sadeleştirir.

Eski MCP Mimarisi Neden Ölçeklenmekte Zorlanıyordu?

Stateful Connection

Server tarafında bağlantıya bağlı bilgi tutulduğunda yeni replica eklemek tek başına yeterli olmaz. İsteğin doğru state'i taşıyan instance'a ulaşması gerekir.

Sticky Session

Sticky session aynı client'ın aynı backend'e yönlendirilmesini sağlar. Ancak trafik eşit dağılmayabilir ve bazı instance'lar diğerlerinden çok daha fazla yük alabilir.

Shared Session Store

Session state'i merkezi store'a taşımak replica bağımlılığını azaltabilir fakat ek ağ çağrısı, gecikme ve yeni bir bağımlılık oluşturur.

Uzun Süre Açık Kalan SSE Bağlantıları

Uzun süre açık bağlantılar connection kapasitesini tüketebilir. Özellikle çok sayıda client olduğunda proxy, gateway ve server limitleri dikkatle yönetilmelidir.

Session Affinity Altında Hot Instance Problemi

Bazı aktif client'lar aynı replica üzerinde toplandığında CPU veya bağlantı kapasitesi dolabilir. Diğer replica'lar boş olsa bile yük dengesi bozulur.

Deployment Sırasında Session Drain Problemi

Stateful bağlantılarda deployment öncesinde aktif session'ların tamamlanmasını beklemek gerekebilir. Stateless request modeli deployment sırasında replica değiştirmeyi kolaylaştırır.

Streamable HTTP Nedir?

Streamable HTTP, remote MCP iletişiminde her mesajın tek MCP endpoint'ine HTTP POST olarak gönderildiği transport modelidir. Yanıt normal JSON veya request kapsamındaki SSE stream biçiminde dönebilir.

Remote MCP İçin Neden Streamable HTTP Kullanılır?

HTTP altyapısı load balancer, gateway, WAF, tracing ve authentication gibi mevcut kurumsal bileşenlerle kolay bütünleşir. Bu nedenle remote MCP server için güçlü bir taşıma seçeneğidir.

/mcp Endpoint Yapısı

Tek bir /mcp endpoint'i farklı JSON-RPC method çağrılarını kabul edebilir. Gateway routing gerekiyorsa method ve tool bilgileri header'lardan da değerlendirilebilir.

JSON-RPC Mesajları

MCP mesajları JSON-RPC 2.0 formatını kullanır. Request id, method, params ve protokole ait metadata birlikte taşınır.

HTTP POST Request Akışı

Client request'i POST ile gönderir. Gateway request'i doğrular, uygun MCP server replica'ya iletir ve yanıt aynı HTTP request bağlamında geri döner.

JSON Response

Kısa işlemlerde server doğrudan JSON response döndürebilir. Bu, klasik request-response davranışına yakındır.

Request-Scoped SSE Response

İşlem sırasında birden fazla event gerekiyorsa yanıt yalnızca ilgili request kapsamında SSE stream olabilir. Bu yapı sürekli açık global stream ihtiyacını azaltır.

Cancellation Nasıl Çalışır?

Client artık ihtiyaç duymadığı isteği iptal edebilmelidir. Server da cancellation sinyalini downstream işlem veya worker katmanına mümkün olduğunca aktarmalıdır.

Streamable HTTP ile Legacy HTTP+SSE Arasındaki Fark

Eski GET Stream Modeli

Eski modelde server kaynaklı bildirimler için uzun ömürlü GET stream kullanımı vardı. Yeni protokol sürümü bu yaklaşımı daha açık request ve subscription modelleriyle değiştirir.

Legacy Session Yönetimi

Eski istemciler session identifier ve initialize handshake davranışına bağlı olabilir. Migration sırasında bu bağımlılıklar belirlenmelidir.

Yeni Stateless Request Modeli

Yeni modelde protokol düzeyinde session yoktur. Her request kendi gerekli bilgilerini taşır ve başka bir replica tarafından işlenebilir.

Yeni Projelerde Hangisi Kullanılmalı?

2026-07-28 uyumlu yeni projelerde Streamable HTTP ve stateless request modeli tercih edilmelidir. Legacy HTTP+SSE artık kullanım dışına alma sürecindedir.

Eski Client'lar İçin Backward Compatibility

Gerçek üretim ortamlarında tüm client'lar aynı anda güncellenmeyebilir. Bu nedenle belirli bir geçiş döneminde legacy ve yeni protokol yollarını birlikte desteklemek gerekebilir.

MCP Endpoint İçin Önerilen Production Mimarisi

Benim tercih ettiğim zihinsel model şu sıradır: client, edge, WAF, API Gateway, stateless MCP server pool, tool katmanı ve downstream servisler. Bu yapının her noktasında auth, timeout ve telemetry sınırları açık olmalıdır.

MCP Client

Client doğru protokol sürümünü ve capability bilgisini gönderir. Retry, timeout ve cancellation davranışı da client tarafında belirlenmelidir.

DNS / Edge Katmanı

DNS ve edge katmanı global kullanıcıları doğru bölgeye yönlendirebilir. Multi-region tasarımında ilk trafik kararı çoğunlukla burada verilir.

CDN / WAF

WAF kötü niyetli trafik kalıplarını erken aşamada engelleyebilir. CDN ise yalnızca gerçekten cache edilebilir içeriklerde kullanılmalıdır.

API Gateway

Gateway authentication, routing, rate limiting, request validation ve merkezi loglama için güçlü bir kontrol noktasıdır. Yazılım mimarisi değerlendirmeleri için https://www.diyarbakiryazilim.com.tr/posts/sektorel-bilisim-denetimlerinde-yazilim-mimarisi-kriterleri adresindeki yaklaşım da incelenebilir.

Stateless MCP Server Pool

Aynı server sürümünü çalıştıran birden fazla replica load balancer arkasında bulunur. Her replica gelen herhangi bir geçerli request'i işleyebilmelidir.

Tool Execution Katmanı

Tool çağrılarının tamamını HTTP handler içinde çalıştırmak her zaman doğru değildir. Uzun veya kaynak tüketen işler ayrı worker'lara aktarılabilir.

Downstream API'ler

MCP server çoğu zaman başka API'lere erişir. Timeout, circuit breaker ve authorization sınırları bu çağrılar için ayrı tanımlanmalıdır.

Database ve Queue

Kalıcı application state database'te tutulabilir. Uzun süren işler ve burst trafik için queue sistemi server katmanını rahatlatır.

Observability Katmanı

Log, metric ve trace birlikte kullanılmalıdır. Bir tool çağrısının gateway'den downstream API'ye kadar izlenebilmesi hata çözüm süresini ciddi biçimde kısaltır.

Stateless MCP Server Nasıl Tasarlanır?

Request Başına Server Context

Authentication bilgisi, tenant bilgisi ve trace context request başına oluşturulmalıdır. Bir sonraki request'in aynı process'e geleceği varsayılmamalıdır.

Process Memory'ye Kullanıcı State'i Yazmamak

Kullanıcıya ait kalıcı bilgi process memory'de tutulursa sonraki request başka replica'ya geldiğinde veri kaybolur. Bu tür state harici bir sisteme taşınmalıdır.

Shared Mutable State'ten Kaçınmak

Global değişkenlerde sürekli değişen kullanıcı veya task state'i saklamak ölçekleme ve eş zamanlılık sorunlarına yol açabilir.

Cross-Request State Gerektiğinde Ne Yapılmalı?

Uygulama state gerektiriyorsa bunu gizlemek yerine açık bir application state olarak tasarlayın. Protokolün stateless olması, uygulamanın hiç state kullanamayacağı anlamına gelmez.

Explicit State Handle

Server bir state handle üretip sonraki request'te normal parametre olarak geri alabilir. Böylece bağımlılık açık biçimde görünür.

Database

Kalıcı ve tutarlı veri için database uygun seçimdir. Tenant ve authorization sınırları sorgu seviyesinde korunmalıdır.

Distributed Cache

Kısa ömürlü ve tekrar üretilebilir bilgiler distributed cache içinde tutulabilir. TTL ve invalidation davranışı önceden belirlenmelidir.

Durable Task Store

Uzun süren task'ların durumu kalıcı task store içinde tutulmalıdır. Worker değişse bile task geçmişi kaybolmamalıdır.

Connection State ile Application State'i Ayırmak

Bağlantının teknik durumu ile kullanıcının iş sürecine ait durum farklı kavramlardır. Bu ayrım doğru yapıldığında stateless transport kullanırken çok adımlı iş süreçleri sürdürülebilir.

Horizontal Scaling Nasıl Çalışır?

Round-Robin Load Balancing

Round-robin gelen request'leri sırayla replica'lara dağıtır. 2026-07-28 sürümünde self-contained request modeli bu basit yöntemi çok daha kullanılabilir hâle getirir.

Her Replica'nın Her Request'i İşleyebilmesi

Sağlıklı herhangi bir replica'nın request'i karşılayabilmesi temel hedeftir. Böylece routing katmanında session affinity ihtiyacı ortadan kalkabilir.

MCP Server Replica Sayısını Artırmak

Trafik yükseldiğinde yeni replica eklenebilir. Yeni instance health check'i geçtikten sonra load balancer trafiğine katılır.

Stateless Scaling'in Avantajları

Scale-out, rolling deployment ve failover daha kolay yönetilir. Replica kaybı belirli kullanıcı session'larını doğrudan kaybetmek anlamına gelmez.

Scale-Out Sırasında Shared State Gerektiren Veriler

Rate limit sayaçları, task durumu veya tenant cache gibi bilgiler replica dışındaki paylaşımlı sistemlerde tutulabilir.

MCP İçin API Gateway Mimarisi

Gateway Neden Kullanılır?

Gateway tüm MCP server'ların tekrar tekrar aynı güvenlik ve trafik kontrol kodunu yazmasını önler. Ortak politikalar tek noktadan uygulanabilir.

Authentication

Client kimliği token veya uygun kurumsal identity sistemiyle doğrulanmalıdır. Geçersiz request backend'e ulaşmadan reddedilebilir.

Authorization

Kimliği bilmek yeterli değildir. Hangi client veya kullanıcının hangi tool'u çağırabileceği ayrıca kontrol edilmelidir.

Routing

Gateway method, tool, tenant veya domain bilgisini kullanarak farklı backend pool'lara trafik yönlendirebilir.

Rate Limiting

Tek bir client'ın tüm kapasiteyi tüketmesini önlemek için gateway seviyesinde limit uygulanabilir. Daha hassas tool limitleri backend ile birlikte yürütülebilir.

Request Validation

Header ile body bilgisinin uyumsuzluğu, geçersiz content type veya aşırı büyük body erken aşamada reddedilmelidir.

WAF

WAF yaygın web saldırılarına ve kötü niyetli request desenlerine karşı ilk savunma katmanlarından biridir.

Logging ve Tracing

Gateway request id ve trace context üretmek için doğru noktadır. Bu bilgiler MCP server ve downstream servislere aktarılmalıdır.

Response Size Limits

Tool'un megabaytlarca çıktı üretmesine izin vermek maliyet ve latency sorunlarına yol açabilir. Response boyutu için sınır belirlemek gerekir.

Mcp-Method ve Mcp-Name ile Header-Based Routing

Mcp-Method Nedir?

Mcp-Method, Streamable HTTP request'inde JSON-RPC method bilgisini header seviyesinde taşır. 2026-07-28 sürümünde standart request header'larından biridir.

Mcp-Name Nedir?

Mcp-Name, ilgili çağrıda tool gibi isimlendirilebilir öğeyi gateway seviyesinde görünür hâle getirebilir.

JSON-RPC Body Parse Etmeden Routing

Gateway method ve name bilgisini header'dan okuyarak body içindeki JSON-RPC verisini ayrıştırmadan routing kararı verebilir.

Tool Bazlı Backend Seçmek

Örneğin search tool trafiği ayrı bir backend grubuna, finans işlemleri başka bir backend grubuna gönderilebilir.

Gateway Üzerinde Tool Bazlı Policy

Header tabanlı görünürlük yalnızca routing için değil, tool seviyesinde farklı politikalar uygulamak için de değerlidir.

Rate Limit

Pahalı tool'lar için daha düşük çağrı limiti tanımlanabilir.

Timeout

Hızlı arama tool'u ile uzun rapor hazırlayan tool aynı timeout değerini kullanmak zorunda değildir.

Authentication

Bazı tool'lar yalnızca doğrulanmış kurumsal client'lara açılabilir.

Authorization

Kullanıcı rolü ve scope bilgisi tool seviyesinde kontrol edilebilir.

Audit

Riskli işlemlerde kim, ne zaman, hangi tool'u hangi tenant adına çağırdı sorusu yanıtlanabilmelidir.

MCP Server'ları Capability Domain'lerine Bölmek

Tek Büyük MCP Server

Az sayıda tool ve tek ekip varsa tek server geliştirme sürecini sade tutabilir. Ancak bütün yetenekleri sınırsız biçimde tek server'a eklemek ileride sorun yaratabilir.

Birden Fazla Domain MCP Server

Yetenekleri iş alanlarına göre ayırmak farklı güvenlik ve ölçekleme ihtiyaçlarını bağımsız yönetmeye yardımcı olur.

CRM MCP Server

Müşteri kayıtları, fırsatlar ve iletişim geçmişi gibi CRM işlemleri tek capability domain altında gruplanabilir.

Finance MCP Server

Finans işlemleri daha güçlü authorization ve audit kuralları gerektirebilir. Ayrı server bu politikaların uygulanmasını kolaylaştırır.

Search MCP Server

Search trafiği genellikle yüksek request sayısı ve farklı cache davranışı üretir. Bu nedenle bağımsız ölçeklenmesi faydalı olabilir.

Infrastructure MCP Server

Altyapı değişikliği yapan araçlar yüksek yetkiye sahip olabilir. Bunların daha dar erişim politikasıyla ayrı tutulması güvenliği güçlendirir.

Ne Zaman Server'ları Ayırmak Mantıklıdır?

Ayrım için yalnızca tool sayısına bakmayın. Trafik, güvenlik, ekip sahipliği ve SLA farklılıkları daha iyi karar kriterleridir.

Farklı Trafik Profili

Bir domain çok yüksek trafik alıyorsa bağımsız scale edilebilir.

Farklı Güvenlik Seviyesi

Okuma ağırlıklı public veri ile hassas write işlemlerini aynı güvenlik sınırına koymak gerekli değildir.

Farklı Ekip Sahipliği

Farklı ekiplerin release döngüsü bağımsızsa server sınırı ekip sorumluluğunu netleştirebilir.

Farklı SLA

Kritik servisler daha yüksek availability hedefi ve ayrı kapasite rezervi kullanabilir.

Tek MCP Endpoint mi Birden Fazla MCP Endpoint mi?

Tek Endpoint'in Avantajları

Client yapılandırması sade olur. Merkezi gateway arkadaki farklı domain server'lara yönlendirme yapabilir.

Domain Bazlı Endpoint'in Avantajları

Her domain kendi auth, ağ ve deployment politikasına sahip olabilir. Sorunların birbirinden ayrılması da kolaylaşır.

Subdomain Stratejisi

finance-mcp.example.com ve search-mcp.example.com gibi subdomain'ler net ağ sınırları oluşturabilir.

Merkezi Gateway Stratejisi

Tek dış endpoint kullanılır, gateway gelen tool veya method bilgisine göre doğru backend'i seçer.

Kurumsal Yapı İçin Karar Kriterleri

Client sayısı, ekip yapısı, güvenlik sınırları, data residency ve operasyon modeli birlikte değerlendirilmelidir.

Tool Tasarımı Ölçeklenebilirliği Nasıl Etkiler?

API Endpoint'lerini Birebir Tool Yapmanın Problemi

Mevcut her REST endpoint'ini ayrı tool'a çevirmek dev bir tool listesi oluşturabilir. Modelin seçim yapması ve client'ın discovery yapması zorlaşır.

Goal-Oriented Tool Tasarımı

Tool'ları iş hedefine göre tasarlamak çoğu zaman daha anlaşılırdır. Örneğin bir görevi tamamlamak için beş düşük seviyeli çağrı yerine tek anlamlı tool tercih edilebilir.

Çok Fazla Tool'un Discovery Maliyeti

Tool catalog büyüdükçe metadata boyutu, cache ihtiyacı ve model bağlamına eklenen bilgi artar.

Tool Input Schema Tasarımı

Schema açık, sınırlı ve öngörülebilir olmalıdır. Gereksiz serbest metin alanları validation ve güvenlik maliyetini yükseltir.

Tool Output Boyutunu Sınırlamak

Tool yalnızca iş için gereken veriyi döndürmelidir. Büyük veri setlerinde tamamını tek response içinde göndermek yerine bölümlendirme kullanılabilir.

Pagination

Büyük listeler sayfalara ayrılmalıdır. Client ihtiyaç duyduğu kadar veriyi isteyebilir.

Filtering

Server tarafı filtreleme, gereksiz veri transferini azaltır.

Aggregation

Modelin tekrar tekrar küçük sorgular göndermesi yerine uygun durumlarda özetlenmiş iş sonucu döndürmek daha verimli olabilir.

MCP Tool Discovery Nasıl Ölçeklenir?

tools/list

tools/list server tarafından sunulan tool'ların listesini getirir. Büyük sistemlerde bu response için cache stratejisi önem kazanır.

Büyük Tool Catalog Problemi

Yüzlerce tool tek listede sunulduğunda response boyutu ve seçim maliyeti artar. Domain ayrımı burada da fayda sağlar.

Deterministic Ordering

2026-07-28 spesifikasyonu tool listelerinin belirli ve tutarlı bir sırayla döndürülmesini önerir. Böylece cache davranışı daha kararlı olur.

Tool Metadata Standardizasyonu

İsim, açıklama ve schema biçimleri ekipler arasında ortak kurallara bağlanmalıdır. Bu, client davranışını daha öngörülebilir yapar.

Tool Catalog'un Bölünmesi

Capability domain bazlı server kullanımı, client'ın ihtiyaç duymadığı yüzlerce tool'u keşfetmesini önler.

Gereksiz Discovery Çağrılarını Azaltmak

Doğru TTL ve cache invalidation yaklaşımıyla sürekli tools/list çağrısı yapılmasına gerek kalmaz.

MCP Cache Stratejisi

ttlMs Nedir?

ttlMs, cache edilebilir sonucun ne kadar süre güncel kabul edilebileceğine ilişkin milisaniye cinsinden ipucu verir.

cacheScope Nedir?

cacheScope, cache içeriğinin paylaşılabilir olup olmadığını ifade eder. 2026-07-28 sürümünde ilgili list ve resource sonuçlarında bu cache alanları tanımlanmıştır.

tools/list Cache

Tool tanımları sık değişmiyorsa cache ciddi trafik tasarrufu sağlayabilir.

prompts/list Cache

Prompt catalog için de benzer yaklaşım uygulanabilir. Değişiklik olduğunda cache'in yenilenmesi gerekir.

resources/list Cache

Resource listesi büyüdüğünde sürekli tam liste çekmek yerine cache ve change notification birlikte kullanılabilir.

resources/read Cache

Paylaşılabilir ve değişim sıklığı düşük resource'lar uygun cache politikasıyla daha hızlı sunulabilir.

Private ve Shared Cache Ayrımı

Kullanıcıya veya tenant'a özel veri shared cache'e yanlışlıkla yazılmamalıdır. Cache key içinde identity sınırı açık biçimde korunmalıdır.

Stale Tool Catalog Problemi

Client eski tool schema'sını kullanırsa request validation hataları oluşabilir. TTL tek başına yeterli değilse notification ile invalidation yapılabilir.

Deployment Sonrası Cache Invalidation

Tool schema değişikliği içeren deployment sonrasında eski catalog'un ne zaman geçersiz sayılacağı release planının parçası olmalıdır.

Uzun Süren MCP Tool Çağrıları Nasıl Yönetilir?

Request İçinde Dakikalarca Beklemenin Problemleri

Uzun request'ler gateway timeout, connection kaybı ve kaynak tüketimi sorunlarına yol açabilir. Kullanıcı tarayıcıyı kapatsa bile server boşuna çalışmaya devam edebilir.

Tasks Extension Nedir?

Tasks, uzun süren işleri request yaşam döngüsünden ayırmaya yarayan bir MCP extension'ıdır. 2026-07-28 ve sonrasında explicit opt-in ile kullanılabilir.

Task Handle

Client'a bir task kimliği döndürülür. Sonraki durum kontrolleri bu handle üzerinden yapılır.

tasks/get

tasks/get client'ın task durumunu sorgulamasını sağlar.

tasks/update

Task ek kullanıcı girdisine ihtiyaç duyuyorsa tasks/update üzerinden gerekli cevaplar gönderilebilir.

tasks/cancel

tasks/cancel iptal talebini iletir. Gerçek iptal davranışı yapılan işin cooperative cancellation desteğine bağlıdır.

Task State Machine

Queued, running, input_required, completed, failed ve cancelled gibi durumlar uygulama tarafından açık biçimde ele alınmalıdır.

Interactive Request Pool ile Worker Pool'u Ayırmak

Kısa MCP request'lerinin uzun veri işleme görevleri tarafından bloke edilmemesi için interactive server ve worker kapasitesi ayrı tutulabilir.

MCP Tasks İçin Queue Mimarisi

Tool Call → Queue → Worker

Uzun işte server hızlı biçimde task oluşturur, işi queue'ya gönderir ve worker daha sonra çalıştırır.

Task Persistence

Task kaydı queue mesajından ayrı ve kalıcı tutulmalıdır. Worker yeniden başlasa bile client durum sorgulayabilmelidir.

Retry

Geçici hatalarda kontrollü retry yapılabilir. Ancak write işlemlerinde idempotency kontrol edilmelidir.

Dead-Letter Queue

Belirli sayıda başarısız olan işler dead-letter queue'ya alınabilir. Böylece sürekli retry döngüsü engellenir.

Task Timeout

Bir task'ın sonsuza kadar running kalmasına izin verilmemelidir. İş türüne göre maksimum çalışma süresi belirlenmelidir.

Worker Autoscaling

Worker sayısı CPU yerine queue derinliğine göre ölçeklenebilir.

Queue Backlog Üzerinden Scaling

Backlog yükseldiğinde worker eklemek, uzun iş yüklerinde yalnızca MCP HTTP server sayısını artırmaktan daha etkili olabilir.

Multi Round-Trip Requests (MRTR) Nedir?

MRTR, server'ın bir işlemi tamamlamak için client'tan ek bilgi isteyebilmesini stateless request modeliyle uyumlu hâle getirir. Server input_required sonucu döndürebilir ve client yanıtlarla original çağrıyı yeniden gönderebilir.

input_required

Bu durum işlemin henüz tamamlanmadığını ve ek client girdisi gerektiğini gösterir.

inputResponses

Client istenen cevapları inputResponses alanı üzerinden gönderir.

Kullanıcı Onayı Gerektiren Tool'lar

Silme, ödeme veya altyapı değişikliği gibi etkili işlemlerde MRTR kullanıcıdan açık onay almak için kullanılabilir.

Eksik Parametre Toplama

Tool çalışırken eksik bilgi fark edilirse request'i hata ile sonlandırmak yerine client'tan tamamlayıcı veri istenebilir.

Stateless Elicitation

Gerekli devam bilgisi request state içinde taşındığında retry farklı replica tarafından işlenebilir.

MRTR Retry Loop'larını Önlemek

Server aynı eksik girdiyi tekrar tekrar istememelidir. Request state içinde hangi adımların tamamlandığı doğrulanmalıdır.

Maksimum Round Sayısı

Uygulama sonsuz kullanıcı etkileşimini önlemek için maksimum round sayısı belirleyebilir.

MCP Subscription ve Gerçek Zamanlı Bildirimler

subscriptions/listen

subscriptions/listen, 2026-07-28 sürümünde client'ın istediği bildirim türleri için uzun ömürlü stream açmasını sağlar. Eski unsolicited GET stream yaklaşımının yerini alır.

Explicit Subscription Modeli

Client hangi bildirimleri istediğini açıkça belirtir. Server her değişikliği tüm client'lara göndermek zorunda değildir.

Notification Type Seçimi

Tools changed, prompts changed veya resource updated gibi ihtiyaç duyulan event türleri ayrı seçilebilir.

Uzun Süreli Stream'lerin Ölçeklenmesi

Subscription stream'i tutan replica ile değişikliği üreten replica farklı olabilir. Bu durumda shared event bus kullanmak gerekir.

Disconnect ve Reconnect

Bağlantı koparsa client yeniden listen açmalı ve gerekli state'i tekrar fetch etmelidir. Event replay garantisi varmış gibi davranılmamalıdır.

Subscription Trafiğini Interactive Trafikten Ayırmak

Çok sayıda uzun stream varsa subscription için ayrı server pool ayırmak kısa request latency'sini koruyabilir.

MCP Endpoint'lerinde Rate Limiting

Kullanıcı Bazlı Rate Limit

Tek kullanıcı belirlenen pencere içinde sınırlı sayıda request gönderebilir.

Client Bazlı Rate Limit

Machine client veya uygulama kimliği için ayrı limit kullanılabilir.

Tenant Bazlı Rate Limit

Kurumsal müşterilerin kapasitesi birbirinden ayrılabilir. Bir tenant'ın ani trafiği diğer tenant'ları etkilememelidir.

Tool Bazlı Rate Limit

Pahalı veya riskli tool'lar için daha düşük limit uygulanabilir.

Cost-Weighted Rate Limit

Her request'i aynı saymak yerine operasyon maliyetine göre puan sistemi kullanılabilir. Basit okuma bir puan, ağır rapor üretimi daha yüksek puan tüketebilir.

Read Tool ve Write Tool İçin Farklı Limitler

Write işlemleri hem risk hem downstream maliyeti nedeniyle daha kontrollü tutulabilir.

HTTP 429 Stratejisi

Limit aşıldığında 429 Too Many Requests döndürülmeli ve client'ın kontrollü backoff uygulaması sağlanmalıdır.

Concurrency Control Nasıl Yapılır?

Maximum In-Flight Request

Bir server'ın aynı anda işleyebileceği request sayısına üst sınır konulabilir.

Tool Bazlı Concurrency

CPU tüketen bir tool yalnızca sınırlı sayıda eş zamanlı çalıştırılabilir.

Tenant Bazlı Concurrency

Büyük bir tenant'ın eş zamanlı yüzlerce request'i tüm worker kapasitesini tüketmemelidir.

Downstream API Limitlerini Korumak

MCP server'ın kapasitesi downstream API kapasitesinden yüksek olabilir. Concurrency limit bu servisleri aşırı yükten korur.

Backpressure

Sistem kapasite sınırına yaklaştığında yeni işleri yavaşlatmalı veya reddetmelidir.

Queueing

Kısa süreli kapasite dalgalanmaları queue ile emilebilir. Ancak sınırsız queue gecikmeyi görünmez biçimde büyütür.

Load Shedding

Sistem kritik seviyede yüklendiğinde düşük öncelikli istekleri erken reddetmek genel hizmet kalitesini koruyabilir.

Timeout Stratejisi Nasıl Tasarlanmalı?

Gateway Timeout

Gateway sonsuz süre backend beklememelidir. Endpoint tipine uygun üst sınır belirlenir.

MCP Handler Timeout

MCP request handler kendi çalışma bütçesini bilmelidir.

Tool Timeout

Her tool aynı timeout'a sahip olmak zorunda değildir. İş türüne göre farklı değerler uygulanabilir.

Downstream API Timeout

Downstream timeout, MCP handler timeout değerinden daha kısa olmalıdır ki server hata işleme için zaman bulabilsin.

Database Timeout

Yavaş sorgular tüm request havuzunu bloke etmemelidir. Database sorgularına uygun limit koymak gerekir.

Timeout Budget

Toplam request bütçesi gateway, tool ve downstream katmanları arasında paylaştırılmalıdır.

Uzun İşleri Tasks'a Taşımak

Normal HTTP request süresine sığmayan işler task mimarisine aktarılmalıdır.

Retry ve Idempotency

Hangi MCP Çağrıları Retry Edilebilir?

Her başarısız request otomatik retry edilmemelidir. İşlemin yan etkisi ve başarısızlığın hangi aşamada oluştuğu değerlendirilmelidir.

Read Tool Retry

Salt okunur ve deterministik tool'lar geçici ağ hatalarında çoğunlukla daha güvenli retry edilebilir.

Write Tool Retry Riskleri

İlk request aslında başarılı oldu fakat response kaybolduysa retry aynı işlemi ikinci kez çalıştırabilir.

Idempotency Key

Write işlemlerinde client tarafından üretilen idempotency key duplicate işlemleri engellemeye yardımcı olur.

Duplicate Tool Execution

Ödeme, kayıt oluşturma veya bildirim gönderme gibi işlemlerde duplicate execution mutlaka düşünülmelidir.

Exponential Backoff

Retry aralığını giderek artırmak başarısız downstream servise sürekli yük bindirilmesini önler.

Jitter

Client'ların aynı anda yeniden denemesini önlemek için retry süresine rastgele küçük fark eklenebilir.

Retry Storm Önleme

Gateway, server ve downstream client aynı anda retry yaparsa tek hata çok sayıda yeni request üretebilir. Retry sorumluluğu katmanlar arasında açıkça belirlenmelidir.

Circuit Breaker ve Bulkhead Pattern

Downstream Servis Çöktüğünde MCP'yi Korumak

Bir bağımlılık çalışmıyorsa MCP server'ın bütün request kapasitesini o servisi bekleyerek tüketmemesi gerekir.

Circuit Breaker

Belirli hata eşiğinden sonra çağrılar geçici süre hızlı biçimde reddedilir. Servis toparlandığında kontrollü deneme yapılır.

Bulkhead Isolation

Farklı tool veya downstream sistemler için bağımsız kapasite havuzları ayrılır.

Tool Bazlı Worker Pool

Ağır tool'lar ayrı worker pool kullanırsa hafif tool'ların latency'si korunabilir.

Failure Domain Oluşturmak

Bir component hatasının yalnızca ilgili yetenek alanını etkilemesi amaçlanır.

Graceful Degradation

Bazı özellikler geçici kapatılırken temel MCP servisleri çalışmaya devam edebilir.

MCP Endpoint Güvenliği Nasıl Sağlanır?

MCP endpoint güvenliği authentication rate limiting ve API gateway yapılandırması ile başlar fakat burada bitmez. Tool permission, input validation, secret yönetimi ve audit zinciri birlikte kurulmalıdır.

Public MCP Endpoint'in Riskleri

Public endpoint internet üzerindeki otomatik taramalara, brute force denemelerine ve kötü niyetli input'lara açıktır.

Authentication

Request'i gönderen kullanıcı veya client güvenilir bir identity mekanizmasıyla doğrulanmalıdır.

Authorization

Doğrulanmış kimliğin yapabileceği işlemler scope, rol ve tenant bilgisine göre sınırlandırılmalıdır.

Least Privilege

Her client yalnızca gerçekten ihtiyaç duyduğu yetkilere sahip olmalıdır.

Tool-Level Permission

Server'a erişim izni, bütün tool'lara erişim anlamına gelmemelidir.

Audit Trail

Özellikle write ve destructive tool çağrıları sonradan incelenebilir biçimde kaydedilmelidir.

Zero Trust Yaklaşımı

Request iç ağdan geliyor diye otomatik güvenilir kabul edilmemelidir. Identity ve permission her erişimde doğrulanmalıdır.

OAuth ile Remote MCP Authorization

MCP Server'ın Resource Server Rolü

Remote MCP server korunan kaynağı sunan resource server gibi davranabilir. Gelen access token doğrulanır ve istenen işlem için uygun yetkiye sahip olup olmadığı kontrol edilir.

Authorization Server

Authorization Server token üretimi ve kullanıcı yetkilendirme sürecini yönetir.

Access Token

Access token kısa ömürlü olmalı ve yalnızca gerekli kaynaklara erişim vermelidir.

Scope

Scope, client'ın yapabileceği işlemleri daraltır. Read ve write izinleri gerektiğinde ayrı tutulabilir.

Resource Identifier

Client hangi protected resource için token istediğini açık biçimde belirtmelidir.

Audience Restriction

Başka servis için üretilen token MCP server tarafından kabul edilmemelidir.

Issuer Validation

Token'ın beklenen issuer tarafından üretildiği doğrulanmalıdır. 2026-07-28 sürümü authorization tarafında issuer doğrulamasını güçlendiren değişiklikler içerir.

Client ID Metadata Documents (CIMD)

MCP Client Kimliği Problemi

Public MCP ekosisteminde çok sayıda bağımsız client bulunduğunda client kimliğinin nasıl tanımlanacağı önemli hâle gelir.

CIMD Nasıl Çalışır?

CIMD yaklaşımı, client metadata bilgisinin tanımlı bir doküman üzerinden sunulmasına dayanır.

DCR ile CIMD Arasındaki Fark

Dynamic Client Registration sunucu tarafında dinamik kayıt akışı kullanırken CIMD metadata belgesi yaklaşımına yönelir. 2026-07-28 sürümünde DCR, backward compatibility için korunurken CIMD yönü resmileştirilmiştir.

Public MCP Ekosisteminde Client Registration

Public server hangi client türlerinin bağlanabileceğini ve hangi kayıt yöntemini kabul edeceğini önceden tanımlamalıdır.

Bilinmeyen Client'ların Kontrolü

Tanımlanamayan veya güven politikasıyla eşleşmeyen client erişimleri sınırlandırılabilir.

On-Behalf-Of Yetkilendirme

MCP Server'ın Downstream API Çağırması

MCP server çoğu zaman son kullanıcı adına başka API çağırır. Downstream sistem kullanıcı bağlamını doğru biçimde bilmelidir.

Son Kullanıcı Kimliğini Korumak

Server bütün istekleri tek genel servis hesabıyla yaparsa gerçek kullanıcı kimliği audit zincirinde kaybolabilir.

Service Account Kullanmanın Riskleri

Çok geniş yetkili service account ele geçirilirse birden fazla tenant veya sistem etkilenebilir.

Scope Daraltma

Downstream token yalnızca yapılacak iş için gereken minimum scope'u içermelidir.

Delegated Authorization

Kullanıcı adına işlem yapılacaksa delegation modeli açıkça tanımlanmalıdır.

Audit Zinciri

Client, kullanıcı, MCP server, tool ve downstream işlem arasındaki ilişki log kayıtlarında takip edilebilir olmalıdır.

Multi-Tenant MCP Server Mimarisi

Tenant Context

Her request hangi tenant adına çalıştığını açık biçimde taşımalıdır.

Tenant Isolation

Bir tenant'ın verisinin başka tenant request'inde görünmemesi temel güvenlik şartıdır.

Tenant Bazlı Authorization

Kullanıcının aynı tool için farklı tenant'larda farklı yetkileri olabilir.

Tenant Bazlı Rate Limit

Her tenant kendi kapasite sınırına sahip olabilir.

Tenant Bazlı Cache

Private cache key tenant identity içermelidir.

Tenant Bazlı Observability

Latency, error ve maliyet değerleri tenant bazında ölçülebilirse sorunlu kullanım daha hızlı anlaşılır.

Cross-Tenant Data Leakage Önleme

Authorization kontrolü yalnızca request girişinde değil, database sorgusu ve cache erişiminde de uygulanmalıdır.

Public ve Private MCP Endpoint Arasındaki Fark

Public Internet MCP

Public endpoint internet üzerinden erişilebilir. DDoS koruması, WAF ve güçlü authentication zorunlu hâle gelir.

Private Network MCP

Private MCP yalnızca kurum ağı veya belirlenmiş network alanından erişilebilir.

VPC / VNet İçindeki MCP Server

Server private subnet içinde tutulup gateway üzerinden kontrollü biçimde sunulabilir.

VPN

Uzak çalışan ekipler private MCP endpoint'e VPN üzerinden erişebilir.

Private Endpoint

Cloud ortamında public IP kullanmadan servisler arasında özel bağlantı kurulabilir.

Internal Service Identity

Servisler arası çağrılarda kullanıcı token'ından bağımsız workload identity kullanılabilir.

Hangi Senaryoda Private MCP Kullanılmalı?

Hassas iç sistemler, yalnızca kurumsal ağdan erişilmesi gereken yönetim tool'ları ve yüksek yetkili altyapı operasyonlarında private yaklaşım güçlü bir seçenektir.

MCP Endpoint'lerinde Ağ Güvenliği

TLS

Remote MCP trafiği TLS üzerinden korunmalıdır. Plain HTTP üretim ortamında kullanılmamalıdır.

Origin Validation

Browser tabanlı client senaryolarında origin kontrolü uygulanmalıdır.

DNS Rebinding Koruması

Özellikle local network servisleri DNS rebinding saldırılarına karşı host ve origin doğrulaması yapmalıdır.

SSRF Koruması

Tool kullanıcıdan URL alıp server tarafında request gönderiyorsa iç servis ve metadata endpoint'lerine erişim sınırlandırılmalıdır.

IP Allowlist

Belirli kurumsal client'ların sabit ağlardan eriştiği senaryoda ek bir katman olarak IP allowlist kullanılabilir.

WAF

WAF anormal request desenlerini, bot trafiğini ve bazı yaygın saldırıları backend'e ulaşmadan engelleyebilir.

DDoS Protection

Public MCP endpoint yüksek hacimli trafik saldırılarına karşı edge seviyesinde korunmalıdır.

Tool Input Güvenliği

JSON Schema Validation

Tool input yalnızca model doğru gönderecek varsayımıyla kabul edilmemelidir. Schema server tarafında uygulanmalıdır.

Maksimum Input Boyutu

Request body ve tool argument boyutu için limit belirlenmelidir.

String Length Limitleri

Serbest metin alanlarında maksimum uzunluk tanımlamak kaynak tüketimini sınırlar.

URL Validation

URL alanları protocol, host ve gerekiyorsa path kurallarına göre doğrulanmalıdır.

Path Traversal

Dosya sistemi kullanan tool'larda ../ benzeri path traversal girişimleri engellenmelidir.

Command Injection

Kullanıcı girdisi shell komutuna doğrudan eklenmemelidir.

SQL Injection

Database sorguları parametreli query ile yürütülmelidir.

Server-Side Request Forgery

Server'ın herhangi bir kullanıcı URL'sine serbestçe erişmesine izin vermek ciddi risk oluşturabilir. Network egress politikası uygulanmalıdır.

Prompt Injection MCP Endpoint'lerini Nasıl Etkiler?

LLM Kararının Yetkilendirme Sayılmaması

Model bir tool'u çağırmaya karar verdi diye kullanıcının o işlemi yapmaya yetkili olduğu varsayılamaz.

Tool Permission Enforcement

Permission kontrolü MCP server veya güvenilir policy katmanında uygulanmalıdır.

Destructive Tool'larda Human Approval

Silme, ödeme veya production değişikliği yapan tool'larda kullanıcı onayı ek güvenlik sağlar.

Input Sanitization

Modelden gelen parametreler diğer dış input'lar gibi doğrulanmalıdır.

Output Trust Boundary

Downstream sistemden gelen metin güvenilir talimat olarak kabul edilmemelidir.

Indirect Prompt Injection

Resource veya web içeriğindeki kötü niyetli metin model davranışını etkileyebilir. Yetki kontrolleri model kararından bağımsız tutulmalıdır.

Secret ve Credential Yönetimi

Secret'ları Tool Result'a Döndürmemek

API key veya token hiçbir durumda normal tool output olarak modele gönderilmemelidir.

Environment Variables

Basit deployment'larda secret environment variable üzerinden inject edilebilir ancak repository veya log içine yazılmamalıdır.

Secret Manager

Kurumsal ortamlarda merkezi secret manager erişim kontrolü ve rotation için daha uygun olabilir.

Token Rotation

Uzun ömürlü credential'lar düzenli yenilenmeli ve eski token hızlı biçimde iptal edilebilmelidir.

Downstream Credential Isolation

Bir tool'un kullandığı credential diğer tool'lar tarafından erişilebilir olmamalıdır.

Per-Tenant Credentials

Her tenant farklı downstream hesabı kullanıyorsa credential eşlemesi güvenli storage içinde tutulmalıdır.

MCP Server Observability

Structured Logging

Log kayıtları JSON gibi işlenebilir formatta tutulursa request id, tenant ve tool alanları kolay sorgulanabilir.

Metrics

Request sayısı, latency, error rate ve queue backlog temel metric'ler arasındadır.

Distributed Tracing

Tek request'in gateway, MCP server, tool ve downstream servisler arasındaki yolculuğu trace ile izlenebilir.

Error Tracking

Exception grupları ve tekrar oranları uygulama sürümüyle birlikte takip edilmelidir.

Audit Logging

Security audit log ile uygulama debug log'u farklı ihtiyaçlara hizmet eder. Hassas işlemler değiştirilemez veya korumalı audit storage'a yazılabilir.

Tool-Level Telemetry

Toplam MCP latency yerine her tool'un success rate ve latency değerini ayrı görmek daha anlamlıdır.

OpenTelemetry ile MCP İzlenebilirliği

Trace Context

2026-07-28 dokümantasyonu traceparent, tracestate ve baggage bilgisinin MCP metadata içinde taşınmasına ilişkin convention tanımlar.

MCP Client → Gateway

Client'tan gelen trace context gateway'de korunmalı veya güvenli biçimde yeni trace ile ilişkilendirilmelidir.

Gateway → MCP Server

Gateway oluşturduğu span bilgisini MCP server'a aktarır.

MCP Server → Tool

Her tool çağrısı ayrı child span olarak kaydedilebilir.

Tool → Downstream API

Downstream HTTP ve database çağrıları aynı trace içinde yer almalıdır.

Tek Trace Üzerinde Uçtan Uca Görünürlük

Böylece yavaşlığın gateway'de mi, MCP handler'da mı yoksa downstream API'de mi oluştuğu hızla anlaşılır.

MCP İçin Hangi Metrikler İzlenmeli?

Requests per Second

Endpoint'e saniyede kaç request geldiğini gösterir.

Concurrent Requests

Aynı anda kaç request işlendiğini takip eder.

Tool Call Count

Hangi tool'un ne kadar kullanıldığını gösterir.

Tool Success Rate

Başarılı tool çağrılarının toplam çağrılara oranıdır.

Tool Error Rate

Hata oranı yükseldiğinde deployment veya downstream sorunları incelenmelidir.

p50 Latency

Tipik kullanıcı deneyimini gösterir.

p95 Latency

Yavaş request grubunun davranışını görmeye yardımcı olur.

p99 Latency

En kötü kullanıcı deneyimine yakın request'leri gösterir.

Task Queue Backlog

Worker kapasitesinin talebe yetişip yetişmediğini gösterir.

Cache Hit Ratio

Cache stratejisinin gerçekten trafik ve latency kazancı üretip üretmediğini anlamaya yardımcı olur.

Rate-Limited Request Sayısı

Limit nedeniyle kaç request'in reddedildiği kapasite ve kullanım analizi için önemlidir.

MCP Endpoint İçin SLI, SLO ve SLA

Availability SLI

Başarılı ve erişilebilir request oranını ölçer.

Latency SLI

Belirli latency eşiği altında tamamlanan request oranı takip edilebilir.

Error Rate SLI

Server ve tool hatalarının toplam request içindeki payını gösterir.

SLO Belirlemek

SLO, hedef hizmet seviyesini ifade eder. Örneğin belirli tool çağrılarının yüzde 99'unun tanımlı sürede tamamlanması hedeflenebilir.

Error Budget

SLO'nun izin verdiği başarısızlık payı release hızı ile güvenilirlik arasında karar vermeyi kolaylaştırır.

Burn-Rate Alerting

Error budget kısa sürede hızla tüketiliyorsa ekip erkenden uyarılmalıdır.

MCP Autoscaling Nasıl Yapılır?

CPU Bazlı Scaling

CPU yoğun tool'larda HPA veya benzer sistemler CPU kullanımına göre replica artırabilir.

Memory Bazlı Scaling

Memory yoğun workload'larda bellek metriği kullanılabilir.

Request Rate Bazlı Scaling

HTTP trafiği belirli eşiği geçtiğinde yeni MCP server instance'ları eklenebilir.

In-Flight Request Bazlı Scaling

Aktif request sayısı CPU'dan daha doğru kapasite sinyali olabilir.

Queue Backlog Bazlı Scaling

Task worker'lar için en anlamlı sinyallerden biri bekleyen iş sayısıdır.

Scale-to-Zero

Düşük kullanılan servislerde maliyeti azaltabilir fakat ilk request için cold start yaratır.

Cold Start Etkisi

Server ayağa kalkarken SDK, credential, database connection veya tool registry hazırlıyorsa ilk request daha uzun sürebilir.

Kubernetes Üzerinde MCP Server

Deployment

MCP server container'ları Deployment ile birden fazla replica olarak çalıştırılabilir.

Service

Service pod'lara sabit ağ erişimi ve load balancing sağlar.

Ingress / Gateway

Dış trafik TLS termination, authentication ve routing politikalarıyla cluster'a alınabilir.

HPA

Horizontal Pod Autoscaler uygun metric'e göre replica sayısını artırıp azaltabilir.

Pod Disruption Budget

Bakım sırasında aynı anda çok fazla pod'un kapanmasını önlemek availability için faydalıdır.

Readiness Probe

Pod gerçekten request almaya hazır olmadan load balancer'a eklenmemelidir.

Liveness Probe

Yanıt veremez hâle gelen process yeniden başlatılabilir.

Session Affinity Neden Gerekmiyor?

2026-07-28 stateless request modelinde protokol session'ı bulunmadığından aynı client request'lerinin sürekli aynı pod'a gitmesi gerekmez.

Serverless MCP Server Mimarisi

Stateless MCP'nin Serverless ile Uyumu

Request'lerin bağımsız olması request bazlı compute modelleriyle doğal biçimde uyumludur.

Request-Scoped Compute

Her çağrı gerektiğinde yeni runtime instance üzerinde işlenebilir.

Cold Start

Düşük trafikte runtime kapatılıyorsa ilk request ek başlatma gecikmesi yaşayabilir.

Execution Timeout

Serverless platformların maksimum çalışma süresi uzun tool'lar için sınırlayıcı olabilir.

Uzun İşleri Task Worker'a Aktarmak

Uzun işlemler queue ve worker sistemine aktarılarak HTTP execution süresinden ayrılabilir.

Serverless Maliyet Modeli

Düşük ve dalgalı trafikte kullanım bazlı fiyatlama avantaj sağlayabilir. Sürekli yüksek trafikte sabit worker altyapısı daha ekonomik olabilir.

Edge MCP Server Kullanmak Mantıklı mı?

Kullanıcıya Yakın Execution

Basit ve bağımsız tool'lar kullanıcıya yakın edge region'da çalıştırılabilir.

Global Endpoint

Tek hostname dünyanın farklı bölgelerindeki edge noktalarına yönlendirilebilir.

Latency Avantajı

Network round trip süresi düşebilir.

Database Region Problemi

Edge function sürekli tek bölgedeki database'e bağlanıyorsa kazanılan latency geri kaybedilebilir.

Edge Runtime Sınırlamaları

Runtime süresi, socket desteği, paket ekosistemi ve filesystem erişimi sınırlı olabilir.

Hangi Tool'lar Edge İçin Uygundur?

Cache ağırlıklı, stateless ve hızlı çalışan tool'lar daha uygundur. Ağır database işlemleri her zaman iyi aday değildir.

Multi-Region MCP Mimarisi

Active–Active

Birden fazla region aynı anda trafik işler. Global load balancer kullanıcıyı uygun bölgeye yönlendirir.

Active–Passive

Bir region ana trafik merkezidir, diğer region failover için bekler.

Global Load Balancer

Health, latency ve coğrafi konuma göre region seçimi yapabilir.

Geo Routing

Kullanıcılar coğrafi olarak yakın veya veri politikası açısından uygun region'a gönderilebilir.

Data Residency

Bazı tenant verilerinin belirli ülke veya bölgede kalması gerekebilir.

Regional Failure

Bir region tamamen erişilemez hâle geldiğinde diğer region trafiği devralabilmelidir.

Cross-Region State

Task, database ve cache state'i region'lar arasında nasıl paylaşılacak veya bölünecek sorusu önceden çözülmelidir.

High Availability ve Disaster Recovery

Replica Failure

Tek pod veya process kaybı kullanıcı tarafından fark edilmemelidir.

Availability Zone Failure

Replica'lar aynı zone'da toplanmamalıdır.

Region Failure

Kritik sistemlerde başka region'a failover planı hazırlanmalıdır.

Downstream Dependency Failure

MCP server sağlıklı olsa bile bağlı API veya database çalışmıyorsa bazı tool'lar kullanılamaz. Dependency health ayrı izlenmelidir.

Recovery Point Objective

RPO kabul edilebilir veri kaybı miktarını tanımlar.

Recovery Time Objective

RTO hizmetin ne kadar sürede geri dönmesi gerektiğini belirler.

Failover Testleri

Failover planı yalnızca dokümanda kalmamalıdır. Kontrollü testlerle gerçekten çalıştığı doğrulanmalıdır.

MCP Server Deployments Nasıl Yapılmalı?

Rolling Deployment

Replica'lar sırayla yeni sürüme geçirilir. Readiness check başarısızsa trafik eski replica'larda kalır.

Blue/Green

Eski ve yeni ortam birlikte çalışır. Trafik doğrulama sonrasında yeni ortama geçirilir.

Canary

Trafiğin küçük bir bölümü yeni sürüme gönderilir. Error ve latency değerleri sağlıklıysa oran artırılır.

Traffic Splitting

Gateway veya service mesh belirli yüzdede trafiği farklı sürümlere dağıtabilir.

Automatic Rollback

Error rate veya latency eşiği aşılırsa yeni deployment otomatik geri alınabilir.

Protocol Compatibility Kontrolü

Client sürümleri farklı olabileceği için deployment yalnızca unit test değil, protokol compatibility testleriyle de doğrulanmalıdır.

MCP Tool Versioning Stratejisi

Tool Name Değişikliği

Tool adını değiştirmek client davranışını etkileyebilir. Geçiş süresince eski ve yeni isim birlikte sunulabilir.

Input Schema Breaking Change

Zorunlu yeni alan eklemek eski client çağrılarını kırabilir.

Output Schema Breaking Change

Alan kaldırmak veya veri tipini değiştirmek consumer tarafında sorun yaratabilir.

Deprecated Tool

Eski tool hemen silinmek yerine deprecated olarak işaretlenip replacement açıklanabilir.

Parallel Version

Gerekirse report_generate_v2 gibi yeni tool bir süre eski sürümle birlikte çalışabilir.

Backward Compatibility

Eski client'ların ne kadar süre destekleneceği ürün politikası olarak tanımlanmalıdır.

MCP Protokol Sürüm Uyumluluğu

MCP-Protocol-Version

HTTP request hangi MCP protokol sürümünü kullandığını belirtmelidir.

Eski Client

Eski client initialize handshake ve legacy transport davranışını bekleyebilir.

Yeni Server

Yeni server yalnızca modern protokolü destekleyebilir veya migration sürecinde legacy uyumluluk katmanı sunabilir.

Feature Negotiation

Client ve server yalnızca iki tarafın desteklediği extension veya capability'leri kullanmalıdır.

Protocol Mismatch

Desteklenmeyen sürüm geldiğinde anlaşılır bir hata dönmek silent failure'dan daha sağlıklıdır.

Compatibility Test Matrix

Production öncesinde desteklenen client ve server sürüm kombinasyonları otomatik test edilmelidir.

Eski Stateful MCP Server 2026 Mimarisine Nasıl Taşınır?

Mcp-Session-Id Bağımlılıklarını Bulmak

Önce kod, middleware ve datastore içinde session id kullanan noktalar belirlenmelidir.

Sticky Session'ı Kaldırmak

Request herhangi bir replica'ya gidebilecek hâle geldikten sonra load balancer affinity kapatılabilir.

Session State'i Application State'e Taşımak

Gerçekten gerekli state database, cache veya explicit state handle modeline geçirilmelidir.

Legacy SSE Akışlarını Belirlemek

Client'ın hangi bildirimler için eski GET stream'e bağlı olduğu çıkarılmalıdır.

MRTR'a Geçmek

Server-to-client etkileşim gerektiren işlemler Multi Round-Trip Request modeline uyarlanabilir.

Tasks Extension'a Geçmek

Dakikalar süren tool'lar request bağlantısında bekletilmek yerine task yapısına taşınabilir.

Header-Based Routing Eklemek

Gateway Mcp-Method ve Mcp-Name bilgisini doğrulayıp routing politikalarında kullanabilir.

Dual-Route Migration

Belirli süre eski ve yeni endpoint davranışları birlikte sunulabilir.

Legacy Trafiği Kademeli Sonlandırmak

Legacy kullanım metric'lerle takip edilir. Kullanım yeterince düştüğünde eski yol kontrollü biçimde kapatılır.

MCP Endpoint Load Testi Nasıl Yapılır?

Baseline Oluşturmak

Önce düşük trafik altında normal latency ve kaynak kullanımı ölçülmelidir.

Short Tool Call Testi

Milisaniyeler içinde tamamlanan tool'larla maksimum request kapasitesi ölçülebilir.

Slow Tool Call Testi

Yavaş downstream API simüle edilerek connection ve in-flight limitleri gözlemlenir.

Concurrent Client Testi

Gerçekçi sayıda client aynı anda farklı tool çağrıları yapmalıdır.

Burst Traffic

Kısa sürede normalin birkaç katı trafik gönderilip autoscaling ve rate limiting davranışı ölçülür.

Rate Limiting Testi

Limit aşıldığında sistemin doğru 429 yanıtı verdiği doğrulanmalıdır.

Cache Testi

Cache hit ve miss senaryolarındaki latency farkı ölçülmelidir.

Task Queue Stress Testi

Queue kapasitesi, worker scaling ve backlog büyümesi yüksek task yükü altında test edilmelidir.

MCP İçin Chaos ve Failure Testing

Replica Öldürme

Aktif trafik sırasında bir replica kapatılır ve request başarısının etkilenip etkilenmediği ölçülür.

Gateway Failure

Gateway node kaybında diğer node'ların trafiği devralması test edilir.

Database Latency

Database gecikmesi yapay olarak artırılarak timeout ve connection pool davranışı izlenir.

Downstream API Timeout

Tool'un bağlı olduğu API cevap vermediğinde MCP server'ın kaynak tüketimi kontrol edilir.

Queue Failure

Task queue geçici olarak ulaşılamaz olduğunda yeni task oluşturma davranışı incelenir.

Region Failure

Multi-region sistemde bir bölge tamamen devre dışı bırakılarak failover doğrulanır.

Recovery Süresini Ölçmek

Sistemin yalnızca geri dönmesi değil, hedef RTO içinde geri dönmesi önemlidir.

MCP Tool'ları Nasıl Test Edilir?

Schema Testleri

Geçerli ve geçersiz input örnekleriyle schema validation test edilir.

Unit Test

Tool iş mantığı dış servislerden izole edilerek test edilebilir.

Integration Test

Database, API ve queue bağlantıları gerçek veya kontrollü test ortamında doğrulanır.

Contract Test

Tool input ve output sözleşmesinin client beklentileriyle uyumu test edilir.

Security Test

Authorization bypass, injection ve aşırı input senaryoları denenmelidir.

Load Test

Gerçekçi trafik altında latency ve error rate ölçülür.

Agent Evals

Modelin doğru durumda doğru tool'u seçip seçmediği örnek görevlerle ölçülebilir.

Regression Evals

Tool açıklaması veya schema değişikliğinin önceki başarılı görevleri bozup bozmadığı kontrol edilir.

MCP Inspector ile Endpoint Testi

Tool Discovery

Server'ın yayınladığı tool listesi ve schema bilgileri kontrol edilir.

Tool Call

Gerçek request ile tool invocation davranışı doğrulanır.

Error Response

Geçersiz input ve internal error senaryolarında anlamlı response dönülmelidir.

Authentication

Token olmadan, geçersiz token ile ve doğru token ile ayrı test yapılmalıdır.

Protocol Compatibility

Desteklenen MCP sürümleri ayrı ayrı denenmelidir.

Production Öncesi Kontroller

Discovery, auth, tool call, timeout ve hata senaryoları release checklist içinde bulunmalıdır.

MCP Endpoint Maliyetleri Nasıl Kontrol Edilir?

Compute Cost

Replica ve worker kullanımının tool başına maliyeti ölçülmelidir.

Network Cost

Büyük tool response'ları ve cross-region trafik beklenenden yüksek network maliyeti oluşturabilir.

Database Cost

Sık çalışan tool'ların sorgu davranışı database maliyetini doğrudan etkiler.

Observability Cost

Her request için çok fazla log ve trace saklamak yüksek depolama maliyeti oluşturabilir. Sampling ve retention politikası uygulanabilir.

Long-Lived Request Cost

Uzun açık bağlantılar compute ve connection kapasitesini tüketir.

Task Worker Cost

Worker autoscaling backlog'a göre ayarlanırsa boş kapasite maliyeti azaltılabilir.

Cache ile Maliyet Azaltmak

Tool catalog ve sık okunan resource verilerinde uygun cache, downstream request sayısını azaltır.

Cost per Tool Call

Gerçek maliyeti anlamanın en yararlı yollarından biri toplam altyapı giderini tool çağrılarıyla ilişkilendirmektir.

Monolithic MCP Server mı Microservice MCP Mimarisi mi?

Monolith'in Avantajları

Küçük ekiplerde tek repository, tek deployment ve ortak runtime geliştirme hızını artırabilir.

Capability-Based Server'ların Avantajları

Farklı trafik ve güvenlik profilleri bağımsız yönetilebilir.

Deployment Karmaşıklığı

Server sayısı arttıkça deployment, monitoring ve ownership süreçleri de artar. Bu nedenle bölme kararı yalnızca moda göre verilmemelidir.

Failure Isolation

Search servisi çöktüğünde finance servisi çalışmaya devam edebilir.

Independent Scaling

Yalnızca yoğun trafik alan domain için replica artırılabilir.

Team Ownership

Her domain server belirli bir ekibin sorumluluğunda tutulabilir.

Hangi Ölçekte Ayrıştırılmalı?

Tool sayısından önce değişim hızı, trafik, güvenlik ve ekip sınırlarına bakmak daha doğru sonuç verir.

MCP Gateway ile Birden Fazla Backend'i Birleştirmek

Unified MCP Endpoint

Client tek endpoint görür. Arkadaki farklı server'lar gateway üzerinden birleşir.

Tool Routing

Gateway Mcp-Name bilgisine göre tool'u ilgili backend'e yönlendirebilir.

Merkezi Identity

Authentication tek noktada uygulanıp doğrulanmış identity backend'e aktarılabilir.

Merkezi Audit

Tüm tool çağrıları ortak audit formatında kaydedilebilir.

Merkezi Observability

Gateway bütün domain'lerin request ve latency dağılımını tek noktadan gösterebilir.

Policy Enforcement

Rate limit, tenant quota ve tool permission politikaları merkezi olarak yürütülebilir.

Gateway'in Single Point of Failure Olmasını Önlemek

Gateway birden fazla replica ve mümkünse birden fazla availability zone üzerinde çalıştırılmalıdır.

MCP Server İçin En İyi Programlama Dili Hangisidir?

MCP Bir Programlama Dili midir?

Hayır. MCP bir protokoldür. Server farklı programlama dilleriyle geliştirilebilir.

TypeScript

Web ve Node.js ekosistemine yakın ekipler için güçlü bir seçenektir.

Python

Veri işleme ve yapay zekâ entegrasyonlarının yoğun olduğu ekiplerde yaygın tercihlerden biridir.

Go

Düşük runtime overhead, güçlü concurrency ve tek binary deployment modeli nedeniyle altyapı servislerinde kullanılabilir.

C#

.NET altyapısı kullanan kurumsal ekipler için doğal bir seçim olabilir.

Dil Seçiminde Performance Tek Kriter midir?

Hayır. MCP server latency'sinin büyük bölümü çoğu zaman downstream API veya database çağrısından gelir.

SDK Olgunluğu

SDK'nın desteklediği güncel protokol sürümü ve extension'lar kontrol edilmelidir. 2026-07-28 sürümüyle Tier 1 SDK'lar TypeScript, Python, Go ve C# tarafında güncellenmiştir.

Ekip Yetkinliği

Ekip iyi bildiği dili kullanıyorsa güvenlik ve operasyon hataları daha az olabilir.

Deployment Platformu

Serverless, container, Kubernetes veya edge runtime seçimi kullanılabilecek dil ve library seçeneklerini etkileyebilir.

Open Source ve MCP Ekosistemi

MCP'nin Açık Standart Yapısı

MCP'nin açık biçimde dokümante edilen protokol yapısı farklı client ve server implementasyonlarının birlikte çalışmasını hedefler.

Official SDK'lar

Resmî SDK'lar protokol sürümlerindeki değişiklikleri uygulama tarafına taşımayı kolaylaştırır.

TypeScript, Python, Go ve C# Ekosistemi

Bu dillerdeki SDK desteği farklı teknoloji ekiplerinin aynı protokol etrafında çalışabilmesine yardımcı olur.

Community SDK'lar

Topluluk tarafından geliştirilen SDK'lar kullanılmadan önce güncel protocol compatibility ve bakım durumu kontrol edilmelidir.

SEP Süreci

Protocol değişiklikleri proposal ve specification süreçleriyle tartışılıp olgunlaştırılır.

Extension Ekosistemi

Tasks gibi özelliklerin extension olarak ayrılması core protokolü daha küçük tutarken isteğe bağlı yeteneklerin gelişmesine alan açar.

Açık Kaynak MCP Server'lara Katkı

İyi bir başlangıç yolu küçük bug düzeltmeleri, test ekleme ve örnek server geliştirme olabilir.

MCP Alanında Yazılımcı Olmak İçin Ne Yapmalı?

HTTP ve JSON-RPC Öğrenmek

Transport ve message modelini anlamadan yalnızca SDK fonksiyonlarını ezberlemek yeterli değildir.

OAuth Temelleri

Remote MCP server geliştirirken token, scope, issuer ve resource kavramları bilinmelidir.

Distributed Systems

Timeout, retry, idempotency ve partial failure kavramları production sistemlerde sürekli karşınıza çıkar.

API Gateway

Routing, rate limit ve merkezi authentication uygulamalı olarak öğrenilmelidir.

Queue ve Async Processing

Uzun tool işlemlerinde queue ve worker mimarisi temel ihtiyaçlardan biridir.

OpenTelemetry

Trace, metric ve log ilişkisini anlamak production sorunlarını çözmeyi kolaylaştırır.

MCP SDK ile Server Geliştirmek

Önce birkaç basit tool içeren küçük server oluşturup ardından auth ve remote transport eklemek öğrenme sürecini hızlandırır.

Production Remote MCP Server Yayınlamak

Asıl öğrenme yalnızca local demo yapmakla bitmez. Gateway, TLS, rate limit, monitoring ve load test ile gerçek production yaklaşımı kurulmalıdır.

Diyarbakır Yazılım Topluluğu ve MCP Ekosistemi

Model Context Protocol (MCP) ile Ölçeklenebilir Ağ Uç Noktaları üzerine çalışan geliştiriciler için topluluk ortamı, yalnızca teoriyi değil gerçek mimari kararları tartışmak açısından değerlidir.

MCP Üzerine Teknik İçerik ve Workshop'lar

Diyarbakır Yazılım Topluluğu üzerinden yazılım mimarisi, yapay zekâ altyapıları ve MCP gibi yeni protokoller üzerine teknik içerikler takip edilebilir.

Remote MCP Server Projeleri

Remote server geliştirmek isteyen ekipler authentication, Streamable HTTP ve gateway entegrasyonunu küçük bir proje üzerinden birlikte ele alabilir.

Open Source MCP Server Geliştirmek

Açık kaynak bir server geliştirmek protocol tasarımını, testing yaklaşımını ve tool schema kararlarını uygulamalı biçimde görmenin iyi yollarından biridir.

AI Agent ve MCP Çalışma Grupları

Ortak çalışma grupları farklı tool tasarımlarının ve production modellerinin karşılaştırılmasına yardımcı olabilir.

Yerel Yazılımcılar Arasında Açık Kaynak İşbirliği

Bir geliştirici gateway üzerinde çalışırken başka biri tool testleri veya observability tarafına katkı sunabilir. Proje örnekleri için https://www.diyarbakiryazilim.com.tr/projects adresine göz atabilirsiniz.

Production MCP Mimarileri Üzerinden Uygulamalı Öğrenme

Sadece “çalışıyor” sonucu yerine neden stateless tasarım kullanıldığı, hangi metric'in izlendiği ve failover sırasında ne olduğu tartışıldığında öğrenme daha kalıcı hâle gelir. Topluluk hakkında daha fazla bilgi için https://www.diyarbakiryazilim.com.tr/about adresi kullanılabilir.

Production MCP Endpoint Kontrol Listesi

Streamable HTTP Kullanılıyor mu?

Yeni remote deployment'ın güncel transport modeline uygunluğu kontrol edilmelidir.

Stateless Çalışıyor mu?

Bir request'in önceki request'i işleyen replica'ya bağımlı olmadığı doğrulanmalıdır.

Sticky Session Kaldırıldı mı?

Application gerektirmiyorsa session affinity kullanılmamalıdır.

Mcp-Method ve Mcp-Name Doğrulanıyor mu?

Header ile body bilgisinin eşleştiği server veya gateway tarafından kontrol edilmelidir.

Authentication Var mı?

Public veya private olmasına bakılmadan kimlik doğrulama politikası belirlenmelidir.

Tool-Level Authorization Var mı?

Server erişimi bütün tool'lara otomatik erişim anlamına gelmemelidir.

Rate Limiting Var mı?

Kullanıcı, tenant ve pahalı tool'lar için limit politikaları tanımlanmalıdır.

Timeout ve Retry Politikası Var mı?

Her katmanın timeout ve retry sorumluluğu belgelenmelidir.

Long-Running İşler Tasks'a Ayrıldı mı?

Dakikalar süren işler normal HTTP request içinde tutulmamalıdır.

Cache Hints Kullanılıyor mu?

List ve resource sonuçlarının TTL ve scope bilgileri doğru seçilmelidir.

OpenTelemetry Var mı?

Trace context gateway'den downstream API'ye kadar korunmalıdır.

SLO Tanımlı mı?

Availability ve latency hedefleri sayısal biçimde belirlenmelidir.

Load Test Yapıldı mı?

Gerçekçi concurrent client ve burst trafik senaryoları denenmelidir.

Legacy Protocol Compatibility Test Edildi mi?

Eski client desteği devam ediyorsa her release'te compatibility matrix çalıştırılmalıdır.

Sıkça Sorulan Sorular

MCP endpoint nedir?

MCP endpoint, client'ın MCP protocol mesajlarını gönderdiği ağ adresidir. Remote kullanımda çoğunlukla Streamable HTTP ile tek bir /mcp endpoint'i üzerinden çalışır.

Remote MCP server nedir?

Local process yerine ağ üzerinden erişilen MCP server'dır. Authentication, TLS, rate limiting ve production monitoring gibi ek gereksinimleri vardır.

MCP için Streamable HTTP nedir?

MCP mesajlarının HTTP POST ile tek endpoint'e gönderildiği ve response'un JSON veya request kapsamlı SSE olabildiği transport modelidir.

MCP sunucularında SSE hâlâ kullanılmalı mı?

SSE tamamen ortadan kalkmış değildir. Streamable HTTP belirli request'lerde request-scoped SSE response kullanabilir ve subscriptions/listen uzun stream açabilir. Kullanım dışına alınan yaklaşım legacy HTTP+SSE modelidir.

MCP 2026-07-28 ile ne değişti?

Protocol-level session ve initialize handshake kaldırıldı. Request'ler self-contained hâle geldi, header-based routing geliştirildi, cache hints eklendi, MRTR ve yeni extension modeli güçlendirildi.

MCP artık tamamen stateless mı?

Protokol core stateless'tir. Ancak uygulama kendi business state'ini database, explicit handle veya durable task store üzerinde tutabilir.

MCP için sticky session gerekli mi?

2026-07-28 request modeli için normal durumda gerekli değildir. Her request herhangi bir sağlıklı server instance tarafından işlenebilir.

MCP server yatay olarak nasıl ölçeklenir?

Server stateless tasarlanır, birden fazla replica load balancer arkasına konur ve shared application state process dışına taşınır.

MCP server'ın önüne API Gateway konulmalı mı?

Her sistem için zorunlu değildir ancak production remote MCP ortamında authentication, routing, rate limiting ve merkezi audit için çok faydalıdır.

Mcp-Method ve Mcp-Name nedir?

Streamable HTTP request'lerinde operation bilgisini HTTP header seviyesinde görünür hâle getiren standart alanlardır. Gateway routing ve policy uygulamalarında kullanılabilir.

Uzun süren MCP tool çağrıları nasıl yönetilir?

Uzun işlemler Tasks extension ile task hâline getirilip worker sisteminde yürütülebilir. Client durumu tasks/get ile takip edebilir.

MCP Tasks Extension nedir?

Uzun süren MCP işlemlerini request bağlantısından ayıran opt-in extension'dır. Task oluşturma, durum sorgulama, güncelleme ve iptal akışlarını tanımlar.

MRTR nedir?

Multi Round-Trip Requests, server'ın işlem sırasında ek client girdisi isteyip daha sonra aynı işlemin devam ettirilmesini sağlayan modeldir.

MCP endpoint OAuth ile nasıl korunur?

Server protected resource olarak konumlandırılır, access token doğrulanır ve issuer, audience, resource ile scope kontrolleri uygulanır.

MCP sunucusu için hangi programlama dili kullanılmalı?

Ekip yetkinliği, SDK desteği ve deployment ortamı esas alınmalıdır. TypeScript, Python, Go ve C# güçlü seçenekler arasındadır.

Kubernetes üzerinde MCP server çalıştırılabilir mi?

Evet. Stateless server'lar Deployment ve Service üzerinden çalıştırılabilir, HPA ile yatay ölçeklenebilir ve gateway üzerinden dışarı açılabilir.

Serverless MCP server ölçeklenebilir mi?

Evet. Stateless request modeli serverless mimariye uygundur. Ancak cold start ve execution timeout gibi platform limitleri değerlendirilmelidir.

Eski MCP sunucuları yeni protokole nasıl geçirilir?

Session id bağımlılıkları kaldırılır, state harici storage'a taşınır, legacy SSE akışları belirlenir ve yeni stateless request modeli kademeli olarak devreye alınır.

Model Context Protocol (MCP) nedir ve ölçeklenebilir ağ uç noktaları oluşturmada nasıl kullanılır?

MCP, yapay zekâ uygulamalarının tools, resources ve prompts sunan server'larla ortak bir protokol üzerinden iletişim kurmasını sağlar. Ölçeklenebilir bir yapıda remote MCP server'lar stateless çalıştırılır, load balancer arkasında çoğaltılır ve uygulama state'i replica belleğine bağlanmaz.

MCP sunucularında Streamable HTTP ile uzak ağ bağlantıları ve endpoint yönetimi nasıl çalışır?

Client JSON-RPC mesajını HTTP POST ile MCP endpoint'ine gönderir. Gateway isteği doğrulayıp uygun server replica'ya yollar. Response kısa işlemlerde JSON, akış gereken durumlarda request-scoped SSE olabilir.

MCP ağ uç noktaları yüksek trafik altında nasıl ölçeklendirilir ve yük dengelenir?

Stateless server replica sayısı artırılır ve request'ler round-robin veya uygun load balancing politikasıyla dağıtılır. Ağır işlemler worker queue'ya taşınır. Autoscaling için yalnızca CPU değil, request rate, in-flight request ve queue backlog gibi sinyaller de kullanılır.

Kurumsal MCP endpoint’lerinde kimlik doğrulama, yetkilendirme ve güvenlik nasıl sağlanır?

OAuth tabanlı authentication, tool-level authorization, least privilege, gateway rate limiting, TLS, WAF, schema validation ve audit logging birlikte uygulanmalıdır. Modelin tool seçmesi hiçbir zaman authorization kontrolünün yerine geçmemelidir.

Yakınımda Model Context Protocol (MCP) entegrasyonu ve ölçeklenebilir yapay zekâ altyapısı danışmanlığı veren yazılım firması nasıl bulabilirim?

Kurumsal MCP server ve ölçeklenebilir AI endpoint entegrasyon hizmeti ararken yalnızca basit bir demo sunulmasına değil, Streamable HTTP, stateless scaling, API Gateway, OAuth, load testing, OpenTelemetry ve deployment süreçlerinin birlikte ele alınmasına dikkat edin. MCP server ve yapay zeka altyapı danışmanlığı yakınımda şeklinde araştırma yapıyorsanız Diyarbakır Yazılım Topluluğu üzerinden teknik içeriklere ve proje çalışmalarına ulaşabilirsiniz: https://www.diyarbakiryazilim.com.tr

Sonuç

Model Context Protocol (MCP) ile Ölçeklenebilir Ağ Uç Noktaları tasarlamanın temel fikri basittir: request'i tek bir server instance'a bağlamayın. Stateless protokol modelinden yararlanın, application state'i doğru yerde tutun, gateway politikalarını merkezi hâle getirin ve uzun işleri task worker'larına ayırın.

Production ortamında başarı yalnızca endpoint'in cevap vermesiyle ölçülmez. İstekler yoğun trafik altında dağıtılabilmeli, bir replica kaybolduğunda sistem devam edebilmeli, kullanıcı yalnızca izinli tool'lara erişebilmeli ve bir hata oluştuğunda hangi katmanda başladığı görülebilmelidir.

MCP mimarisi, remote server geliştirme, API Gateway entegrasyonu, ölçeklenebilir yapay zekâ altyapıları ve yazılım topluluğu çalışmaları hakkında daha fazla bilgi edinmek için Diyarbakır Yazılım Topluluğu'nu ziyaret edebilirsiniz: https://www.diyarbakiryazilim.com.tr