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 — LLM 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:

Alan	Açıklama
Routing Modu	Araç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ü	Bu proxy'nin sunduğu protokol sürümü; bir sonraki deploy'da geçerli olur — bkz. Protokol Sürümleri.
İstemci Kimlik Doğrulaması	Yok ya da Gerekli değerini alır; proxy'de veya bağlı API Proxy Grubunda aktif bir kimlik doğrulama politikası bulunduğunda Gerekli olur. Diğer politika türleri (örn. IP kısıtlama, loglama) istemci kimlik doğrulaması gerektirmez; böyle bir proxy Yok 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 LLM 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 Yönlendirme 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.

Yönlendirme sekmesi değişiklikleri anında kaydeder

Yönlendirme sekmesinin altında Kaydet düğmesi ve "kaydedilmemiş değişiklik" uyarısı 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; Yapılandır düğmesi sağdan bir çekmece açar. Ayarı çekmecede değiştirip Kaydet'i seçin; İptal düzenlemeyi atar.
• Araç Ekle / Düzenle, Sunucu Ekle / Düzenle ve diğer çekmecelerin her birinin kendi Kaydet düğmesi vardır. Düğme değişikliği yazar ve çekmeceyi yalnız sunucu kabul ettikten sonra kapatır. Reddedilen değişiklik çekmeceyi, yazdıklarınızla birlikte açık bırakır.
• Sekmede doğrudan görünen birkaç kontrol değiştiği anda kaydedilir: istemci token'ının iletimi, izin verilen araç adları listesi, Keşif — server.json içindeki Otomatik üret / Özel seçimi ve satır silme.
• Yayınlanan araç ya da arka uç sunucu satırını silmek önce onay ister. Silme anında kaydedilir.
• Kayıt reddedilirse sekme son kaydedilen duruma döner. Gördüğünüz, sunucudaki durumdur.
• Kaydedilen bir değişikliğin gateway'e ulaşması için yine deploy gerekir.

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": "2026-07-28",
      "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.

Yönlendirme sekmesi anında kaydeder

Yönlendirme 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ında sağ üstteki Diğer işlemler (⋯) menüsünden, Dönüştür > MCP Gateway'e Dönüştür öğesinden

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 Yönlendirme 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 Zorunlu Scope'lar tanımlanır.

not

Zorunlu Scope alanına rol adlarını girersiniz. Çağıranın hepsine sahip olması gerekir; proxy'de hangi kimlik doğrulama politikası olursa olsun uygulanır. Denetim kapalı-güvenlidir: gerekli rollerin hepsine sahip olmayan veya hiç rolü olmayan çağıran araca erişemez, katalogun geri kalanı etkilenmez. Alan boşsa kimliği doğrulanmış her istemci aracı çağırabilir. Standart MCP OAuth profilinde istemci her rolün OAuth Scope Adını ister — bkz. Scope'lar ve araç erişimi.

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 Kaydet düğmesi değişikliği sunucuya yazar ve sunucu kabul edince çekmeceyi kapatır. Sıra kısaca şudur: Kaydet → deploy. Deploy'u 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.

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" }
  }
}

Kullanım Dışı Operasyonlar

Kaynak API proxy'nin tanım dosyası bir operasyonu kullanım dışı (deprecated) olarak işaretlediyse araç tools/list yanıtında kalır ve çağrılabilir. Gateway araç açıklamasını [Deprecated] ile başlatır. Böylece model ve kullanıcı durumu görür. Araç listeden çıkarılmaz.

Devre dışı endpoint ayrı bir durumdur. Aracı da listede kalır. Çağrı, "metot bulunamadı veya devre dışı" diyen bir araç hatası döndürür (isError true olur). Bu bir JSON-RPC hatası değildir.

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 Rate Limit, 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 Yönlendirme sekmesinde, ayrı bir bağlantı ekranına gitmeden doğrudan tanımlanır:

Arka uç sunucuyu ekleyin

Yönlendirme 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.

reason	Anlamı	Kontrol edin
CONNECTION_CONFIGURATION_ERROR	Bağlantı tanımı çağrıyı engelliyor.	Giden trafik koruması (private adres), mTLS anahtar deposu, katalog kayması engeli.
BACKEND_UNREACHABLE	Worker sunucuya ulaşamıyor.	Sunucu adresi, DNS, güvenlik duvarı. localhost kullanmayın — bu adres worker pod'unu gösterir.
BACKEND_TIMEOUT	Sunucu zamanında yanıt vermedi.	Sunucu yükü ve ağ gecikmesi.
BACKEND_TLS_ERROR	TLS el sıkışması başarısız oldu.	Sunucu sertifikası ve güven deposu.
BACKEND_AUTH_FAILED	Sunucu 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_ERROR	Sunucu başka bir HTTP hata durumu döndürdü.	httpStatus değeri ve sunucu logları.
BACKEND_TOOL_ERROR	Sunucu bir JSON-RPC hatası döndürdü. Aracın kendisi başarısız oldu.	backendErrorCode değeri ve sunucu logları.
BACKEND_PROTOCOL_ERROR	Yanı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_ERROR	Baş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. API proxy üzerinde yönetme yetkiniz yoksa da düğme pasif kalır, çünkü deneme bu yetkiyi ister. Ç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. Özel ağ (cluster-içi) egress'ine izin ver anahtarı açıksa deneme loopback (127.0.0.1, localhost), RFC1918, link-local ve küme içi adreslere de ulaşabilir; düz http de çalışır. Anahtar kapalıysa yalnız genel https adresleri kabul edilir. Anahtarı açmak bulut metadata adresini de açar; yalnız güvendiğiniz sunucular için açın.
• Sık yapılan bir hata, MCP olmayan bir proxy adresinin (örneğin bir LLM Gateway) 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. Düğme API proxy üzerinde yönetme yetkisi ister; yetkiniz yoksa düğme pasiftir.

• 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ü

Yönlendirme 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. Yönlendirme 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ç aktif kimlik doğrulama politikası yoksa örnekler kimliksiz (anonim) kalır.

