Ana içeriğe geç

MCP Gateway

Genel Bakış​

MCP (Model Context Protocol), AI ajanlarının dış sistemlere standart bir protokolle "araç" (tool) olarak bağlanmasını sağlayan açık bir protokoldür. Apinizer'da MCP, diğer proxy tipleriyle (REST, SOAP, AI) aynı seviyede birinci sınıf bir API Proxy tipidir — kendi başına ayrı bir yönetim ekranı veya kimlik doğrulama modeli taşımaz, mevcut API Proxy yaşam döngüsünün (deploy, redeploy, rollback, export/import) tamamını paylaşır.

Eski modelden fark

Önceki sürümlerde bir API'yi MCP olarak yayınlamak, kendi CRUD ekranına ve kendi kimlik doğrulama moduna (Yok / API Anahtarı / OAuth2) sahip ayrı bir "MCP Inbound Sunucusu" kaydı gerektiriyordu. Bu model tamamen kaldırıldı. Artık MCP yayınlamak, MCP tipinde bir API Proxy oluşturup onun yönlendirme modunu seçmekten ibarettir; kimlik doğrulama da proxy'nin normal politika zincirinden gelir. Ayrıntı için bu sayfanın sonundaki Eski Sürümden Geçiş bölümüne bakın.

Bir MCP Gateway, iki yönlendirme modundan biriyle çalışır:

  • Araçları Aç — mevcut API Proxy operasyonlarınızı, MCP uyumlu her istemcinin keşfedip çağırabileceği MCP araçları olarak yayınlar
  • Passthrough — MCP çağrılarını dış bir MCP sunucusuna iletir, yol boyunca araç filtresi ve çıktı maskeleme uygular

Menüdeki MCP Gateway girişi, MCP Gateway'lerinizin kart görünümlü listesini açar — AI Gateway'lerle aynı düzen; bir kartı açtığınızda o proxy'nin Overview, yönlendirme, politika ve trace/trafik/analitik sekmelerine ulaşırsınız.

Proxy Bilgisi Alanları​

Her MCP Gateway'in Overview sekmesinde, tüm proxy tiplerinde bulunan proxy bilgisi panelinin yanında üç MCP'ye özgü alan da gösterilir:

AlanAçıklama
Routing ModuAraçları Aç ya da Passthrough değerini gösterir; Araçları Aç modunda kaç aracın yayınlandığı ve hangi kaynak API proxy'sinden geldiği bilgisi de eklenir.
MCP Protokol SürümüBir sonraki deploy'da geçerli olacak, üzerinde anlaşılan protokol sürümü — bkz. Protokol Sürümleri.
İstemci Kimlik DoğrulamasıYok ya da Gerekli değerini alır; proxy'ye herhangi bir istek politikası eklendiği anda otomatik olarak Gerekli gösterir.

Apinizer'ı bunun tersi yönde, yani dış bir MCP sunucusunun istemcisi olarak kullanmak — onun araçlarını kendi AI akışınıza katmak — için ayrı bir MCP Gateway'e gerek yoktur; bu, herhangi bir AI Gateway'e eklenen MCP Çağrısı (LLM) / MCP Çağrısı (Sabit) politikasıyla yapılır, bkz. Giden Araç Çağrısı.

bilgi

Model Context Protocol kavramına genel bir giriş için Yapay Zeka Temel Kavramları sayfasına bakabilirsiniz. Bu sayfa Apinizer'ın MCP desteğine odaklanır.

Hızlı Başlangıç​

MCP tipinde bir API Proxy oluşturun

MCP tipinde bir API Proxy oluşturma akışını başlatın — proxy tipi zaten MCP olarak seçili gelir, bir tip seçim ekranı gösterilmez ve doğrudan minimal bir oluşturma formu açılır. Proxy'ye tek bir istemci relative path'i (örn. /mcp/asistan) atanır — bu tek yol, hem JSON-RPC trafiğini hem de discovery belgesini taşır.

Yönlendirme modunu seçin

Proxy'nin MCP Routing sekmesini açın. Routing Modu bölümündeki Yapılandır düğmesini seçin. Açılan çekmecede iki moddan birini seçin: mevcut proxy'lerinizi araç olarak sunmak için Araçları Aç, dış bir MCP sunucusuna geçiş yapmak için Passthrough. Kaydet düğmesini seçin. Sekme, kaydedilen modun bölümlerini gösterir. Aşağıdaki Modlar bölümüne bakın.

Moda göre yapılandırın

Araçları Aç modunda hangi API proxy/metotların hangi araç adıyla sunulacağını ekleyin. Passthrough modunda arka uç MCP sunucusunu/sunucularını satır içi tanımlayın ve gerekiyorsa araç izin listesini daraltın.

Deploy edin

Proxy'yi normal bir API Proxy gibi bir ortama deploy edin. Deploy geçmişi, redeploy ve rollback davranışı diğer proxy tipleriyle birebir aynıdır.

İstemciyi bağlayın

Proxy'nin Overview sekmesindeki İstemci Uç Noktaları bölümünden MCP adresini ve istemciniz için kopyalamaya hazır bir komutu kopyalayın — bkz. İstemci Uç Noktaları (Overview). İsterseniz istemciyi doğrudan proxy'nin relative path'ine JSON-RPC ile bağlayabilir ya da önce {relativePath}/.well-known/mcp/server.json üzerinden keşfedebilirsiniz. Discovery belgesi kimlik doğrulamadan muaftır; asıl erişim kontrolü, istek proxy'nin politika zincirinden geçerken uygulanır.

MCP uç noktası https://api.apinizer.com/apigateway/aigw/petstore-mcp/ olan bir proxy için discovery yanıtı (server.json) örneği:

{
"$schema": "https://static.modelcontextprotocol.io/schemas/2025-09-29/server.schema.json",
"name": "com.apinizer/aigw-petstore-mcp",
"description": "Apinizer MCP Gateway: Petstore Proxy",
"version": "1.0.0",
"remotes": [
{
"type": "streamable-http",
"url": "https://api.apinizer.com/apigateway/aigw/petstore-mcp/",
"headers": [
{
"name": "Authorization",
"description": "Bearer <access_token> obtained from https://api.apinizer.com/apigateway/auth/token",
"isRequired": true,
"isSecret": true
}
]
}
],
"_meta": {
"com.apinizer": {
"protocolVersion": "2025-06-18",
"authRequired": true,
"auth": [
{
"scheme": "bearer",
"tokenEndpoint": "https://api.apinizer.com/apigateway/auth/token",
"grantType": "client_credentials"
}
]
}
}
}

Belge, MCP Registry server.json şemasına uyar: remotes[] bağlanılacak adresi, taşıma tipini ve — proxy'nin istek politikası zincirinde bir kimlik doğrulama politikası varsa — istemcinin göndermesi gereken başlığı taşır; yukarıdaki örnekte bu, gateway'in kendi /auth/token uç noktasından client_credentials ile alınan bir OAuth2/JWT erişim token'ıdır (bkz. Kimlik Doğrulama). _meta altındaki com.apinizer alanı yalnızca protokol sürümünü (protocolVersion), genel kimlik doğrulama gerekliliğini (authRequired) ve aynı türetilen kimlik doğrulama bilgisini makine tarafından okunabilir biçimde (auth) taşır — proxy kimliği, adı veya yönlendirme modu gibi gateway'e özgü hiçbir bilgi burada yayınlanmaz: bu belge kimlik doğrulaması olmadan her çağırana açıktır ve anonim bir çağıranın bu iç bilgileri öğrenmesi için bir neden yoktur.

MCP Routing sekmesi anında kaydeder