Politika	İstemcinin göndermesi gereken	Notlar
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.
OIDC	Dış 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.key	mcp-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 LLM 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) politikasıdır (LLM Gateway'in yanıt akışına — araç çağırma adımına — eklenir). Hedef sunucu, Passthrough modundaki gibi politikanın kendi ekranında satır içi tanımlanır. Modelin kararından bağımsız, yönetici tarafından sabit bir araç çağrısı yapmak — istek akışında veya hata akışında — için MCP Çağrısı (Sabit) bölümüne bakın.

Politikayı ekleyin

Bir LLM Gateway'in yanıt akışına (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ı (Arka Uç Kimlik Doğrulama bölümüne bakın) 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 / Yeniden Tara 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.

MCP Çağrısı (Sabit)

MCP Çağrısı (Sabit) politikası, modelden bağımsız olarak yönetici tarafından önceden seçilmiş tek bir aracı dış bir MCP sunucusunda çalıştırır. MCP Çağrısı (LLM)'den farklı olarak modelin bir araç çağrısı döndürmesini beklemez; herhangi bir proxy tipinin istek akışında veya hata akışında çalışabilir.

Alan	Açıklama
Hedef Araç	Çağrılacak araç; sunucunun keşfedilmiş araç kataloğundan seçilir. Katalogda bulunmayan araç fail-closed reddedilir.
Argüman Şablonu	Araca gönderilen JSON gövde. ${DEGISKEN_ADI} ortam değişkenleri önce çözülür; #{...} bağlam değişkenleri sonra çözülür. Çözümlenen metin geçerli bir JSON olmalıdır; geçersiz şablon, dağıtım başarısızlığı olarak değerlendirilir.
Bekleme Modu	Gönder ve Unut (varsayılan) — çağrıyı asenkron dağıtır, akışı bloklamaz. Değişkene Senkron — sonucu bekler ve belirtilen çıktı değişkenine yazar.
Çıktı Değişken Adı	Yalnızca Bekleme Modu Değişkene Senkron olduğunda zorunludur.
Çağrı Zaman Aşımı (ms)	Çağrı başına HTTP zaman aşımı. Varsayılan: 30 000 ms.

Hata davranışı. İki başarısızlık kategorisi vardır:

• Yapılandırma sorunları — satır içi sunucu ayarlanmamış, hedef araç boş ya da ortam değişkeni çözülememiş, araç katalogda yok veya çağıranın kimliği erişim kurallarınca reddedilmiş — isteği HTTP 500 / ERR-288 ile bloklar.
• Dağıtım başarısızlıkları — zaman aşımı, uzak sunucu hatası, geçersiz argüman JSON'ı veya argüman kısıtlaması ihlali — yalnız loglanır, istek veya hata akışını asla bloklamaz. Değişkene Senkron modunda çıktı değişkeni boş kalır; kullanmadan önce kontrol edin.

Araç sonucu çıktı değişkenine kişisel veri maskeleme uygulanmadan yazılır. Bu politikadaki argüman kısıtlamaları yalnızca Yönetim REST API üzerinden yapılandırılır; politika ekranında düzenlenemez.

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

Yalnız Yanıt Akışı

MCP Çağrısı (LLM) politikası, modelin döndürdüğü araç çağrıları üzerinde çalışır. Bu çağrılar yalnız yanıtta bulunur. Bu yüzden proxy bu politikayı ve A2A Çağrısı (LLM) politikasını yalnız yanıt akışında kabul eder. Platform hatada bunları "MCP Tool Call" ve "A2A Agent Call" adlarıyla anar. Birini istek akışına veya hata akışına koyan kayıt şu mesajla reddedilir: "MCP Tool Call and A2A Agent Call policies can be placed only in the response flow". Denetim proxy düzeyini, metot düzeyini ve politika gruplarını kapsar. Her kayıt yolu için geçerlidir: APIops REST API ve içe aktarma dahil. Platform politikayı sizin yerinize başka bir akışa taşımaz. MCP Çağrısı (Sabit) ve A2A Çağrısı (Sabit) politikaları bu denetimin dışındadır.

Arka Uç Kimlik Doğrulama

Aynı kimlik doğrulama şemaları, Passthrough proxy'nin MCP sunucu satırında ve MCP Çağrısı (LLM) / MCP Çağrısı (Sabit) politikalarının satır içi sunucusunda kullanılabilir. A2A ajanlarında da aynı şemalar vardır (bkz. A2A Gateway).

Şema	Gateway'in gönderdiği
Yok	Kimlik bilgisi göndermez.
Bearer Token	Authorization başlığında sabit bir bearer token.
OAuth2 Client Credentials	Gateway'in client ID ve secret ile token adresinden aldığı token.
mTLS (İstemci Sertifikası)	Seçilen KeyStore'daki istemci sertifikası. Authorization başlığı gönderilmez.
API Anahtarı (Başlık)	API anahtarı, adını verdiğiniz başlıkta (örneğin X-API-Key). Authorization başlığı gönderilmez. Authorization, Proxy-Authorization, Host, Cookie, Accept, Accept-Encoding, içerik ve bağlantı başlıkları, MCP-Protocol-Version ve Mcp-Session-Id başlık adı olarak kullanılamaz.
Basic Kimlik Doğrulama	Authorization başlığında Basic kimlik bilgisi olarak kullanıcı adı ve parola. Kullanıcı adı iki nokta (:) içeremez. https uç noktası kullanın.
OAuth2 Token Exchange (RFC 8693)	Hedef için üretilmiş bir token. Gateway, çağıranın doğrulanmış token'ını dış bir yetkilendirme sunucusunun token adresinde değiştirir. Yalnız yeni token gönderilir.

Bağlantılardaki sırlar. MCP veya A2A bağlantısının API anahtarı, Basic parolası, bearer token'ı ve client secret'ı, bağlantıyı yalnız görüntüleme yetkisi olan kullanıcıdan gizlenir. Ekran değer yerine "ayarlı" ibaresini gösterir. Düzenleme yetkisi olan kullanıcı değeri görür. Kaydederken bir sır alanını boş bırakırsanız kayıtlı değer korunur. Apinizer Credential AS de bu grant'ı kabul eder (bkz. Token Exchange).

• Çağıranın token'ı, proxy'nin bir kimlik doğrulama politikası (JWT, OAuth2 veya OIDC) tarafından aynı istekte doğrulanmış olmalıdır. Basic kimlik bilgisi ya da doğrulanmamış ham başlık kullanılmaz.
• Doğrulanmış çağıran token'ı olmayan istek reddedilir. Gateway kendi kimlik bilgisine geri dönmez.
• Token Exchange Audience isteğe bağlıdır. Boş bırakırsanız yetkilendirme sunucusunun varsayılanı kullanılır. Gateway, client ID ve secret'ı Basic istemci kimlik doğrulamasıyla gönderir.
• Gateway değiştirilmiş token'ı ortak bir önbellekte tutar. Kayıt, token süresi ile çağıran token süresinden erken olanın bitişinden 30 saniye önce sona erer. İki süre de bilinmiyorsa token yalnız o çağrıda kullanılır.
• Önbellek anahtarı çağıran token'ı, token adresini, istemciyi, scope'u ve audience değerini içerir. Bir çağıran başka bir çağıranın token'ını almaz.
• Hedef 401 veya 403 dönerse MCP sunucusu için önbellek kaydı silinir ve çağrı bir kez daha denenir. A2A ajanlarında yeniden deneme yoktur.
• Token iletme (passthrough) bu şemada uygulanmaz.
• Araçları getir, Araçları Keşfet / Yeniden Tara ve bağlantı testi token alamaz, çünkü çağıran token'ı taşımazlar. Bağlantı testi yalnız ayarları denetler. Bu sunucunun sağlık durumu Unknown görünür.

Auth Keşfet

Auth Keşfet düğmesi, sunucu çekmecesinde adresin yanında ve MCP politika ekranlarında bulunur. Düğme hedefe ne gerektiğini sorar ve form değerlerini önerir. Forma uygula öneriyi forma yazar. Hiçbir şey kaydedilmez ve kimlik bilgisi gönderilmez.

1. Gateway, adrese kimliksiz bir istek gönderir. Protokol sürümü sabitlenmemiş sunucuda önce server/discover dener. Olmazsa initialize dener.
2. Hedef, resource_metadata adresiyle 401 dönerse gateway korunan kaynak meta verisini (RFC 9728), sonra yetkilendirme sunucusu meta verisini (RFC 8414, sonra OpenID Connect) okur.
3. Form önerilen şemayı, token adresini, scope'ları, grant türlerini ve istemci kimlik doğrulama yöntemlerini gösterir. Client ID ve secret'ı (veya anahtar ya da parolayı) girin ve kaydedin.

Sonuç hakkında bilmeniz gerekenler:

• Meta verideki issuer, yetkilendirme sunucusu adresinden farklıysa gateway token adresi önermez. Bir not nedenini açıklar.
• Meta veri başka bir kaynağı gösteriyorsa, yetkilendirme sunucusu client credentials grant sunmuyorsa, token exchange destekliyorsa ve hedef istemci sertifikası istiyorsa bir not görünür.
• Değişken olarak okunacak bir değer ve https olmayan bir token adresi forma yazılmaz. Bir not sizi bilgilendirir.
• Hedef kimlik bilgisi olmadan yanıt verirse mevcut şema korunur, çünkü sunucu yalnız araç çağrılarını koruyor olabilir.
• Keşif, gateway worker'ında değil Manager'da çalışır. https adreslerini kabul eder; düz http yalnız Özel ağ (cluster-içi) egress'ine izin ver anahtarı açıkken kabul edilir. Yönlendirmeyi (redirect) izlemez. Tüm çalışma için 30 saniyelik sınır vardır.
• Özel ağ (cluster-içi) egress'ine izin ver anahtarı kapalıyken özel ve ayrılmış adresler (loopback, link-local, bulut metadata, RFC1918) reddedilir. Anahtar açıksa hiçbiri engellenmez ve düz http kabul edilir. Anahtarı yalnız sistem yöneticisi açabilir.
• Auth Keşfet için projede AI geliştirme veya API yönetimi MANAGE yetkisi gerekir.

Protokol Sürümleri

Bir MCP Gateway tek bir protokol davranışıyla çalışır. Davranışı proxy başına Yönlendirme sekmesinde seçersiniz (Routing Modu bölümü → Yapılandır → MCP Protokol Sürümü → Kaydet). Seçim bir sonraki redeploy ile uygulanır. Bu sayfada 2025-11-25 ve öncesi sürümlere legacy, 2026-07-28 sürümüne modern denir.

Sürüm	Davranış
2024-11-05	Eski (legacy) taşıma — HTTP + Sunucu Tarafından Gönderilen Olaylar (SSE), GET .../sse push kanalı
2025-03-26, 2025-06-18, 2025-11-25	Streamable HTTP. Gelen istek tarafında üçü aynı davranır. Yanıtlarda MCP-Protocol-Version başlığı bulunur.
2026-07-28	Varsayılandır. Modern protokol. İstemci her istekte protokol sürümünü gönderir, bu yüzden initialize el sıkışması gerekmez. Bkz. Modern Protokol.

Sürüm değişikliği proxy'yi yeniden deploy etmenizi gerektirir. Alan boş bırakılırsa 2026-07-28 kullanılır. MCP Gateway'e Dönüştür eylemi bu varsayılanla bir proxy oluşturur.

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.

Modern Protokol

İsteğin modern üyelerini yalnız 2026-07-28 sürümündeki proxy okur. Diğer tüm proxy'ler her isteği eskisi gibi işler.

• Her istekte sürüm. Modern istemci protokol sürümünü istek meta verisine (_meta) yazar. Gateway isteği oturum olmadan işler.
• server/discover. Desteklenen sürümleri ve gateway yeteneklerini döndürür. Legacy istek bu metot için olağan "metot bulunamadı" yanıtını alır.
• Desteklenmeyen sürüm. Gateway -32022 JSON-RPC hatasıyla yanıt verir. Hata verisi desteklenen sürümleri ve istemcinin istediği sürümü listeler.
• Desteklenmeyen sürüm: HTTP durumu. -32022 yanıtı HTTP 400 ile gelir.
• Standart başlıklar. Modern istek MCP-Protocol-Version (_meta içindeki sürüme eşit), Mcp-Method (metoda eşit) ve tools/call için Mcp-Name (araç adına eşit) başlıklarını taşımalıdır. Biri eksikse ya da gövdeyle uyuşmuyorsa gateway HTTP 400 ve -32020 JSON-RPC hatasıyla yanıt verir. Yalnız eski (legacy) istek, yani _meta taşımayan istek denetlenmez. Gateway modern arka uç sunucuya Mcp-Method ve Mcp-Name başlıklarını gönderir.
• İstekte _meta yoksa. Gateway isteği legacy istek olarak işler. 2026-07-28 proxy'sindeki initialize isteği, yanıtta legacy bir sürüm alır.

Modern bir tools/call bir girdi isteğiyle ya da bir task ile de bitebilir. İkisi için de ortamda bir JWT imzalama anahtarı olmalıdır, çünkü gateway istemciye verdiği değerleri imzalar. Anahtar yoksa gateway bu çağrıları -32603 JSON-RPC hatasıyla reddeder.

Girdi İstekleri (input_required)

Passthrough modunda modern bir arka uç sunucu, araç çağrısına sonuç yerine input_required ile yanıt verebilir. Yanıt, sunucunun kullanıcıdan ne istediğini listeler. İstemci değerleri toplar ve aynı tools/call isteğini, yanıtlarla ve aldığı requestState değeriyle yeniden gönderir.

• Gateway yanıtı istemciye iletir. requestState değerini çağıran, istemci, proxy, arka uç sunucu, araç adı ve argümanlarla birlikte imzalar. Değer 10 dakika geçerlidir.
• Farklı bir çağıran, araç ya da argüman kümesi değeri kullanırsa gateway çağrıyı -32602 ile reddeder.
• Gateway yanıtları ve arka uç durumunu arka uç sunucuya değiştirmeden iletir.

Task'lar

Task, istemcinin uzun bir araç çağrısını başlatıp sonucu sonra okumasını sağlar. Gateway Tasks uzantısını (io.modelcontextprotocol/tasks) destekler:

• İstemci uzantıyı aynı isteğin meta verisinde bildirmelidir. Uzantıyı bildirmeyen modern istemci tasks/get, tasks/update ve tasks/cancel için -32021 ("Missing required client capability") hatası alır. Legacy istek "metot bulunamadı" yanıtı alır.
• tools/call, resultType: "task" ve bir taskId ile yanıt verebilir. İstemci durumu tasks/get ile okur. Gateway ayrıca arka uç task'ına kullanıcı girdisi iletmek için tasks/update, iptal için tasks/cancel kullanır.
• Var olmayan, süresi dolmuş ya da başka bir çağırana ait task kimliği aynı hatayı alır (-32602, "Task not found").

Üç tür task vardır:

Tür	Ne zaman oluşur	Durum nerede tutulur
Arka uç task'ı (Passthrough)	Arka uç sunucu task ile yanıt verir ve istemci uzantıyı bildirmiştir. Gateway task kimliğini imzalar ve iletir. Uzantıyı bildirmeyen istemci hata alır.	Arka uç sunucu. Gateway durum tutmaz. Biten sonuç proxy'nin çıktı filtresinden geçer.
Gateway task'ı (Araçları Aç)	Uzantıyı bildiren istemci bir aracı çağırır ve çağrı 10 saniyede bitmez. Aynı çağrı arka planda sürer, yeniden başlatılmaz.	Gateway.
Onay task'ı	Çağrı onay bekler. Bkz. Araç Risk Politikası ve Onay.	Gateway.

Gateway task kuralları:

• Uzantıyı bildirmeyen istemci yavaş bir çağrıda her zaman normal eşzamanlı yanıt alır. Gateway o çağrıyı task'a çevirmez.
• Gateway task kaydını yanıt vermeden önce yazar. Kaydı yazamazsa çağrıyı bekler ve eşzamanlı yanıt verir.
• Gateway task'ı en çok 150 saniye sürebilir. Bu süreden sonra hâlâ çalışıyorsa task başarısız olur. Gateway task'ı yeniden çalıştırmaz (örneğin worker yeniden başladıysa). Önerilen yoklama aralığı 2 saniyedir.
• Gateway biten task'ı 7 gün saklar, sonra siler. Task bitince saklanan argümanları siler.
• Arka plan çağrıları diğer çağrılarla aynı eşzamanlı araç çağrısı sınırına sayılır. Sınır doluysa gateway task başlatmaz ve oturum sınırı hatasıyla yanıt verir.
• tasks/cancel task'ı iptal edilmiş olarak işaretler. Çağrının yaptığı işi geri almaz. Çalışmakta olan bir çağrı yan etkilerini tamamlayabilir.

Elicitation

Elicitation, arka uç sunucunun araç çağrısı sırasında kullanıcıdan ek girdi istemesini sağlar. Gateway bunu yalnız aynı dönemdeki iki taraf arasında destekler:

İstemci	Arka uç sunucu	Form modu	URL modu
Modern (2026-07-28)	Modern	Desteklenir. Arka uç input_required ile yanıt verir ve gateway bunu istemciye iletir (Girdi İstekleri).	Aynı yol. Gateway inputRequests içeriğini değiştirmeden iletir.
Legacy (2025-11-25 ve öncesi)	Legacy	Passthrough modunda, o arka uç sunucuda Elicitation isteklerini aktar açıksa desteklenir (varsayılan kapalı).	Bu sürümde desteklenmez.
Modern	Legacy	ERR-310 ile reddedilir.	ERR-310 ile reddedilir.
Legacy	Modern	ERR-310 ile reddedilir.	ERR-310 ile reddedilir.
Herhangi	Araçları Aç modu	Uygulanmaz. Apinizer API proxy araçları girdi istemez.	Uygulanmaz.

Gateway form modunu ve URL modunu farklı işlemez. İsteğin ve yanıtın içeriğini, arka uç ve istemci nasıl gönderdiyse öyle aktarır. Bir istemcinin ya da arka ucun URL modunu desteklemesi, protokol sürümlerine ve istemcinin bildirdiği elicitation yeteneğine bağlıdır. Gateway legacy arka uca yalnız istemcinin elicitation isteklerini yanıtlayabildiğini bildirir (elicitation: {}); bu form modu anlamına gelir. İstemcinin yeteneği arka uca ulaşmadığı için URL modu ilan edilmez. Legacy taraflar arasında URL modu bu sürümde desteklenmez.

Bilinen sınır: gateway, arka uç sunucuların araçlarında x-mcp-header ile tanımladığı Mcp-Param-* başlıklarını üretmez.

Elicitation kullanmayan çağrılar bu sınırlardan etkilenmez.

Elicitation isteklerini aktar, arka uç sunucu çekmecesindeki (Passthrough) bir anahtardır. Açtığınızda:

• Gateway arka uç sunucuya istemcinin soru yanıtlayabildiğini bildirir. Anahtar kapalıyken gateway bu yeteneği göndermez ve sunucu için hiçbir şey değişmez.
• Soru, legacy istemciye bir olay akışıyla gider. İstemci yanıtı ayrı bir istekle gönderir. Bu istek başka bir worker'a gidebilir. Gateway yanıtı arka uç sunucuya iletir.
• Araç çağrısı yanıt için en çok 5 dakika bekleyebilir. Bekleme boyunca istek açık kalır.
• Gateway yalnız elicitation isteğini aktarır. Sunucunun diğer istekleri "metot bulunamadı" yanıtı alır ve çağrı sürer. Ping boş yanıt alır.
• Aktarılan soru, çağırana ve proxy'ye bağlı imzalı bir kimlik taşır. Başka bir çağıranın yanıtı reddedilir.

MCP Çağrıları için Hata Mesajları

Hata kodu	Ne zaman	JSON-RPC hatası
ERR-309	Araç çağrısı onay gerektirir ve istemci Tasks uzantısını bildirmemiştir. Hata verisinde approvalId bulunur.	-32021
ERR-310	Araç kullanıcıdan girdi istedi ve gateway bunu istemci ile sunucunun protokol sürümleri arasında aktaramıyor.	-32603

Gateway bu hataları, diğer MCP reddi yanıtlarında olduğu gibi HTTP 200 yanıtında JSON-RPC hatası olarak döndürür. Varsayılan metni Hata Mesajları ekranından değiştirebilirsiniz. Bkz. Hata Mesajları.

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:

Kolon	Açıklama
server.json	O ortam için yayınlanan keşif belgesinin (server.json) adresine giden bağlantı.
Protokol	O 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, Yönlendirme 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 API proxy yapılandırmasının bir parçasıdır. Kimlik erişim kurallarını, argüman kısıtlarını ve araç risk politikasını Yönlendirme sekmesinden ayarlarsınız. Hepsi APIops ile de ayarlanabilir:

• Kimlik bazlı erişim listesi (identity-ACL) — her iki modda da uygulanır. Araçları Aç modunda çağıran, aracın zorunlu scope denetimini de geçmelidir (yukarıda anlatılmıştır). Opsiyonel: boş bırakılırsa mevcut araç izin listesi/keşif davranışı aynen sürer. Doldurulursa default-deny olur: tüketici / API istemcisi, 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. Kuralları Yönlendirme sekmesindeki Kimlik Erişim Kuralları çekmecesinden ya da APIops ile ayarlarsınız.

• 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 kural tanımlarsınız. Gateway kuralları çağrıyı göndermeden önce denetler ve bir kural sağlanmazsa çağrıyı reddeder. Kuralları Yönlendirme sekmesinde ayarlarsınız:

  • Araçları Aç: araç çekmecesini açın ve aracın Argüman kısıtları düzenleyicisini kullanın.
  • Passthrough: Argüman kısıtları bölümünü kullanın. Araç ekle ile aracı ekleyin ve adını tools/list yanıtındaki gibi tam olarak yazın. Eşleşme büyük-küçük harf duyarlıdır. İki sunucunun kullandığı araç adı sunucu__araç biçiminde görünür.

  Her kuralın bir Argüman yolu, bir Kural türü ve bir Değer alanı vardır:

  Kural	Değer	Çağrı şu durumda reddedilir
  Düzenli ifade (tam eşleşme)	Düzenli ifade	Argüman ifadenin tamamıyla eşleşmezse.
  En fazla uzunluk	0 veya daha büyük bir tam sayı	Argüman metni daha uzunsa.
  İzin verilen değerler	Virgülle ayrılmış değerler	Argüman değerlerden biri değilse.
  Zorunlu	Yok	Argüman yoksa.

  Argüman yolu, noktayla ayrılmış özellik adlarıdır (örneğin user.email). Dizi indeksi (items.0.name) ve joker karakter (*) desteklenmez. Düzenli ifade, en fazla uzunluk ve izin verilen değerler kuralları bir argümanı yalnız argüman varsa denetler. Argümanı zorunlu yapmak için Zorunlu kuralı ekleyin. Kayıtlı geçersiz bir kuralı (boş yol, derlenmeyen düzenli ifade) gateway sessizce atlar ve trafiği durdurmaz. Ekran böyle bir kuralı kaydetmez; sorunu kayıttan önce görürsünüz. Ortam değişkenleri (${var}) çalışma zamanında çözülür ve ekranda denetlenmez. Regex kuralları ReDoS'a karşı sınırlıdır (4096 karakter üst sınırı + 200ms zaman aşımı).

• Çağrı hacmini sınırlama — MCP routing'in kendine ait bir çağrı kotası yoktur. Çağrı hacmini iki yerde sınırlarsınız ve her yerin tek bir işi vardır:

  • Kimlik bazlı limitler (tüketici, API istemcisi, uygulama veya organizasyon başına) yalnız Limit Planı ile ayarlanır.
  • Proxy'nin korunması (tüm çağıranların toplamı) için proxy'ye Kota veya Throttling politikasını ekleyin.

  İkisi de MCP araç çağrılarını araç bazında ayrı sayabilir. Sayım değişkeni olarak MCP Araç Adı (tools/call) bağlam değerini seçin. Bu değer kanonik araç adıdır; gateway çağrıyı bu adla çalıştırır. Bu yüzden my_tool, MY_TOOL ve my-tool tek sayaç kullanır. Bunun için istek gövdesinden $.params.name okumayın. Gövde adı istemcinin yazdığı gibi taşır ve her yazım ayrı sayaç açar. Önceki sürümde kaydedilmiş bir callQuota değeri yok sayılır ve routing'in bir sonraki kaydında silinir.

• 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.

• Dağıtımda katalog keşfi — MCP Çağrısı (LLM) veya MCP Çağrısı (Sabit) politikasının satır içi sunucusunda araç kataloğu ve onaylı özet (hash) yoksa, ilk katalog proxy'yi dağıttığınızda alınır. Dağıtımda Manager, worker proxy'yi almadan önce sunucudan araç listesini bir kez ister. Bir dağıtımın tüm sorguları paralel çalışır; tüm dağıtım için toplam 30 saniyelik tek bir süre sınırı vardır. Başarılı ilk sonuç araç kataloğu olarak kaydedilir ve onaylı başlangıç noktası olur; sonraki değişiklikler buna karşı denetlenir. Kataloğu ya da onaylı özeti olan sunucu yeniden sorgulanmaz. Tespit edilmiş bir sapmayı dağıtım onaylamaz. Araç döndürmeyen, erişilemeyen veya 30 saniye içinde yanıt vermeyen sunucu dağıtımı durdurmaz. Dağıtım sonucunda o sunucu için bir WARNING satırı görünür ve katalog keşfedilene kadar araç çağrıları reddedilmeye devam eder. Araçları Keşfet / Yeniden Tara'yı kullanın ve yeniden dağıtın. Kimlik doğrulama şeması OAuth2 token exchange olan sunucu dağıtımda sorgulanmaz; dağıtım anında istemci token'ı yoktur ve zamanlanmış sağlık denetimi de aynı nedenle onu atlar. Bu kimlik doğrulama şemasına sahip satır içi A2A ajanı için de aynısı geçerlidir. Bu sunucu için WARNING satırı yazılmaz. Araç kataloğunu Araçları Keşfet / Yeniden Tara ile alın. Passthrough proxy'nin Yönlendirme sekmesindeki sunucular dağıtımda sorgulanmaz.

• 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 Yönlendirme sekmesinde Arka Uç MCP Sunucusu kartındaki İstemci Erişimi ve İletim bölümünde Yapılandır'ı 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 İstemci token'ı gerekli 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

Giden MCP çağrıları (araç keşfi, araç çalıştırma, OAuth2 token uç noktası, sağlık yoklaması) varsayılan olarak yalnız https kabul eder. Tüm özel ve ayrılmış adresleri (loopback, link-local, bulut metadata, CGNAT, multicast, RFC1918, IPv6 ULA) reddeder.

Sunucu başına Özel ağ (cluster-içi) egress'ine izin ver ayarı bu korumayı kaldırır. Ayar açıkken hiçbir adres sınıfı engellenmez: loopback, link-local, bulut metadata adresi 169.254.169.254, 100.64.0.0/10, 0.0.0.0/8, multicast, RFC1918 ve IPv6 ULA'ya erişilir; düz http de kabul edilir. Ayarı açmak bulut metadata adresini de açar. Yalnız güvendiğiniz sunucular için açın.

Ayar açıkken de yalnız http ve https URL'leri kabul edilir, URL geçerli olmalıdır, ana makine adı çözülmelidir ve bağlantı çözülen adreslere sabitlenir (DNS rebinding savunması).

Standart MCP İstemci Profili

Standart MCP istemcileri (örneğin MCP Inspector veya Claude Code) yetkilendirme sunucusunu kendileri bulur. MCP sunucusunun korunan kaynak meta verisini okurlar, yetkilendirme sunucusunun meta verisini okurlar, bu MCP kaynağı için token alırlar ve sonra araçları çağırırlar. Standard MCP OAuth profili gateway'i bu şekilde çalıştırır. Varsayılan profil Legacy'dir. Önceki sürümlerin davranışını korur.

Profili Yönlendirme sekmesindeki Routing Modu bölümünden seçersiniz (Yapılandır → İstemci Kimlik Doğrulama Profili). Ekran ön koşulları ve her sorunun nedenini gösterir. Kimlik doğrulama zinciri henüz hazır değilse kaydı ya da deploy'u reddetmez. Önce profili seçip politikayı sonra ekleyebilir ya da tamamlayabilirsiniz. Zincirde bir sorun olduğu sürece gateway korunan kaynak meta verisini yayınlamaz ve MCP istemcileri oturum açamaz. Deploy için ortamın erişim URL'si yine gereklidir.

Önce tüm worker'ları yükseltin

Standard profilini seçmeden önce ortamdaki tüm worker'ları yükseltin. Eski bir worker korunan kaynak meta verisini yayınlamaz ve Legacy proxy'de standart token kabul eder.

Ön koşullar

• Proxy'nin kimlik doğrulama zinciri tek bir yetkilendirme sunucusunun token'larını kullanır: ACL'den Yönet seçili bir OAuth2 veya JWT politikası (Apinizer Credential AS), Bu Politikadan Yönet seçili ve Tarayıcı ile giriş (authorization_code) anahtarı açık bir OAuth2 veya JWT politikası (Apinizer /auth yetkilendirme sunucusu) ya da bir OIDC politikası (tek kimlik sağlayıcı).
• Ortamda erişim adresi tanımlıdır. Erişim adresi kanonik kaynağı belirler.
• Araçları Aç modunda proxy'nin bir servis istemcisi vardır ve her aracın bir Hedef kimliği vardır (aşağıya bakın).

Ekran şu sorunları bildirir:

Sorun	Anlamı
Etkin kimlik doğrulama politikası yok	ACL'den Yönet seçili bir OAuth2 veya JWT politikası ya da bir OIDC politikası ekleyin.
Politika tarayıcı girişi olmadan proxy anahtarı token'ı veriyor	Politikada Tarayıcı ile giriş (authorization_code) anahtarını açın ya da ACL'den Yönet seçin.
Issuer'ı olmayan OIDC politikası	Kimlik sağlayıcının issuer'ını girin.
OIDC politikası Bearer token kabul etmiyor	Politikada Bearer JWT kimlik doğrulamasını açın.
OIDC politikası JWT imzasını doğrulamıyor	Yerel JWT doğrulamasını ve imza doğrulamasını (JWKS) açın.
Politika token olmayan bir kimlik bilgisi istiyor	Politikayı kaldırın (örneğin Basic, API anahtarı, Digest, mTLS, SAML veya JOSE politikaları).
Birden fazla yetkilendirme sunucusunun token'ı	Yalnız birini bırakın.
Aynı zincirde JWT ve OAuth2 politikası	Yalnız birini bırakın.

Zincir proxy'nin kendi politikalarından okunur. Proxy grubu politikası yalnız grup yolundan gelen istekte çalışır.

Kanonik kaynak

Kanonik kaynak; ortam erişim adresi, Apinizer kök bağlamı ve proxy yoludur (sonda / yok). Gateway bunu yapılandırmadan üretir. İsteğin Host veya X-Forwarded-* başlıklarını hiç kullanmaz. Token'lar bu değer için verilir ve yalnız aud içinde bu değer varsa kabul edilir.

Korunan kaynak meta verisi

Gateway belgeyi (RFC 9728) kimlik doğrulamasız olarak proxy yolu artı /.well-known/oauth-protected-resource adresinde yayınlar. Belge kaynağı, tek yetkilendirme sunucusunu (authorization_servers), istemcilerin isteyebileceği scope'ları (scopes_supported) ve bearer_methods_supported (header) değerini içerir. Gateway belgeyi yalnız kimlik doğrulama zinciri tek bir yetkilendirme sunucusunun Bearer token'ını kabul ettiğinde ve Standard profil zincire uyduğunda yayınlar. Gateway'in yayınlayacak doğru bilgisi yoksa adres 404 döndürür. Tablodaki sorunlardan biri zincirde sürüyorsa da durum aynıdır. Yönlendirme sekmesindeki ön koşullar panelini kontrol edin. Legacy proxy belgeyi yayınlamaz; istek normal kimlik doğrulama zincirinden geçer.

Belge yalnız proxy yolunun altındadır. RFC 9728 "yol ekleme" biçimindeki adrese ihtiyacınız varsa bunu ingress sağlamalıdır. MCP Inspector gibi tarayıcı tabanlı istemci için proxy'nin CORS ayarları açık olmalıdır.

Gateway yetkisiz isteğe, bu belgeyi adlandıran standart bir WWW-Authenticate başlığıyla yanıt verir:

Durum	Yanıt
Token yok	Bearer resource_metadata="…" ile 401.
Geçersiz token	error="invalid_token" ve resource_metadata ile 401.
Bir araç, token'ın sahip olmadığı scope'u ister (Araçları Aç)	error="insufficient_scope", istemcinin isteyebileceği scope ve resource_metadata ile 403.

Yetkilendirme sunucusu meta verisi

• Apinizer Credential AS (ACL'den Yönet). Issuer <erişim adresi>/credential olur. Kanonik meta veri (RFC 8414) https://<host>/.well-known/oauth-authorization-server/credential adresindedir. Eski /credential/.well-known/openid-configuration ve /credential/.well-known/oauth-authorization-server adresleri de çalışır. Meta veri token ucunu, anahtarları, introspection ve iptal uçlarını, client_credentials ve token exchange grant'larını ve istemci kimlik doğrulama yöntemlerini listeler. Issuer yapılandırılmış erişim adresinden gelir ve korunan kaynak meta verisindeki authorization_servers değerine eşittir. Ortamın erişim adresi tanımlıysa meta veri ek olarak authorization_endpoint, authorization_code grant'ını, PKCE S256 değerini ve none istemci kimlik doğrulama yöntemini ilan eder.
• Apinizer /auth yetkilendirme sunucusu (Bu Politikadan Yönet). Politikada Tarayıcı ile giriş (authorization_code) anahtarı açıksa issuer <erişim adresi>/auth olur. Kanonik meta veri https://<host>/.well-known/oauth-authorization-server/auth adresindedir. Eski /auth/.well-known/oauth-authorization-server adresi de çalışır. Anahtar kapalıysa proxy Standart profili kullanamaz. Ekran bunu bildirir.
• Kimlik sağlayıcı. Kimlik sağlayıcı kendi meta verisini yayınlar. Korunan kaynak meta verisi politikadaki issuer adresini gösterir.

Token alma

• Makineden makineye (Credential AS). İstemci /credential/token adresine, proxy'nin kanonik kaynağına eşit tek bir resource parametresiyle (RFC 8707) client_credentials isteği gönderir. Token yalnız bu kaynak içindir (aud). Biçimi (JWT veya opaque) proxy'nin politikasına uyar. Bu istekte refresh token yoktur. resource içermeyen, başka grant türü kullanan veya bilinmeyen kaynak içeren istek eskisi gibi çalışır ve legacy token verir. Standard proxy legacy token'ı, Legacy proxy standart token'ı reddeder.
• Tarayıcı ile giriş (Apinizer yetkilendirme sunucusu). İstemci, açık (public) bir API istemcisiyle authorization code + PKCE akışını izler. authorize ve token uçları ACL'den Yönet modunda /credential, Bu Politikadan Yönet modunda /auth altındadır. resource zorunludur ve proxy'nin kanonik kaynağına eşit olmalıdır. Access token'ın aud değeri bu kaynaktır. JWT ise başlığında typ: at+jwt bulunur. Refresh token her kullanımda yenilenir ve kullanılmış bir refresh token'ın tekrarı token ailesini iptal eder. Kullanıcının ve uygulamanın erişimi birlikte aranır: kullanıcının erişimi ∩ uygulamanın erişimi. Kurulum, sınırlar ve curl ile doğrulama için MCP Gateway'e Keycloak Olmadan Tarayıcı ile Giriş senaryosuna bakın.
• Kimlik sağlayıcı. İstemci kimlik sağlayıcıya kayıt olur ve token'ı oradan alır. Token'ın aud claim'i kanonik kaynağı içermelidir. Bazı kimlik sağlayıcılar resource parametresini yok sayar. Örneğin Keycloak'ta kanonik kaynağı aud değerine ekleyen bir Audience mapper gerekir. Gateway JWT'yi sağlayıcının anahtarlarıyla (JWKS) yerelde doğrular. Token'ı yalnız Authorization başlığından okur. Sağlayıcının opaque token'ını kabul etmez. Gateway rolleri scope claim'inden okumaz ve scp içindeki diziyi okumaz.

not

İstemci kimliği meta veri belgeleri (CIMD) ve dinamik istemci kaydı (DCR) bu sürümde yoktur. Meta veri bunları ilan etmez (client_id_metadata_document_supported yoktur) ve https URL biçimindeki client_id kayıtsız istemci olarak reddedilir (invalid_client). Kimlik sağlayıcıda istemciyi sağlayıcı kaydeder. Apinizer yetkilendirme sunucusunda istemci, önceden sizin oluşturduğunuz API istemcisidir: makine istemcisi için gizli (confidential) istemci, tarayıcı girişi için açık (public) istemci.

Scope'lar ve araç erişimi

Standard profilinde token'daki scope bir wire scope'tur. Rol, wire scope'unu OAuth Scope Adı alanında alır. İstemci rol adını değil scope adını ister. Çağıran bir aracı yalnız şu ikisi doğruysa kullanabilir: token aracın istediği rolün wire scope'unu içerir ve kullanıcı o role şu anda sahiptir. OAuth scope adı olmayan rol hiçbir aracı açmaz. Scope adı, projenin bir istemcisinin sahip olabileceği roller arasında benzersiz olmalıdır. Kimlik erişim kuralları (identity-ACL) ek olarak uygulanır.

Araç hedefine yapılan çağrılar

Standard profilinde gateway, çağıranın Authorization başlığını Araçları Aç aracının hedefine iletmez. Hedef için token'ı kendisi üretir. Bunu her araç için Hedef kimliği alanında belirlersiniz:

• Servis. Gateway hedefi proxy'nin servis istemcisi olarak çağırır. Kullanıcı yalnız denetim için kaydedilir.
• Delege kullanıcı. Gateway hedefi oturum açmış kullanıcı olarak, servis istemcisi aracılığıyla çağırır. Çağrı ikisini de taşır. Hedef yetki devri token'larını kabul etmeli ve servis istemcisi onun İzin verilen ajanlar listesinde olmalıdır. Gateway, Credential AS'nin token exchange grant'ını süreç içinde kullanır. Bkz. Token Exchange. Kimlik sağlayıcıdan gelen kullanıcı yalnız sağlayıcı kullanıcıyı mevcut bir API istemcisine eşliyorsa delege edilir. Aksi halde çağrı reddedilir.

Araç argümanı ya da istemci başlığı çağrının kimliğini belirleyemez: gateway çağıranın Authorization değerini ve başlık olarak tanımlı argümanı siler.

Loglarda ve limitlerde kullanıcı bağlamı

Standard profilindeki bir çağrıda trafik logu token'ın kullanıcısını ve istemcisini taşır:

Log alanı	Değer
usub	Kalıcı kullanıcı kimliği: kimlik sağlayıcı token'ında sub. Credential AS client_credentials token'ında istemcinin kendisi. Tarayıcı girişi token'ında oturum açan kullanıcının kullanıcı adı (ACL'den Yönet modunda tüketicinin kullanıcı adı).
uids	Kimlik kaynağı: kimlik sağlayıcı token'ının issuer'ı Credential AS token'ı ve ACL'den Yönet modundaki (/credential) tarayıcı girişi token'ı için apinizer, Bu Politikadan Yönet modundaki (/auth) tarayıcı girişi token'ı için apinizer-policy.
ocid	Token'ı alan OAuth istemcisi (azp, yoksa client_id).

Araç çağrısının sonuç sınıfı (mcprc) ayrıdır. Bkz. Loglama ve Analytics. Limit Planı, OAuth istemcisini OAuth İstemci Kimliği (standart MCP token'ı) bağlam değeriyle kullanabilir. Kullanıcı doğrulanmış kimlik olarak kalır. Bu yüzden Limit Planı kullanıcı zinciri diğer proxy'lerdeki gibi çalışır.

Standard profilinde Yönlendirme sekmesindeki ön koşullar paneli kanonik kaynağı, yetkilendirme sunucusunu (issuer) ve Tarayıcı ile giriş (authorization_code) satırını gösterir. Satır üç durumdan birini bildirir: açık (politikanın kimlik kaynağındaki kullanıcılar giriş sayfasında oturum açar), kullanılabilir (her uygulamanın API istemcisinde açılır) ya da bu yetkilendirme sunucusunun sunmadığı.

Adım adım örnekler: MCP Gateway'e Keycloak ile OAuth Girişi (harici kimlik sağlayıcı) ve MCP Gateway'e Keycloak Olmadan Tarayıcı ile Giriş (Apinizer yetkilendirme sunucusu).

Araç Risk Politikası ve Onay

Araç risk politikası her araç çağrısına bir risk düzeyi verir ve her düzey için gateway'in ne yapacağını belirler. Her iki modda da çalışır ve varsayılan olarak kapalıdır. Politika kapalıyken her çağrıya izin verilir ve hiçbir düzey hesaplanmaz.

Risk düzeyleri

Bir araç üç düzeyden birini alır: Düşük, Orta veya Yüksek. Gateway eşleşen ilk kuralı uygular:

1. Sizin ayarınız. Araçları Aç modunda aracın Risk düzeyi alanı. Passthrough modunda Araç risk düzeyleri listesinde aracın tools/list yanıtındaki adıyla eklediğiniz satır.
2. Güvenilen araç işaretleri. Arka uç sunucuda Araç işaretlerine güven açıksa: salt okunur araç Düşük, yıkıcı araç Yüksek, diğer araçlar Orta olur.
3. Güvenilmeyen araç işaretleri. Araç işaretlerine güven kapalıysa (varsayılan) işaretler düzeyi yalnız yükseltebilir. Yıkıcı araç Yüksek olur. Salt okunur işareti düzeyi düşürmez. Araç hem salt okunur hem yıkıcı işaretliyse Yüksek olur.
4. Varsayılan. Araçları Aç modunda operasyonun HTTP metodu: GET ve HEAD Düşük, DELETE Yüksek, diğer metotlar Orta. Passthrough modunda Orta.

İşareti olmayan araç varsayılan düzeyini korur. Araç işaretlerine güven ayarını yalnız sizin yönettiğiniz sunucu için açın.

İşlemler

Her düzey için üç işlemden birini seçersiniz:

İşlem	Gateway'in yaptığı
İzin ver	Çağrı devam eder.
Onay iste	Çağrı, bir yönetici onaylayana kadar bekler.
Reddet	Gateway çağrıyı reddeder.

Politikayı açtığınızda ekran Düşük = İzin ver, Orta = İzin ver ve Yüksek = Onay iste değerleriyle başlar. Her birini değiştirebilirsiniz.

Muafiyetler, kimlik kurallarıdır (tüketici / API istemcisi, rol veya organizasyon). Eşleşen çağıran için Onay iste, İzin ver olur. Reddet değişmez. Muafiyet yalnız kimliği denetler. Bu yüzden bütün araçlar için geçerlidir.

Risk denetimi scope ve kimlik kurallarından, ve argüman kısıtlarından sonra, çağrı gönderilmeden hemen önce çalışır.

Onay akışı

1. Çağrı onay gerektirir. Gateway bir onay isteği yazar ve istemciye hemen yanıt verir:
   • Tasks uzantısını bildiren istemci "onay bekliyor" durumunda bir task alır.
   • Diğer istemciler approvalId içeren -32021 hatasını alır (ERR-309).
2. Yönetici isteği Bekleyen araç onayları bölümünde onaylar ya da reddeder (aşağıya bakın).
3. Onaydan sonra istemci task'ı tasks/get ile okur ya da aynı çağrıyı yeniden gönderir. Gateway çağrıyı bir kez çalıştırır. Hiçbir şey çağrıyı kendiliğinden çalıştırmaz.
4. Karardan önce aynı çağrının yeni bir denemesi ikinci istek oluşturmaz. Aynı çağıran bir proxy'de en çok 20 açık onay isteğine sahip olabilir. Sonraki çağrı reddedilir.

Onay kuralları:

• 15 dakika. İstek, istek anından itibaren 15 dakika geçerlidir. Karar ve tek çalıştırma bu sürede gerçekleşmelidir. Sonra istek sona erer.
• Reddedilen istek. Reddten sonra 15 dakika boyunca aynı çağrı bir politika hatasıyla reddedilir. Sonra yeni bir deneme yeni istek oluşturur.
• Çağrıya bağlı. Onay; çağıran, istemci, proxy, araç ve tam argümanlara aittir. Aracın çözümlendiği operasyona da aittir: Araçları Aç modunda hedef proxy, HTTP metodu ve yol; Passthrough modunda arka uç sunucu ve onun araç adı. Çağrı çalışırken bunlardan biri değişmişse gateway çağrıyı çalıştırmaz ve task başarısız olur.
• Çalışma anında yeniden denetim. Gateway onaylanan çağrıyı çalıştırırken scope'u, kimlik kurallarını ve risk politikasını yeniden denetler. Aracı artık reddeden bir politika çağrıyı durdurur.
• Onay sayılmayanlar. Elicitation yanıtı ya da bir bağlantıyı açmak hiçbir zaman onay değildir. Kararı yalnız Manager'daki yönetici verir.
• Anonim proxy'ler. Proxy'de kimlik doğrulama yoksa gateway onayı bir kimliğe bağlayamaz. Aynı argümanlı her çağrı aynı onayı kullanır. Risk politikasını bir kimlik doğrulama politikasıyla birlikte kullanın.

Bekleyen araç onayları

Yönlendirme sekmesindeki Bekleyen araç onayları bölümü karar bekleyen istekleri listeler. Araç, risk düzeyi, çağıran, istemci kimliği, işlem (çözümlenen hedefin özeti), istek zamanı ve son geçerlilik zamanı görünür. Onayla veya Reddet seçeneğini seçin ve onaylayın.

• Bölüm araç adını ve işlem özetini gösterir. Argüman değerlerini göstermez.
• Projede AI geliştirme veya API yönetimi MANAGE yetkisine ihtiyacınız vardır.
• Manager'da verilen onay ve ret kararları denetim (audit) loguna yazılır.
• Gateway diğer sonuçları (politika reddi, süresi dolan istek, değişen hedef ya da argümanlar) task kaydının durumunda, trafik logundaki Araç onayı alanında ve gateway log'unun bir uyarı satırında izler. Bu sonuçlar denetim logunda yer almaz.

Trafik logu ve alarmlar

• Çağrının trafik detayı Araç onayı alanını gösterir: Bekliyor, Onaylandı, Reddedildi veya Süresi doldu. Aynı değer mcpap adlı bir log alanıdır. Elasticsearch şablonu bu alanı yükseltmeden sonra taşır.
• İki alarm tetiklenme tipi onayları izler: MCP Araç Onayı Bekleyen Sayısı (şu anda bekleyen istekler) ve MCP Araç Onayı Ret Sayısı (son 1 saatteki redler). İkisi de Proje kapsamını kullanır. Bkz. Alarmlar.

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:

Nerede	Alanlar
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çlar	Gerekli 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, LLM 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 ve — araç risk politikasının onay için beklettiği çağrılarda — Araç onayı durumunu 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ı, 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 LLM 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.

Yeni MCP log alanları şunlardır: mcpap (araç onayı durumu), usub, uids ve ocid (Standard profilinin kullanıcı bağlamı) ve mcprc (araç çağrısının sonuç sınıfı: OK, TOOL_ERROR, JSONRPC_ERROR, TRANSPORT veya POLICY_REJECT). Elasticsearch, MongoDB, GELF ve JSON log bağlayıcıları bu alanları yazar. SQL/JDBC trafik log bağlayıcısının kolon listesi bu sürümde değişmez; bu alanlar orada saklanmaz.

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 kavram	Yeni karşılığı
MCP Inbound Sunucusu kaydı	MCP tipinde API Proxy
Sunucu bazlı Yok/API Anahtarı/OAuth2 modu	Proxy'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 Yönlendirme 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

A2A Gateway

Ajanlar arası görev devrini yapılandırın

Global Politikalar

Araç çağrısı politikalarını merkezi olarak yönetin

Tüketiciler

MCP Gateway'inizi çağıran tüketicileri yönetin

İzleme ve Tekrar Oynatma

Araç çağrısı zincirlerini trace üzerinde izleyin