MCP Routing sekmesinde altta Kaydet düğmesi yoktur. "Kaydedilmemiş değişiklik" uyarısı da yoktur. Her değişiklik, yaptığınız anda sunucuya yazılır.

  • Ayar tutan her bölüm — Routing Modu, Araç Çıktı Filtresi ve Keşif — server.json — salt okunur gösterilir. Her bölümün sağ üstünde bir Yapılandır düğmesi vardır. Düğme sağdan bir çekmece açar. Ayarı çekmecede değiştirin ve Kaydet düğmesini seçin. İptal düğmesi değişikliği atar.
  • Her çekmecenin kendi Kaydet düğmesi vardır: Araç Ekle / Düzenle, Sunucu Ekle / Düzenle ve Routing Modu, Araç Çıktı Filtresi ile server.json için Yapılandır. Düğme değişikliği sunucuya yazar. Çekmece yalnız kayıt başarılı olursa kapanır. Kayıt reddedilirse çekmece açık kalır ve girdiğiniz bilgi korunur.
  • Sekme yüzeyinde kalan az sayıda alan değiştiği anda kaydedilir: istemci token'ını iletme, izin verilen araç adları listesi, Keşif — server.json bölümündeki Otomatik üret / Özel seçimi ve satır silme.
  • Bir araç ya da arka uç sunucu satırını silmeden önce Apinizer onay sorar. Sil düğmesini seçerseniz satır silinir ve bu değişiklik hemen kaydedilir. İptal düğmesini seçerseniz hiçbir şey değişmez.
  • Kayıt sürerken sekmedeki denetimler kısa süre kapalı kalır.
  • Kayıt reddedilirse sekme en son kaydedilen duruma döner. Ekranda gördüğünüz değer her zaman sunucudaki değerdir.
  • Kaydedilen değişiklik, gateway'e ulaşmak için deploy gerektirir.

Mevcut Bir API Proxy'den Oluşturma​

Elinizde zaten yayında olan bir REST veya SOAP API Proxy varsa, uç noktalarını tek tek araç satırı olarak girmenize gerek yoktur: MCP Gateway'e Dönüştür aksiyonu, o proxy'nin yanına hazır bir MCP Gateway üretir.

Aksiyona iki yerden ulaşabilirsiniz:

  • API Proxy listesinde ilgili satırın üç nokta menüsünden
  • Proxy'nin detay ekranının üst çubuğundan

Aksiyon yalnızca REST ve SOAP proxy'lerde görünür; MCP, A2A, AI, gRPC ve WebSocket proxy'lerinde gösterilmez. Ayrıca AI Gateway lisans modülü gerektirir — modül yoksa oluşturulan proxy sonradan erişilemez hale gelir, çünkü MCP Gateway'ler AI Gateway menü grubu altında yaşar.

Kaynak proxy'ye dokunulmaz

Dönüştürme adı bir yer değiştirme gibi görünse de, kaynak proxy hiç değişmez: tipi, yönlendirmesi, politikaları, kimlik bilgileri, erişim listeleri ve deploy durumu aynen kalır, trafiğini eskisi gibi karşılamaya devam eder. Üretilen MCP Gateway, Araçları Aç modunda çalışır ve her araç çağrısını kaynak proxy'ye geri yönlendirir — dolayısıyla kaynak proxy üzerindeki tüm politikalar MCP çağrılarında da işler.

Dönüştür penceresi, kaydetmeden önce üretilecek araçların listesini gösterir: araç adı, metot, uç nokta ve girdi şemasının nereden geleceği. Ad ve geçit adresi alanları önerilen değerlerle dolu gelir (<kaynak adı> MCP ve <kaynak geçit adresi>-mcp); ikisini de değiştirebilirsiniz.

Üretim kuralları:

  • Yalnızca aktif uç noktalar araç olur. Pasif bir uç nokta atlanır.
  • Araç adı önce spesifikasyondaki operationId'den, yoksa özet (summary) alanından, o da yoksa <METOT>_<yol> biçiminden türetilir; ardından MCP adlandırma kuralına göre normalize edilir ve katalog içinde tekilleştirilir (_2, _3 ekleriyle).
  • REST kaynakta araç şeması saklanmaz — gateway, her tools/list çağrısında kaynak proxy'nin spesifikasyonundan operasyona özel şemayı üretir. Önizleme tablosunda bu satırlar Otomatik olarak işaretlenir.
  • SOAP kaynakta araç şeması kaydedilir ve tek bir body metin argümanı içerir; WSDL'den otomatik şema çıkarımı bilgi kaybettirdiği için tercih edilen davranış budur. Bu satırlar WSDL'den olarak işaretlenir; gerekiyorsa şemayı sonradan MCP Routing sekmesinden düzenleyebilirsiniz.
  • Kaynak proxy'nin aktif hiçbir uç noktası yoksa dönüştürme reddedilir.
  • Hedef ad ya da geçit adresi kullanımdaysa dönüştürme reddedilir; pencerede değiştirip yeniden deneyebilirsiniz.
Yeni gateway dağıtılmamış gelir

Üretilen MCP Gateway deploy edilmemiş olarak oluşturulur. Araç listesini gözden geçirdikten sonra, diğer proxy'lerde olduğu gibi bir ortama deploy etmeniz gerekir.

Aynı işi CI/CD hattından yapmak için Create MCP Gateway from an API Proxy uç noktasını kullanabilirsiniz.

Modlar​

Araçları Aç (Tool Expose)​

Mevcut bir API proxy'nin uç noktalarını MCP aracı olarak yayınlar. Her satırda bir kaynak API proxy, (opsiyonel) belirli bir metot, sunulacak araç adı/açıklaması, gerekirse bir şema override'ı ve OAuth2 için zorunlu scope'lar tanımlanır.

not

Zorunlu scope alanı yalnızca çağıran OAuth2 ile kimlik doğrulamışsa uygulanır; diğer kimlik doğrulama tiplerinde (API Anahtarı, JWT, Basic, vb.) yok sayılır.

Araç Adı nasıl yayınlanır​

Bir satıra girdiğiniz Araç Adı, tools/list yanıtında görünmeden önce MCP adlandırma kuralına göre normalize edilir: küçük harfe çevrilir, harf ve rakam dışındaki her karakter alt çizgiye dönüşür, tekrar eden alt çizgiler teke iner ve ad en fazla 64 karakterde kesilir. Örnek: Check Availability → check_availability, hotelDetails → hoteldetails. İki satırın adı aynı değere normalize olursa ikinci satır _2, üçüncüsü _3 eki alır; böylece hiçbir araç kataloğa girmeden kaybolmaz.

Alanı boş bırakırsanız ad, kaynak proxy'nin teknik kimliğinden türetilir — okunabilir bir ad görmek için alanı doldurun.

Adı, satırın sağından açılan çekmecede düzenlersiniz. Çekmecedeki Listeye Uygula düğmesi değişikliği yalnızca aşağıdaki tabloya yazar; sunucuya bu adımda hiçbir şey gitmez. Kaydı tamamlamak için sekmenin altındaki Kaydet düğmesine basmanız gerekir — kaydedilmemiş değişiklik varken sekmenin üstünde bunu bildiren bir uyarı durur ve yalnızca kayıt başarılı olduğunda kaybolur. Sıra kısaca şudur: Listeye Uygula → Kaydet → yeniden yükle (deploy). Ortadaki adımı atlarsanız tabloda yeni adı görürsünüz ama gateway eski adı sunmaya devam eder.

Yeni ad deploy'dan sonra görünür

Gateway her zaman en son deploy edilen yapılandırmayı sunar. Bir araç adını değiştirip kaydetmek tools/list yanıtını tek başına değiştirmez; yeni ad ancak proxy'yi ilgili ortama yeniden deploy ettikten sonra istemcilere ulaşır. Kaydedilmiş ama henüz deploy edilmemiş değişiklik varsa, MCP Routing sekmesinin üstünde bunu bildiren bir uyarı görünür.

Passthrough modunda bu normalizasyon uygulanmaz — o modda adları arka uç MCP sunucusu belirler ve Apinizer onları olduğu gibi geçirir. Bu yüzden tools/list yanıtında büyük harfli (örneğin hotelDetails) bir ad görüyorsanız, o yanıt Araçları Aç yapılandırmanızdan değil, ya bir Passthrough yapılandırmasından ya da henüz güncellenmemiş eski bir deploy'dan geliyordur.

Bir istemcinin siparis_sorgula adlı bir aracı çağırma isteği şu şekilde görünür:

{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "siparis_sorgula",
"arguments": { "siparisNo": "SP-10245" }
}
}

Passthrough​

Proxy'ye gelen her MCP çağrısını, arka uç bir MCP sunucusuna olduğu gibi iletir. Bir araç izin listesi ile hangi araçların dışarıya açılacağı daraltılabilir:

  • İzin listesi boş ve sunucuda en az bir araç keşfedilmişse, keşfedilen kataloğun tamamı kullanılabilir olur.
  • İzin listesi boş ve keşfedilen katalog boşsa, hiçbir araç kullanılamaz — sessiz/varsayılan bir açık erişim yoktur. (Sunucu keşif anında hiç yanıt vermezse istek zaten bir hata döner; bu madde yalnızca sunucunun geçerli ama boş bir katalog döndürdüğü duruma ilişkindir.)
  • İzin listesi doluysa, yalnızca hem keşfedilen kataloğun hem de izin listesinin kesişimindeki araçlar kullanılabilir.

Bir aracın çalıştırdığı işlem, her iki modda da Apinizer'ın normal politika zincirinden geçer — Kişisel Veri (PII) Maskeleme, İstem Koruması, Veri Sızıntısı Koruması (DLP), Konu-Dışı Koruması ve Tekrar-Fırtınası (Loop) Koruması gibi gelişmiş korumalar hem araç çağrısının argümanlarına (params.arguments) hem araç sonucuna uygulanır. Bir MCP Gateway'ine yalnızca bu beş koruma eklenebilir; bir LLM çağrısına doğrudan bağlı diğer AI politikaları (Semantik Önbellek, Token Kotaları, Prompt Süsleyici, Prompt Şablonları, RAG, Bağlam Bütünlüğü Koruması) kaydetme adımında reddedilir. Ayrıca araç çıktısı, PII maskeleme ve engelleme desenleri (regex) ile ayrıca filtrelenebilir. İstem Koruması ve Konu-Dışı Koruması bir MCP Gateway'inde kullanıldığında, aynı politikaların taşıdığı dış sağlayıcı guardrail desteği de bu proxy'de aynen çalışır — araç argümanları/sonucu, tanımlıysa bir dış LLM hakemine de gönderilir.

Passthrough modundaki arka uç MCP sunucusu/sunucuları, proxy'nin MCP Routing sekmesinde, ayrı bir bağlantı ekranına gitmeden doğrudan tanımlanır:

Arka uç sunucuyu ekleyin

MCP Routing sekmesinin Passthrough bölümünde Sunucu Ekle ile bir satır açın; sunucunun adresini, kimlik doğrulama bilgilerini ve gerekiyorsa mTLS ayarlarını aynı satırda girin. Her satır tek bir endpoint taşır — ayrı bir failover/yedek sunucu alanı yoktur. Aynı çekmecede Routing Modu bölümünden de sunucu ekleyebilirsiniz; bkz. Routing Modu Bölümü.

Sunucuyu kaydetmeden deneyin

Sunucu çekmecesindeki Araçları getir düğmesini seçin. Apinizer, çekmecede yazan adres ve kimlik bilgisiyle sunucuya bağlanır ve sunduğu araçları listeler. Bkz. Sunucuyu Kaydetmeden Deneme.

Deploy edin ve kataloğu doğrulayın

Proxy ilk kez deploy edildiğinde Apinizer, tanımlı sunucunun/sunucuların araç kataloğunu otomatik olarak keşfeder.

Sağlık durumunu izleyin

Her sunucu periyodik olarak yoklanır (health probe); erişilemeyen bir sunucu proxy'nin durumunda işaretlenir.

Passthrough yapılandırması APIops REST API ile de yönetilebilir; bkz. API Referansı: API Proxies — Update MCP Routing.

Arka Uç Hata Yanıtları​

Passthrough çağrısında MCP sunucusu hata verirse gateway -32603 kodlu bir JSON-RPC hatası döndürür. error.message alanı bu hata tipi (ERR-262) için tanımlı hata mesajını taşır (varsayılan: Tool execution failed.). error.data alanı çağrının neden başarısız olduğunu istemciye bildirir:

{
"jsonrpc": "2.0",
"id": 1,
"error": {
"code": -32603,
"message": "Tool execution failed.",
"data": { "reason": "BACKEND_AUTH_FAILED", "phase": "discovery", "httpStatus": 401 }
}
}
  • phase değeri, gateway sunucudan araç listesini alamadıysa discovery olur. Araç çağrısının kendisi başarısız olduysa call olur.
  • httpStatus alanı yalnız sunucu bir HTTP hata durumu döndürdüyse görünür.
  • backendErrorCode alanı yalnız sunucu bir JSON-RPC hatası döndürdüyse görünür. Sunucunun hata kodunu taşır.
reasonAnlamıKontrol edin
CONNECTION_CONFIGURATION_ERRORBağlantı tanımı çağrıyı engelliyor.Giden trafik koruması (private adres), mTLS anahtar deposu, katalog kayması engeli.
BACKEND_UNREACHABLEWorker sunucuya ulaşamıyor.Sunucu adresi, DNS, güvenlik duvarı. localhost kullanmayın — bu adres worker pod'unu gösterir.
BACKEND_TIMEOUTSunucu zamanında yanıt vermedi.Sunucu yükü ve ağ gecikmesi.
BACKEND_TLS_ERRORTLS el sıkışması başarısız oldu.Sunucu sertifikası ve güven deposu.
BACKEND_AUTH_FAILEDSunucu veya OAuth2 token uç noktası kimlik bilgisini reddetti.Sunucu satırının kimlik doğrulama ayarları. Token aktarımı açıksa istemci token'ı.
BACKEND_HTTP_ERRORSunucu başka bir HTTP hata durumu döndürdü.httpStatus değeri ve sunucu logları.
BACKEND_TOOL_ERRORSunucu bir JSON-RPC hatası döndürdü. Aracın kendisi başarısız oldu.backendErrorCode değeri ve sunucu logları.
BACKEND_PROTOCOL_ERRORYanıt geçerli bir MCP yanıtı değil ya da protokol sürümü uyuşmuyor.Sunucu satırının MCP Protokol Sürümü alanı. Adresin bir MCP uç noktası olduğundan emin olun.
BACKEND_CONNECTION_ERRORBaşka bir iletim hatası oluştu.Worker logu.

Yanıt; sunucu adresini, hata metnini ve sunucunun hata gövdesini hiçbir zaman taşımaz. Worker logu tam ayrıntıyı MCP PASSTHROUGH ile başlayan bir uyarı satırında tutar.

Sunucuyu Kaydetmeden Deneme​

Sunucu Ekle / Sunucuyu Düzenle çekmecesinde, kaydetme satırının üstünde bir Araçları getir düğmesi vardır. Düğme, çekmecede o an yazan adres, kimlik bilgisi ve mTLS ayarlarıyla sunucuya bağlanır ve sunucunun sunduğu araçları listeler: araç adı, açıklaması ve bir adet rozeti.

  • Bu işlem hiçbir şey kaydetmez. Passthrough modunda gateway, arka uç kataloglarını istek anında zaten canlı çözer. Liste bir doğrulamadır: "adres ve kimlik bilgisi çalışıyor, sunucu bunları sunuyor".
  • Kayıtlı bir sunucuyu düzenliyorsanız token'ı yeniden yazmanız gerekmez. Maskeli alana dokunmayın; Apinizer denemede kayıtlı kimlik bilgisini kullanır.
  • Adres girilene kadar düğme pasiftir. Çağrı başarısız olursa çekmecedeki bilgiler korunur ve sunucunun bildirdiği neden ekranda yazar: bir HTTP durumu (MCP server returned HTTP 404), reddedilen bağlantı, engellenen hedef ya da MCP tools/list sonucu olmayan bir yanıt. Adresi, kimlik bilgisini ya da ağ erişimini düzeltin ve düğmeyi yeniden seçin.
  • Deneme, gateway worker'ından değil Manager'dan koşar. Adres Manager'dan erişilebilir olmalıdır. Loopback adresleri (127.0.0.1, localhost), link-local ve bulut metadata adresleri Özel ağ erişimine izin ver anahtarı açıkken de reddedilir; o anahtar yalnız RFC1918 ve küme içi hedefleri açar. Yalnız kendi makinenizde erişilebilen bir MCP sunucusu bu yolla denenemez.
  • Sık yapılan bir hata, MCP olmayan bir proxy adresinin (örneğin bir AI Gateway proxy'si) girilmesidir. Böyle bir adres yanıt verir ama MCP el sıkışması yapmaz; deneme bağlantı hatası yerine protokol hatası ile biter.

Arka Uç MCP Sunucusu Listesi​

Arka Uç MCP Sunucusu bölümü her sunucuyu ayrı bir kartta listeler. Kartta sunucunun adı ve adresi yazar. Rozetler protokol sürümünü, kimlik doğrulama yöntemini, özel ağ erişimini ve yetenek önbelleğini gösterir. Yapılandır düğmesi sunucunun çekmecesini açar. Çöp kutusu simgesi sunucuyu siler.

Her kartın altında o sunucunun araç paneli vardır. Karttaki Araçları getir düğmesini seçin. Apinizer yalnız o sunucuya, kayıtlı adres ve kimlik bilgisiyle bağlanır; token'ı yeniden yazmanız gerekmez. Panel, sunucunun bildirdiği araçları adı ve açıklamasıyla listeler.

  • Liste kaydedilmez. Bu canlı bir keşiftir; çekmecedeki deneme ile aynıdır. Gateway her istekte arka uca yeniden sorar. Ekranda gördüğünüz o anın yanıtıdır, proxy'nin sakladığı bir katalog değildir.
  • Her araç izinli ya da engelli rozeti taşır. Rozet, sunucu listesinin üstündeki İstemci Erişimi ve İletim bölümünde yer alan İzin Verilen Araç Adları listesinden okunur. Liste boşsa keşfedilen her araç izinlidir. İzin listesi dışında kalan araç gizlenmez; bilerek engelli rozetiyle gösterilir. Aksi hâlde sunucuda olmayan bir aracı, yalnız izin listenizde olmayan bir araçtan ayırt edemezsiniz.
  • Kimlik bazlı bir kural (bkz. Güvenlik ve Governance) izinli bir aracı tek bir çağırandan gizleyebilir. Rozet proxy geneli kararı bildirir, çağıran bazlı kararı değil.
  • Sunucuya erişilemezse panel bunu yazar ve sunucunun bildirdiği nedeni gösterir: bir HTTP durumu, reddedilen bağlantı ya da engellenen hedef. Nedeni sayfadan çıkmadan görür, adresi ya da kimlik bilgisini düzeltirsiniz.

Routing Modu Bölümü​

MCP Routing sekmesinin en üstündeki Routing Modu bölümü salt okunur bir özettir: etkin modun kartı vurgulanır, diğer kart soluk gösterilir ve istemcilere bildirilen protokol sürümü bölüm başlığının yanında yazar.

İkisini de değiştirmek için Yapılandır düğmesini seçin. Düğme sağdan bir çekmece açar. Çekmecede modu ve protokol sürümünü seçin, sonra Kaydet düğmesini seçin. İptal düğmesi değişikliği atar. Mod, sekmede hangi bölümlerin görüneceğini belirler: Araçları Aç modunda Açık Araçlar, Passthrough modunda Arka Uç MCP Sunucusu. Bu bölümler yalnız kayıt başarılı olduktan sonra değişir. Çekmecede iki modun açıklamasını okurken sayfanın altındaki bölümler yerinde kalır. Mod değiştirdiğinizde her modun kendi ayarları korunur; iki mod arasında bilgi kaybetmeden gidip gelebilirsiniz.

Çekmecede Passthrough modunu seçtiğinizde, iki mod kartının altında bir Arka Uç MCP Sunucusu listesi de görünür. Passthrough yalnız en az bir arka uç sunucu varken geçerlidir. Arka Uç MCP Sunucusu Ekle düğmesini seçin. Düğme, sunucu çekmecesini mod çekmecesinin üstünde açar. Bilgileri girin ve Kaydet düğmesini seçin. Sunucu o anda kaydedilir; mod seçiminiz korunur. Kayıtlı sunucular listede Düzenle ve Sil düğmeleriyle görünür. Liste boşken mod çekmecesinin Kaydet düğmesi pasif kalır ve bir uyarı nedenini yazar. Böylece önce Passthrough kaydedip sonra "Passthrough en az bir arka uç MCP sunucusu ister" reddini almazsınız.

Araç Çıktı Filtresi​

Araç Çıktı Filtresi bölümü de salt okunurdur: bir rozet filtrenin Etkin mi yoksa Devre dışı mı olduğunu gösterir, ikinci bir rozet PII maskelemenin durumunu bildirir ve engelleme desenleri altta listelenir. Tire işareti tanımlı desen olmadığı anlamına gelir.

Ayarları değiştirmek için Yapılandır düğmesini seçin. Açılan çekmecede filtreyi açıp kapatın, PII Maskele anahtarını açıp kapatın ve engelleme desenlerini ekleyin veya silin. Kaydet düğmesi bu ayarların tümünü tek adımda yazar, İptal düğmesi değişikliği atar. Bir desen eşleşmesi yanıtın tamamını engeller; fazla geniş bir desen meşru yanıtları da engeller. Mümkün olduğunca özgül desen kullanın.

Keşif — server.json​

server.json belgesi varsayılan olarak proxy'nin ayarlarından otomatik üretilir ve güncel tutulur — bir önceki bölümdeki örnek de budur. MCP Routing sekmesindeki Keşif — server.json bölümünden bu davranış değiştirilebilir:

  • Otomatik üret (varsayılan) — gateway belgeyi routing modu, protokol sürümü ve kimlik doğrulama politikalarından üretmeye devam eder; bu ayarlardan biri değiştiğinde belge kendiliğinden güncellenir.
  • Özel — belgenin tamamı sizin olur. Bölüm belgeyi salt okunur gösterir. Düzenlemek için Yapılandır düğmesini seçin: düğme sağdan bir çekmece açar ve belgeyi bu çekmecedeki editörde düzenlersiniz. Kaydet düğmesi belgeyi sunucuya yazar, İptal düğmesi değişikliği atar. Metin geçerli JSON değilken Kaydet düğmesi kapalı kalır. Çekmece, moda geçtiğiniz andaki üretilmiş belgeyle dolar; o andan itibaren gördüğünüz her satır — alan adları, remotes[], _meta dahil — gateway tarafından bir daha güncellenmez, tamamen sizin sorumluluğunuzdadır.

Çekmecedeki Kaydet düğmesi belgeyi doğrudan sunucuya yazar. Çekmece yalnız kayıt başarılı olursa kapanır. Belge reddedilirse çekmece açık kalır ve metniniz korunur. Sekmenin altında ikinci bir Kaydet düğmesi yoktur.

Kaydetme sırasında kontrol edilen tek kural, metnin geçerli bir JSON olmasıdır; bu koşulu sağlamayan bir belge kaydedilmez. MCP Registry şemasının beklediği name, description, version veya remotes gibi bir alanın eksik olması kaydı engellemez — yalnızca proxy'nin Overview sekmesinde ("Bu server.json belgesinde ... alanı yok. MCP kayıt defterleri bu belgeyi reddeder." gibi) bir uyarı olarak gösterilir; belge eksik alanla birlikte yayınlanmaya devam eder.

Belgeye yazdığınız ${DEGISKEN_ADI} biçimindeki ortam değişkenleri, belge istemciye sunulurken çözülür; kaydedilen metnin kendisi değişmez, yalnızca yayınlanan kopya çalıştığınız ortamın değerini taşır — remotes[].url gibi ortama göre değişen bir alanı tek bir belgeyle her ortamda doğru adres için kullanmanızı sağlar.

Özel belgeden vazgeçmek için aynı seçim düğmesinden Otomatik üret seçeneğine dönün. Apinizer özel belgeyi siler ve bu değişikliği hemen kaydeder. Gateway belgeyi sonraki deploy'dan itibaren yeniden kendisi üretir. Ayrı bir "otomatiğe dön" düğmesi yoktur.

uyarı

"Özel" modda, geçersiz JSON dışındaki her hata — yanlış adres, eksik alan, gerçekte uygulanmayan bir kimlik doğrulama açıklaması — olduğu gibi kaydedilir ve yayınlanır; gateway içeriği ayrıca doğrulamaz ya da düzeltmez. Belgeyi doğru ve bu proxy'nin gerçek yapılandırmasıyla güncel tutmak tamamen size aittir.

İstemci Uç Noktaları (Overview)​

Overview sekmesindeki İstemci Uç Noktaları bölümü, bir istemcinin ihtiyaç duyduğu tam adresleri ve kopyalamaya hazır istekleri, bölümün üstündeki bir seçiciden seçtiğiniz ortama göre gösterir:

  1. MCP Uç Noktası — her MCP istemcisinin initialize, tools/list ve tools/call için çağırdığı tek POST JSON-RPC adresi; kopyalama düğmesiyle birlikte gösterilir.
  2. server.json — Güvenlik ve Governance bölümünde anlatılan, kimlik doğrulaması gerekmeyen GET adresi (MCP Registry server.json şeması); kopyalama düğmesinin yanında, belgeyi doğrudan yeni bir sekmede açan bir Aç bağlantısı ve belgenin Otomatik mi üretildiğini yoksa elle Özelleştirilip düzenlendiğini gösteren bir rozet bulunur — bkz. Keşif — server.json. Belge elle düzenlenmişse ve MCP Registry şemasının beklediği bir alan (name, description, version, remotes) eksikse, rozetin altında bunu bildiren bir uyarı gösterilir; bu uyarı belgenin yayınlanmasını engellemez.
  3. Eski SSE Akışı — yalnızca proxy'nin üzerinde anlaşılan protokol sürümü 2024-11-05 olduğunda görünür; bu taşımanın push kanalına ait GET adresidir, kendi kopyalama düğmesiyle birlikte.
  4. Kopyalamaya hazır komutlar — tools/list, tools/call (bir araç için adını veya argümanlarını elle yazmadan çağrı üretmenizi sağlayan bir araç seçiciyle birlikte), initialize, server.json ve .mcp.json ile Claude Desktop için hazır yapılandırma bloklarını içeren bir İstemci yapılandırması sekmesinden oluşan sekmeli bir alan. Proxy'ye herhangi bir kimlik doğrulama politikası eklendiğinde, ihtiyaç duyan her komuta o politikanın gerçekte gerektirdiği kimlik bilgisi otomatik olarak eklenir — bkz. aşağıdaki Kimlik Doğrulama.

Örneğin MCP Uç Noktası https://api.apinizer.com/apigateway/aigw/petstore-mcp/ olan bir proxy'de server.json https://api.apinizer.com/apigateway/aigw/petstore-mcp/.well-known/mcp/server.json adresinde bulunur ve tools/list komutu şöyle görünür:

curl -X POST https://api.apinizer.com/apigateway/aigw/petstore-mcp/ \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Komutların altında, proxy'nin o an yayınladığı her aracı adı, açıklaması, kaynak API proxy'si ve girdi şemasının dolu olup olmadığıyla listeleyen açılır bir Açık araçlar tablosu bulunur; bir komutu kopyalamadan önce hızlı bir kontrol imkânı verir.

uyarı

Açık bir aracın arkasındaki kaynak API proxy'si seçtiğiniz ortama deploy edilmemişse, o aracın girdi şeması boş görünür ve ona karşı yapılan bir tools/call çağrısı Tool backend proxy unavailable yanıtı döner. Sorunu çözmek için kaynak proxy'yi seçili ortama deploy edin.

Kimlik Doğrulama​

Yukarıdaki komutlardaki kimlik bilgisi hiçbir zaman sabit bir varsayım değildir — proxy'nin istek politikası zincirindeki her aktif kimlik doğrulama politikasından türetilir. Birden fazla politika varsa (örn. mTLS + Basic), çağıranın ikisini birden karşılaması gerekir; proxy'de hiç politika yoksa örnekler kimliksiz (anonim) kalır.

Politikaİstemcinin göndermesi gerekenNotlar
Basic (şifre kontrolü açık)-u "<kullanıcı>:<şifre>" ya da Authorization: Basic <base64(kullanıcı:şifre)>—
API Anahtarı (Bearer olarak)Authorization: Bearer <api-anahtarı>Şifre kontrolü kapalı, anahtarın Bearer olarak taşındığı "yalnızca anahtar" bir politikadır.
API Anahtarı (başlıkta)Politikanın tanımladığı başlık adıyla anahtar (örn. X-Api-Key: <api-anahtarı>)—
API Anahtarı (query parametresinde)Adresin sonuna eklenen ?<parametre-adı>=<api-anahtarı>.mcp.json / Claude Desktop yapılandırmasına yazılamaz — anahtar her zaman adrese eklenir.
JWT / OAuth2 (bu gateway tarafından yönetilir)Önce bir token isteği (/auth/jwt veya /auth/token — kimlik bilgisi bu politika üzerinden yönetiliyorsa; kimlik bilgisi consumer/ACL katmanından geliyorsa /credential/jwt veya /credential/token), ardından Authorization: Bearer <access_token>Token uç noktası aşağıdaki Token Uç Noktası satırında ayrıca gösterilir.
OIDCDış kimlik sağlayıcıdan (IdP) alınan Authorization: Bearer <access_token>Token dış IdP'den alınır, gateway yalnızca doğrular (JWKS / introspection). Claude.ai / Claude Desktop "Custom connectors", IdP OAuth 2.0 Dinamik İstemci Kaydını destekliyorsa bu akışı doğrudan yürütebilir.
Harici JWT (üçüncü taraf issuer)Dış issuer'dan alınan Authorization: Bearer <jwt>Gateway token üretmez, yalnızca doğrular.
Digest--digest -u "<kullanıcı>:<şifre>"Claude Desktop ve Cursor gibi MCP istemcileri challenge/response akışını yürütemez — MCP için Basic veya bir token politikası tercih edin.
mTLS--cert client.crt --key client.keymcp-remote ve Claude Desktop bir istemci sertifikası sunamaz — mTLS'i sonlandıran yerel bir köprü/proxy kullanın ya da mTLS'i bir token politikasıyla birlikte tanımlayın.

Proxy'de bir JWT, OAuth2 ya da (token uç noktası tanımlıysa) bir OIDC politikası varsa, yukarıdaki listede MCP Uç Noktası ve server.json'ın altında ayrıca bir Token Uç Noktası satırı görünür: MCP çağrısından önce token almak için POST edilecek adres, kopyalama düğmesi ve kısa bir özet (yönetim biçimi, grant type) ile birlikte.

Kimlik doğrulama gerektiren her komutun üstünde, o proxy için türetilen sayısal adımlar (örn. "1) Get a token: POST .../auth/token ile ...", "2) Call the MCP endpoint with Authorization: Bearer ...") listelenir; bu adımlar, örnek komutla birlikte olduğu gibi kopyalanabilmesi için kasıtlı olarak İngilizce gösterilir. Digest, mTLS ya da query parametresinde taşınan bir API anahtarı gibi statik istemci yapılandırmasına (.mcp.json / claude_desktop_config.json) tam olarak yazılamayan bir şema kullanıldığında, adımların altında bunu belirten ayrı bir uyarı notu da gösterilir.

not

Bir politika proxy'yi korusa da kimlik bilgisi bir MCP istemcisi tarafından hiç üretilemiyorsa (örn. mesaj gövdesi imzası/şifrelemesi bekleyen bir JOSE politikası ya da bir SAML politikası), o giriş "MCP istemcileri kullanamaz" olarak işaretlenir ve altına ne yapmanız gerektiğini açıklayan bir uyarı eklenir — proxy sessizce "kimlik doğrulama yok" göstermez.

Giden Araç Çağrısı​

Bir AI Gateway'in LLM'i bir araç çağırmak istediğinde (tool_use / function calling), bu isteği fiilen dış bir MCP sunucusuna ileten bileşen MCP Çağrısı (LLM) / MCP Çağrısı (Sabit) politikasıdır (proxy'nin araç çağırma adımına eklenir). Hedef sunucu, Passthrough modundaki gibi politikanın kendi ekranında satır içi tanımlanır:

Politikayı ekleyin

Bir AI Gateway'in araç çağırma adımına MCP Çağrısı (LLM) politikasını ekleyin.

Sunucuyu tanımlayın

MCP Sunucusu (Satır İçi) bölümünde adresi, protokol sürümünü, kimlik doğrulama şemasını (Bearer / OAuth2 Client Credentials / mTLS / Yok) ve capability cache ayarlarını girin. Tek bir endpoint taşır — failover/çoklu-sunucu listesi yoktur; birden çok dış sunucuya araç çağrısı için ayrı politika örnekleri eklenir.

Araçları keşfedin

Araçları Keşfet butonu sunucuya bağlanır, bağlantının çalıştığını doğrular ve araç kataloğunu getirir — kaydetmeden önce çalışır, ayrı bir "bağlantıyı test et" adımı yoktur.

İzinli araçları daraltın (opsiyonel)

Boş bırakılırsa keşfedilen tüm araçlara izin verilir; araçlar henüz hiç keşfedilmemişse çağrı fail-closed reddedilir. Kısıtlamak için İzin Verilen Araçlar listesinden seçim yapın.

Bu sunucu tanımı da Passthrough modundakiyle aynı SSRF korumasına tabidir (bkz. Güvenlik ve Governance). Politika ekranındaki MCP Bağlantısı alanı geriye dönük uyumluluk için korunur: satır içi sunucu tanımlıyken devre dışı kalır, çalışma zamanında ikisinden yalnızca biri kullanılır.

Bu politika da APIops REST API ile eklenip güncellenebilir; bkz. API Referansı: Policies.

Protokol Sürümleri​

Her MCP Gateway'inin istemcilere bildirdiği protokol sürümü ayrı ayrı yapılandırılabilir (MCP Routing sekmesi → Routing Modu bölümü → Yapılandır → MCP Protokol Sürümü → Kaydet):

SürümDavranış
2024-11-05Eski (legacy) taşıma — HTTP + Sunucu Tarafından Gönderilen Olaylar (SSE), GET .../sse push kanalı
2025-06-18Streamable HTTP, yanıtlarda MCP-Protocol-Version başlığı — varsayılan
2026-07-28Stateless taşıma — initialize el sıkışması gerekmez

Sürüm değişikliği proxy'yi yeniden deploy etmenizi gerektirir. Alan boş bırakılırsa gateway varsayılanı (2025-06-18) kullanılır; tanınmayan/hatalı yazılmış bir sürüm değeri, en yakın alt sürüme düşürülür ve bu durum bir uyarı olarak loglanır — istek reddedilmez.

Deployment Bilgileri​

MCP Gateway'in Deployment Bilgileri tablosu (bkz. Yükleme ve Tanım Dosyası Bilgileri), tüm proxy tiplerinde bulunan alanların yanında iki MCP'ye özgü kolon daha taşır:

KolonAçıklama
server.jsonO ortam için yayınlanan keşif belgesinin (server.json) adresine giden bağlantı.
ProtokolO ortamdaki deploy için üzerinde anlaşılan MCP protokol sürümü.

Tanım Dosyaları (Specs) kolonundaki Göster (Show) bağlantısı da MCP proxy'lerinde artık farklı bir belge açar: bir OpenAPI belgesi yerine, dört sekmeli bir diyalog gösterir — tools/list, initialize, server.json ve İstemci yapılandırması. Bir MCP Gateway'in gösterilecek bir REST/SOAP sözleşmesi olmadığından, bu diyalog bağlanan bir istemcinin göreceği kataloğu, el sıkışma yanıtını ve keşif belgesini aynen sunar.

Çoklu Hedef (Aggregation)​

Passthrough modunda, MCP Routing sekmesindeki satır içi sunucu listesine en fazla 10 arka uç MCP sunucusu eklenebilir. Apinizer bu sunucuların tamamının araç kataloglarını tek bir tools/list yanıtında birleştirir:

  • Farklı sunucularda aynı isme sahip araçlar, deterministik biçimde sunucuAdı__araçAdı şeklinde isimlendirilerek çakışma önlenir.
  • Fail-soft: hedeflerden biri yavaş veya erişilemez durumdaysa, diğer hedeflerin araçları etkilenmeden sunulmaya devam eder.
  • Tek bir sunucu yeterliyse listeye tek satır eklemek yeterlidir; sıralama, satırları yukarı/aşağı taşıyarak değiştirilebilir.

Güvenlik ve Governance​

Kimlik doğrulama artık proxy'nin normal politika zincirinden gelir — JWT, OIDC, API Anahtarı, Basic gibi mevcut tüm auth politikaları MCP Gateway'lerinde de kullanılabilir; ayrı bir "MCP kimlik doğrulama modu" yoktur. Zincirdeki her aktif politikanın istemciden ne beklediği tek bir yerden türetilir ve iki yüzeyde aynı şekilde kullanılır: Overview sekmesindeki Kimlik Doğrulama bölümü ve server.json belgesi — biri değişince diğeri asla farklı bir şey söylemez. Discovery belgesi (.well-known/mcp/server.json, MCP Registry server.json biçiminde) bu zincirden muaftır ve her zaman açık erişimlidir; yalnızca başlıkta taşınabilen şemaların (Basic, Bearer API anahtarı, başlıkta taşınan API anahtarı, JWT/OAuth2/OIDC token'ı) beklediği başlığı remotes[].headers altında bildirir ve genel durumu _meta["com.apinizer"].authRequired ile işaretler — query parametresinde taşınan bir anahtar, Digest ya da mTLS gibi başlıkta taşınmayan şemalar için hiçbir başlık ilan edilmez. Bu belge her zaman en iyi çaba (best-effort) bir keşif ipucudur; gerçek erişim kontrolü daima istek asıl politika zincirinden geçerken uygulanır. Overview sekmesindeki İstemci Uç Noktaları bölümü bu adresi bir kopyalama düğmesi ve bir Aç bağlantısıyla gösterir — proxy 2024-11-05 sürümündeyse eski SSE adresini de aynı şekilde sunar; böylece bu adresleri elle oluşturmanız gerekmez.

Aşağıdaki governance özellikleri şu an bir yönetim ekranı üzerinden değil, API proxy yapılandırmasının bir parçası olarak (APIops) ayarlanır:

  • Kimlik bazlı erişim listesi (identity-ACL) — yalnızca Passthrough modunda uygulanır; Araçları Aç modunda bu liste hiç değerlendirilmez, o moddaki erişim tamamen yukarıda anlatılan zorunlu scope alanına dayanır. Opsiyonel: boş bırakılırsa mevcut araç izin listesi/keşif davranışı aynen sürer. Doldurulursa default-deny olur: kimlik bilgisi (credential), rol veya organizasyon bazında tanımlanan kurallarla eşleşmeyen bir çağıran hiçbir aracı ne tools/list yanıtında görebilir ne de çağırabilir; bir kuralın engelleme listesi, aynı veya başka bir kuralın izin listesine her zaman önceliklidir.
  • Araç argüman kısıtları (yalnızca MCP — A2A'da karşılığı yoktur, çünkü A2A skill çağrılarının MCP'deki gibi bir giriş şeması yoktur) — bir aracın argümanlarına nokta-gösterimli bir yol üzerinden (örn. user.email) REGEX, MAX_LENGTH, ENUM veya REQUIRED tipinde doğrulama kuralı tanımlanabilir. Regex kuralları ReDoS'a karşı sınırlıdır (4096 karakter üst sınırı + 200ms zaman aşımı). Hatalı yazılmış bir kural (boş yol, geçersiz regex vb.) sessizce atlanır ve trafiği asla durdurmaz.
  • Çağrı kotası (call-quota) — dakika/saat/gün periyodunda, araç bazlı / kimlik bilgisi bazlı / ikisinin birleşimi bazlı bir çağrı limiti tanımlanabilir. Varsayılan kapalıdır (hiç yapılandırılmamışsa kota kontrolü hiç çalışmaz). Yapılandırıldığında kontrol, tüm yetkilendirme ve argüman doğrulama adımlarından sonra, çağrı gerçek hedefe gitmeden hemen önce yapılır — yetkisiz veya hatalı bir çağrı kota hakkı tüketmez.
  • Katalog sapması (catalog drift) koruması — bir MCP sunucusunun aracı ilk keşfedildiğinde (veya elle yeniden keşfedildiğinde) onaylanan katalog bir özet (hash) olarak sabitlenir; periyodik bir sağlık kontrolü canlı kataloğu bu özetle karşılaştırır. Varsayılan davranış (yalnızca uyar) sapmayı loglar ve uyarı üretir ama çağrıları engellemez; kapalı-güvenli davranış seçilirse, katalog yeniden onaylanana kadar sapma tespit edilen sunucu üzerindeki çağrılar reddedilir.
  • Token aktarımı (opt-in) — çağıranın kendi token'ı varsayılan olarak arka uca iletilmez; sunucu satırının gateway kimlik bilgisi kullanılır. Sıfır güven mimarisinde arka uç MCP sunucusu gerçek çağıranı yetkilendirmelidir. Bunun için MCP Routing sekmesinde Backend MCP Server kartındaki İstemci Erişimi ve İletim bölümünde Configure'u seçin ve İstemci token'ını arka uç sunucuya ilet seçeneğini açın. Açıkken çağıranın Authorization: Bearer token'ı her çağrıda arka uca gider: initialize, tools/list ve tools/call. Sunucu satırının gateway kimlik bilgisi gönderilmez. Kabul edilen token audience değerleri isteğe bağlıdır; doluysa yalnız aud claim'i listedeki bir değerle eşleşen JWT iletilir. Bu listeyi doldurmanızı öneririz: bu MCP sunucusu için verilen bir token yalnız bu sunucuya ulaşır (RFC 8707). İletilecek token yoksa (istemci göndermediyse ya da audience eşleşmediyse) sunucu satırının gateway kimlik bilgisi kullanılır; çağrı kimliksiz gönderilmez.
  • İstemci header'larının iletimi — Aynı çekmecedeki İletilecek istemci header'ları tablosundaki header'lar her çağrıda istemci isteğinden arka uç MCP sunucusuna kopyalanır, örneğin app-identifier veya x-tenant-id. Adlar büyük/küçük harfe duyarlı değildir. İstemcinin göndermediği header iletilmez. Header iletimi token aktarımından bağımsız çalışır. Şu header'lar iletilemez: Authorization, Proxy-Authorization, Host, Connection, Keep-Alive, Transfer-Encoding, TE, Trailer, Upgrade, Content-Length, Content-Type, Content-Encoding, Accept, Accept-Encoding, Mcp-Session-Id, MCP-Protocol-Version. Liste en fazla 20 header içerir. Satır sonu içeren ya da 8 KB'tan uzun bir değer iletilmez.
  • Zorunlu header'lar — Header satırında Zorunlu seçeneğini işaretleyin. Gateway Passthrough modunda her JSON-RPC isteğini denetler: initialize, tools/list, tools/call ve diğer metotlar. Keşif belgesi ve SSE uç noktası denetlenmez. Zorunlu header eksikse gateway arka uç MCP sunucusunu çağırmaz. Content-Type: application/json ile HTTP 400 döner. Boş header değeri eksik sayılır. Birden fazla zorunlu header eksikse tablodaki ilk header bildirilir. Trafik kaydında istek Engellenmiş olarak görünür. Denetim token aktarımından bağımsız çalışır. Gönderilen header yine arka uca iletilir.
  • Hata mesajı — Hata mesajı sütunu Varsayılan ya da Özel gösterir. Yanıt gövdesini değiştirmek için düzenle simgesini seçin. Gövde geçerli bir JSON olmalıdır. Varsayılana döndür varsayılan gövdeyi geri yükler. Varsayılan gövde şudur: {"jsonrpc":"2.0","id":{{jsonRpcId}},"error":{"code":-32600,"message":"Missing required header: {{headerName}}"}}. Gövdede iki yer tutucu kullanabilirsiniz. {{headerName}} yapılandırılan header adıyla değiştirilir. {{jsonRpcId}} JSON-RPC isteğinin id değeriyle JSON olarak değiştirilir: sayı sayı kalır, metin tırnak alır, id yoksa null olur. Bu yer tutucuyu tırnak içine yazmayın.
  • Çağırana göre araç listesi önbelleği — token ya da header iletimi açıkken araç listesi önbelleği her çağıran için ayrı tutulur. Bir çağıranın araç listesi başka bir çağırana dönmez.
  • Araçları getir ve iletim — sunucu satırındaki Araçları getir düğmesi satırın gateway kimlik bilgisini kullanır. Token aktarımı açıksa ve satırda kimlik bilgisi yoksa (Kimlik Doğrulama Şeması = None), satır araçları getirmez ve Client token required gösterir: araç listesi, bir istemci gateway'i kendi token'ıyla çağırdığında gelir. Böyle bir sunucuyu gerçek bir istemci çağrısıyla deneyin.

Passthrough çağrıları (araç keşfi, araç çalıştırma, sağlık yoklaması), A2A Gateway ile aynı çıkış (egress) korumasını paylaşır:

tehlike

Hedef adres; bulut metadata uç noktaları, loopback, link-local, multicast ve carrier-grade-NAT (CGNAT) aralıklarına karşı her zaman doğrulanır — bu adreslere yönelik istekler, yapılandırmadan bağımsız olarak her zaman engellenir. Bir sunucu tanımı, opsiyonel olarak diğer özel ağ aralıklarına (RFC1918 / IPv6 ULA — örn. cluster-içi bir MCP sunucusu) erişecek şekilde ayrıca izinlendirilebilir, ancak bu opt-in yukarıdaki adresleri asla açmaz.

Yapılandırmada Ortam Değişkenleri​

MCP Gateway yapılandırmasına yazdığınız metinlerin çoğu ${DEGISKEN_ADI} biçiminde ortam değişkeni referansı kabul eder; değer, proxy'nin çalıştığı ortama göre çözülür. Böylece aynı yapılandırma test ortamından canlıya elle düzenlenmeden taşınabilir — her ortamda farklı adlandırılan bir araç, kabul edilen bir hedef kitle değeri veya ortama özel bir yetki adı tek sefer değişken olarak yazılır.

Değişken kabul eden alanlar:

NeredeAlanlar
Giden araç çağrısıAraç adı, argüman şablonu
Erişim kurallarıİzinli araç listesi, kimlik kuralındaki kullanıcı/rol/organizasyon adı, izin ve ret listeleri
Argüman kısıtlarıArgüman yolu ve kural değeri
Yayınlanan araçlarGerekli yetkiler
Token aktarımıKabul edilen hedef kitle listesi
Keşif belgesi (server.json, Özel mod)Belgenin tamamı — örn. ortama göre değişen bir remotes[].url

Argüman şablonu ayrıca #{...} biçimindeki bağlam değişkenlerini de kabul eder; bunlar ortam değişkenleri yerleştirildikten sonra her istek için ayrıca değerlendirilir.

uyarı

Çözümleme fail-closed çalışır. Değişken, proxy'nin çalıştığı ortamda tanımlı değilse metin yazıldığı gibi kalır — ve gerçekte hiçbir araç, yetki ya da hedef kitle birebir ${DEGISKEN_ADI} adını taşımadığı için çağrı yanlış bir eşleşmeye düşmek yerine reddedilir. Çağıran taraf da araç adı olarak birebir ${DEGISKEN_ADI} metnini gönderip erişim kuralını aşamaz; böyle bir istek doğrudan reddedilir.

not

Araç tespit desenleri ve çıktı engelleme desenleri değişken kabul etmez. Bunlar düzenli ifadedir ve Apinizer her birini kayıt anında, gateway'i kilitleyebilecek desenlere karşı sınar. Ortam değişkeninden gelen bir desen motora bu sınamadan geçmeden ulaşırdı; yani sizi koruyan kontrolün kendisi devre dışı kalırdı. Aynı gerekçe, kaydederken doğrulanan elle girilmiş araç giriş şeması için de geçerlidir.

Loglama ve Analytics​

MCP tipindeki bir proxy'nin detay sayfasında da Trace, Trafik ve Analitik sekmeleri bulunur — REST/SOAP proxy'lerindeki eşdeğer sekmelerle aynı yapıdadır; sekme adı proxy tipini tekrarlamaz, zaten o proxy'nin içindesinizdir. Her MCP çağrısı (gelen araç çağrısı, giden araç çağrısı ve giden sağlık yoklaması), gecikme/boyut/istemci IP'si gibi standart alanların yanında MCP'ye özgü alanlarla birlikte trafik logunda görünür. Analitik sayfasının Trafik tab'ındaki "Flags" rozet kolonu bir isteğin önbellek/koruma/PII/streaming durumunu tek bakışta gösterir; ayrıntılı kullanım, maliyet ve koruma metrikleri aynı Analitik sayfasında izlenebilir — bkz. Raporlar ve Analitik.

MCP tipindeki bir kaydın Detaylı Göster'i seçildiğinde log kaydı ayrı bir pencerede değil, AI Gateway trafiğiyle aynı sağdan açılan detay panelinde (drawer) görüntülenir. Kayıtta AI kullanım verisi yoksa panelin son sekmesi LLM İçgörüleri yerine MCP Detayları (A2A trafiğinde A2A Detayları) başlığıyla açılır ve yalnızca araç adı, JSON-RPC id'si ile giden araç çağrısı bilgilerini gösterir; hiçbir denetim verisi yoksa bu sekme hiç görünmez. REST/SOAP gibi diğer proxy tipleri eski detay penceresini (dialog) kullanmaya devam eder.

MCP proxy'nin döndürdüğü her JSON-RPC reddi (özellik gereği HTTP durumu her zaman 200 kalır, hata JSON-RPC gövdesinde taşınır) trafik logunda ayrıca sınıflandırılır: istemci veya politika kaynaklı redler (hatalı istek, bilinmeyen metot, bilinmeyen araç, politika kapısı, çağrı kotası, argüman kısıtı) ağ geçidinde reddedildi, gateway veya backend kaynaklı hatalar (araç backend proxy'sine ulaşılamaması, araç çalıştırma hatası, oturum limiti) ağ geçidi hatası rozetiyle işaretlenir; bu çağrılar Engellenen/Hata filtrelerinde ve analitikte diğer redler gibi görünür. tools/call isteklerinde Yönlendirme Adresi artık boş değildir — adres, Araçları Aç modunda gateway üzerinden ulaşılan kaynak API proxy yolunu, Passthrough modunda ise MCP sunucusunun host:port'unu gösterir ve araç çağrısı rozetiyle işaretlenir. Başarıyla yanıtlanan ama backend'e hiç gitmeyen istekler (initialize, tools/list, ping gibi protokol çağrıları) ağ geçidinde yanıtlandı rozetini taşır; bu satırlarda Yönlendirme Adresi artık boş kalmaz — istemcinin çağırdığı proxy'nin MCP uç nokta adresi soluk renkte gösterilir. Passthrough modunda tools/list canlı bir keşif için gerçek bir backend çağrısıdır; bu durumda satırda hedef MCP sunucusunun uç nokta adresi görünür (query string ve varsa kullanıcı adı/parola ayıklanmış hâlde loglanır). Rozetlerin tam listesi için API Trafiği sayfasına bakın.

Bir AI Gateway'in birden çok aracı art arda çağırdığı durumlarda (agentic loop), her çağrının süresi ve sonuç durumu ayrı ayrı uçtan uca izleme kaydında (trace) görünür. Uçtan uca bir araç çağrısı zincirini takip etmek için İzleme ve Tekrar Oynatma sayfasına bakın.

Giden Araç Adları: Trace'ten Bağımsız Denetim İzi​

Hangi giden araca (tool) gidildiğinin kaydı trace açık/kapalı olmasından bağımsız olarak ana trafik satırında tutulur — trace kapalıyken (varsayılan kurulum) de kaybolmaz. Bu istek boyunca dispatch edilen tüm giden araç çağrılarının adları iki alanla taşınır:

  • Tekilleştirilmiş isim listesi — aynı istekte tekrar eden araç adları tek kez, ilk görülme sırasıyla, virgülle ayrılmış biçimde tutulur; 256 karakter tavanı vardır ve bir isim asla ortasından kesilmez — sığmayan isim(ler) bütün olarak düşer ve bu durum ,… işaretiyle belli edilir (sessiz kesme yoktur).
  • Ham çağrı sayacı — aynı istekte dispatch edilen tüm giden araç çağrılarının (tekrarlar dahil) toplam sayısı; isim listesi 256 karakter sınırı nedeniyle kırpılsa bile bu sayaç gerçek toplamı taşır.
Reddedilen çağrılar da kaydedilir

Bu denetim izi, bir guard veya kota tarafından reddedilen araç çağrılarını da içerir — amacı yalnızca başarılı çağrıları değil, hangi araca gidilmek istendiğini göstermektir; reddedilen bir çağrı güvenlik açısından başarılı olanı kadar (bazen daha fazla) ilgi çekicidir.

Elasticsearch ve MongoDB trafik-log connector'ları bu alanları otomatik olarak taşır. SQL/JDBC trafik-log connector'ı kullanan mevcut kurulumlar için bkz. 2026.09.0 — Log Tablosu ALTER Scriptleri.

Eski Sürümden Geçiş​

Aşağıdaki ekranlar ve kavramlar kaldırıldı; otomatik bir geçiş yoktur — eşdeğerini MCP tipinde yeni bir API Proxy olarak yeniden oluşturmanız gerekir:

  • Ayrı "MCP Inbound Sunucusu" listeleme/oluşturma/düzenleme ekranı ve bu kayda özgü sunucu bazlı kimlik doğrulama modları (Yok / API Anahtarı / OAuth2) ile bunlara ait issuer/audience/JWKS alanları.
  • Eski istemci uç noktası /aimcp/{id} — yerini proxy'nin kendi relative path'i aldı.
  • MCP sunucusuna özgü ayrı bir deploy tipi — artık standart API Proxy deploy akışının bir parçası.
Eski kavramYeni karşılığı
MCP Inbound Sunucusu kaydıMCP tipinde API Proxy
Sunucu bazlı Yok/API Anahtarı/OAuth2 moduProxy'nin normal auth politika zinciri
/aimcp/{id}Proxy'nin relative path'i

Giden Bağlantı Ekranının Kaldırılması​

Ayrı bir giden MCP bağlantısı listeleme/oluşturma ekranı (ve buna karşılık gelen bağımsız APIops uç noktaları) da kaldırıldı; sunucu tanımı artık yukarıda anlatıldığı gibi Passthrough modunda MCP Routing sekmesinde, araç çağrısında ise MCP Çağrısı (LLM) / MCP Çağrısı (Sabit) politikasının kendisinde satır içi tutulur. Keşif, sağlık yoklaması, katalog kayması (drift) koruması ve token passthrough aynı şekilde çalışmaya devam eder; artık paylaşılan bir kayda değil, sunucunun kendi tanımına bağlıdır.

Bu değişiklik için otomatik bir geçiş vardır: bu eski ekrandan önceden oluşturulmuş bağlantılara sahip mevcut proxy ve politika yapılandırmaları, bir sonraki yükseltmede otomatik olarak satır içi sunucu tanımına taşınır — yeniden oluşturmanız gerekmez. Aynı bağlantı birden fazla proxy/politika tarafından paylaşılıyorsa, yükseltme sonrasında her biri kendi bağımsız (kimlik bilgisi dahil) kopyasını taşır; kimlik bilgisini rotasyona sokarken bunu göz önünde bulundurun.

Dışa/İçe Aktarma​

MCP Gateway, diğer proxy tipleri gibi Dışa/İçe Aktarma Sihirbazı'ndan API Proxy olarak dışa/içe aktarılır. Araçları Aç modunda başka bir API Proxy'nin uç noktalarını araç olarak yayımlıyorsa, o kaynak proxy MCP Kaynak API Proxy'leri adıyla ayrı bir bağımlılık olarak listelenir ve içe aktarımda hedefteki karşılığına eşlenir ya da pakette taşınan kopyasından oluşturulur. Ayrıntı ve hata durumları için bkz. Export Import.

Sonraki Adımlar​