MCP Nedir: Model Context Protocol Nasıl Çalışır

LLM’ler bir süredir araçları çağırabiliyor, ancak Model Context Protocol (MCP) bunu yapmak için yapılandırılmış ve standartlaştırılmış bir yol sunuyor.

Yine de MCP’nin gerçekte ne olduğu konusunda hâlâ kafa karışıklığı var.

Birçok kişi MCP’nin bir uygulama, API veya araç olduğunu varsayar, ancak bunların hiçbiri değildir. MCP bir protokoldür ve bu çok belirli bir anlama gelir.

Bunu parçalara ayıralım.

MCP’nin pratikte neyi mümkün kıldığını görmek istiyorsanız bu kısa videoya bakın:

Protokol nedir?

Protokol, iki veya daha fazla sistemin birbiriyle nasıl iletişim kuracağını tanımlayan bir kurallar kümesidir.

Tek başına hiçbir şey yapmaz. Yalnızca iki varlık arasındaki konuşmanın yapısını ve beklentilerini tanımlar. Bunu, bilgisayarların bilgi alışverişi yapmak için izlediği katı dil bilgisi kurallarına sahip ortak bir dil olarak düşünebilirsiniz.

Posta sistemleri de benzer bir şey yapar. Herhangi bir ülkedeki tüm postaneler mektupları göndermek için standartlaştırılmış bir adres biçimini izler.

Veya bunu AI araçları için USB-C gibi düşünebilirsiniz. Yirmi yıl önce pazar, farklı türde şarj ve veri kablolarıyla doluydu. AI ekosistemlerinde de araçları dil modellerine aktarmanın birden fazla yolu vardı. LangChain, Haystack ve Pydantic AI gibi framework’ler araç entegrasyonu için kendi formatlarını tanımladı. Bu, bir geliştirici Google Maps için bir araç seti yazmak istiyorsa bunu her belirli teknoloji için ayrı ayrı yapması gerektiği anlamına geliyordu.

Bunu daha somut hale getirmek için web sitelerini çalıştıran en popüler protokol olan HTTP’ye (Hypertext Transfer Protocol) bakalım. HTTP, diğer şeylerin yanı sıra, bir tarayıcının (istemci) bir web sunucusundan bir web sayfasını nasıl isteyeceğini ve sunucunun nasıl yanıt vermesi gerektiğini tanımlar.

Bir HTTP istek-yanıt döngüsü örneği:

1. Tarayıcı bir HTTP isteği yapar

Tarayıcınıza https://example.com yazdığınızda tarayıcı web sunucusuna yapılandırılmış bir HTTP isteği gönderir:

Örneğimizde kullanılan HTTP parametreleri ve değerleri şunlardır:

"GET" – Bu eylemdir (bir web sayfası isteme).
"/index.html" – İstenen belirli web sayfası.
"HTTP/1.1" – Kullanılan protokolün sürümü.
"Host: example.com" – Web sitesinin alan adı.
"User-Agent: Mozilla/5.0" – İsteği yapan tarayıcı hakkında bilgi.

Web sunucusu bu isteği nasıl yorumlayacağını bilir çünkü HTTP bu formatı standartlaştırır. Bu “dili” anlar.

2. Sunucu HTTP protokolünü kullanarak yanıt verir

Sunucu isteği işler ve yapılandırılmış bir HTTP yanıtı geri gönderir:

"HTTP/1.1 200 OK" – Yanıt kodu (200 başarı anlamına gelir).
"Content-Type: text/html" – Geri gönderilen içeriğin türü.
"Content-Length: 512" – Yanıtın boyutu.
HTML Content – Gerçek web sayfası içeriği (yalnızca "Welcome to Example.com" başlığı vardır)

Önemli: HTTP’nin kendisi web sayfalarını depolamaz veya görüntülemez. Yalnızca web tarayıcılarının ve web sunucularının nasıl iletişim kurmasına izin verildiğine dair kuralları tanımlar. Bu kuralları izleyen herhangi bir sistem, HTTP tarafından tanımlanan İnternet üzerinden iletişim kurabilir.

MCP bir protokol olarak nasıl çalışır?

Şimdi aynı düşünceyi MCP’ye (Model Context Protocol) uygulayalım.

MCP, AI agent’larının harici araçlar ve veri kaynaklarıyla konuşması için bir protokoldür. HTTP gibi, veriyi depolamaz veya görevleri kendisi yürütmez. Yalnızca AI’nin araçlardan bilgi istemesi ve alması için standartlaştırılmış bir yol tanımlar.

Bu “araçlar” nedir diye sorabilirsiniz.

LLM bağlamında araçlar, AI’nin yalnızca metin üretmenin ötesinde yeteneklerini genişletmek için etkileşim kurabildiği harici sistemler, API’ler veya servislerdir. AI agent’larının gerçek zamanlı veri almasına, randevu ayarlamasına veya arkadaşlarınıza mesaj göndermesine olanak tanır. Bu da onları gerçek dünya ihtiyaçları için çok daha kullanışlı hale getirir.

Bir AI agent’ına şunu sorduğunuzu varsayalım:

“Londra’da şu anda saat kaç?”

AI’nin kendisi doğru yanıtı bilmediği için, çünkü AI modellerinin bir bilgi kesim tarihi vardır (OpenAI modelleri için Ekim 2023), canlı veriyi bir zaman servisinden alması gerekir. Ancak AI, bir web sayfası istemek için HTTP kullanmak yerine, zaman verisi istemek için MCP kullanır.

Olan şudur:

1. AI agent’ı zaman servisine bir MCP isteği yapar (örnek)

"method": "tools.call" → AI harici bir aracı çağırıyor.
"tool": "get_time" → Kullanmak istediği aracın adı.
"args": { "location": "London" } → Belirli giriş parametreleri.

HTTP’de olduğu gibi bu istek de katı bir formatı izler. Böylece MCP uyumlu herhangi bir araç bunu nasıl yorumlayacağını tam olarak bilir.

2. MCP zaman sunucusu yanıt verir

Harici araç (zaman sunucusu), MCP’nin yanıt kurallarını izler ve şunu geri gönderir:

"status": "success" → İsteğin doğru işlendiğini onaylar.
"result" → Gerçek zaman verisini içerir.

Artık AI agent’ı bu veriyi alabilir ve kullanıcıya şu şekilde gerçek bir yanıt oluşturabilir:

“Londra’da şu anki saat 12:20 PM (GMT).”

Özetlemek ve karışıklığı gidermek için:

“MCP bir uygulamadır.” → Hayır, MCP bir kurallar kümesidir. Onu gerçekten kullanmak için MCP’yi uygulayan AI yazılımına ve araçlara ihtiyacınız vardır. Tıpkı Instagram uygulamasının HTTP isteklerine yanıt vermek ve veri iletmek için canlı Instagram sunucularına ihtiyaç duyması gibi.

“MCP bir veritabanıdır.” → Hayır, MCP veri depolamaz. AI agent’larının veritabanları veya API’lerle konuşmasına yardımcı olur.

“MCP bir API gibidir.” → Tam olarak değil. API, tek bir sistemle etkileşim kurmanın belirli bir yoludur. Protokol ise (MCP veya HTTP gibi) birçok farklı sistemin iletişim kurabildiği evrensel bir yolu tanımlar. MCP, bir AI sisteminin birçok gerçek API ile (zaman, veritabanları, Stripe, Slack vb.) etkileşim kurmak için kullanabileceği bir dildir.

MCP neden heyecan verici?

Artık MCP’nin AI yazılımının harici araçlar ve uygulamalarla etkileşim kurması için standartlaştırılmış bir yol olduğunu ve MCP’nin bir API olmadığını bildiğimize göre, AI geliştirici topluluğunun (biz dahil) neden bundan heyecan duyduğunu anlayalım.

MCP bir API değil, AI uygulamalarının gerçek API’lerle ölçekli şekilde etkileşim kurmasına olanak tanıyan bir yapı olduğu için, birçok harici sisteme bağlanmayı gerektiren projelerin daha hızlı başlamasına yardımcı olur. Araçlar ayrıca bir modele erişim alanı sağlar ve OpenAI Hugging Face olayında yaşananlar, bu erişim alanı görevin ötesine geçtiğinde bunun nasıl göründüğünü gösterir. Bunu yapmak için geliştiricilerin bazen tam bir API entegrasyonu geliştirme döngüsünden geçmesi gerekirdi. Ancak bugün genellikle gerekli işlevselliği sağlayan mevcut kütüphaneleri veya açık kaynak projeleri (örneğin GitHub’da bulunan) kullanırlar.

Bu kütüphaneleri kullanmak geliştirmeyi hızlandırır, ancak bunları sisteminizle doğru şekilde entegre etmek (GitHub’da bulduğunuz implementasyonla uyumlu değilse) yine de emek gerektirir. Aracın AI ile çalışmasını sağlamanız gerekir.

MCP ile framework yerindeyse yeni bir entegrasyon eklemek (örneğin Google Drive entegrasyonu) birkaç satır kodla Google Drive MCP sunucusuna bağlanmak kadar basit olabilir. Uyumluluk sorunlarıyla karşılaşmazsınız çünkü ikiniz de aynı protokolü kullanırsınız: MCP.

Farkları daha net görmek için iki yaklaşımı karşılaştıralım.

Standart entegrasyon ile Model Context Protocol (MCP) kullanımı

Bu karşılaştırmayı somut hale getirmek için bir AI Agent’a Google Drive dosya erişimi eklemeyi ele alalım. Önce manuel olarak, sonra MCP uyumlu bir araçla.

Standart entegrasyon

1. Bir kütüphane bulun ve uyarlayın: Bir Google Drive API istemcisi veya açık kaynak proje ararsınız. Google istemci kütüphaneleri sağlar (ör. Python için Google Drive API). Bunu projenize eklersiniz. Yine de bunun AI’nizin ortamıyla çalıştığından emin olmanız gerekir.

2. Mantığı uygulayın: Örneğin dosya aramak veya Drive’dan bir belge almak için fonksiyonlar yazarsınız. AI, bir şeye ihtiyaç duyduğunda bu fonksiyonları çağırmalıdır. AI’nin isteğini Google Drive’a özgü API çağrılarına dönüştürürsünüz. Google’dan yanıt aldıktan sonra içeriği çıkarır ve AI’nin context’ine geri aktarırsınız.

3. Hataları ve uç durumları yönetin: “Dosya bulunamadı”, izin hataları veya API hız limitleri gibi durumları ele almak için kod eklersiniz. Google’ın API’si bir hata döndürürse bunu yakalar ve belki özür içeren bir mesajla yanıt verir veya AI’den yeniden ifade etmesini istersiniz. Ayrıca AI’nizin çok kısa sürede çok fazla istek göndermesini engellemeniz gerekir.

4. Bakımını yapın: Zamanla Google API’sini veya kütüphaneyi güncellerse kodunuzu güncellemeniz gerekir. Kütüphanede bir bug bulursanız yama yapmanız veya başka bir kaynak bulmanız gerekebilir. Esasen AI uygulamanız içinde bu Google Drive entegrasyonunun bakım sorumlusu olursunuz.

Bu süreç diğer araçlara da uzanır: AI’nize Slack veya bir veritabanı eklemek mi istiyorsunuz? Her biri için tüm süreci tekrarlamanız gerekir.

MCP entegrasyonu

Şimdi MCP kullanıldığında bu sürecin nasıl görüneceğine bakalım.

Önce temel kavramları tanımlayalım:

Client – Bir veya daha fazla sunucuya bağlantı kuran ve bir kullanıcının prompt ettiği görevleri gerçekleştirmek için bilgi veya eylem isteyen bir AI uygulaması (ChatGPT, Claude app, Quickchat AI).

Server – Her sunucu bir veritabanı veya bir API (Google Drive) gibi bir şeye bağlanabilir ve sağlayabileceği bir “araç” veya veri kümesi tanımlayabilir. Bu durumda server, bu araçları ve yetenekleri Client’a (AI app) sunan bir programdır.

Geliştiriciler, yapmak istedikleri şeye bağlı olarak iki taraftan birini seçebilir: veriyi sunmak için bir server oluşturmak veya herhangi bir server ile konuşabilen bir AI client oluşturmak. Çoğu kişi ikinci seçeneği ister, ancak MCP’nin adım adım nasıl çalıştığını anlamak için yine de server tarafıyla başlayalım:

• Bir MCP server başlatma. Bir geliştirici veya sistem yöneticisi, belirli bir araç veya veri kaynağı için bir MCP server kurar. MCP server genellikle MCP spesifikasyonunu uygulayan küçük bir programdır. Örneğin, belgeleri nasıl arayacağını ve getireceğini bilen hazır bir Google Drive MCP server mevcuttur.

  Server başlatılırken hedef sisteme (Google Drive) erişim verirsiniz. Server daha sonra işleyebileceği eylemlere veya sorgulara karşılık gelen bir araç kümesini sunar. Esasen bir tarafta MCP konuşan, diğer tarafta yerel servisle konuşan bir API adaptörüdür.

  Server çalışmaya başladıktan sonra istekleri bekler.

• Bir LLM’i (client) bir MCP server’a bağlama. Sonra AI uygulamasının (“client” tarafı) bu server’a bağlanması gerekir. Pratikte, MCP’yi destekleyen bir AI platformu (Claude Desktop gibi) kullanıyorsanız, bunu server’ı başlatacak adres veya komutla yapılandırırsınız. Bağlandıktan sonra client, MCP’nin handshake’ini izleyerek server ile bir oturum kurar. Claude arayüzünü kullanıyorsanız Claude’un belirli MCP server’lara “connected” olduğunu görürsünüz (UI, kullanılabilir connector’ları gösterebilir).

Claude UI’da böyle görünür

• Kullanılabilir araçları keşfetme. Bağlantı kurulduktan sonra yapılacak ilk şey, server’ın ne sunduğunu öğrenmektir (bazen bu, server’a bağlandıktan sonra otomatik olarak gerçekleşir). MCP client, server’a tools/list isteği gönderir (bu protokolde tanımlıdır). Server, kullanılabilir araçlarının listesini döndürür. Her biri ad, açıklama ve input schema gibi ayrıntılar içerir.

  Örneğin bir server, create_file(path, content), read_file(path) ve search_files(query) araçlarının kullanılabilir olduğunu bildirebilir. Client daha sonra bu bilgiyi LLM’in kullanımına sunar. Birçok implementasyonda client, bu araç açıklamalarını formatlar ve modelin context’ine ekler (örneğin system prompt’a şunu ekler: “Aşağıdaki araçlara erişiminiz var… [araç listesi]”).

Kullanıcının geçerli saati isteyen mesajıyla birlikte bir AI system prompt’u

MCP araçları uygulandığında, “get_current_time” adlı bir araç entegre edilir. Bu, AI’nin harici bir kaynağa erişmesine ve Londra’daki kesin saati almasına olanak tanır

Bu, AI uygulamanızın bir görevi tamamlamak için ihtiyaç duyabileceği tüm olası eylemleri önceden düşünmeniz ve programlamanız gerekmediği anlamına gelir. MCP ile AI, bir MCP server’a sorarak tüm olası eylemleri anında keşfedebilir ve gerekli olanı seçebilir.

• MCP üzerinden bir araç kullanma. AI’nin bir eylem gerçekleştirmesi veya veri alması gerektiğinde MCP üzerinden bir aracı çağırır. AI’nin bakış açısından (özellikle araç kullanımını yerel olarak destekleyen Claude gibi modeller için) muhakemesinde şuna karar verir: “Bu parametrelerle X aracını çağırmalıyım.” MCP client bu niyeti yakalar ve MCP formatında uygun server’a (Google Drive MCP server) bir tools/call isteği gönderir.

• MCP server bir köprü görevi görür. AI agent’tan yapılandırılmış ve MCP uyumlu bir istek alır, bunu doğru Google Drive API endpoint’ine eşler, isteği gerçek bir Google Drive API çağrısına yeniden yazar, isteği yürütür, yanıtı işler ve AI agent’a geri göndermeden önce tekrar MCP uyumlu bir yanıta dönüştürür.

  Dikkat çekici olan nokta, MCP server’ların hataları ele almak için yapılandırılmış bir yaklaşım izlemesidir. Bu, AI Agent’ların hataları etkili şekilde yorumlamasını ve bunlara göre hareket etmesini sağlar.

  Diyelim ki bir AI Agent, Google Drive’da bir dosya bulmak için bir MCP aracı kullanıyor. İstek geçersiz bir dosya ID’si içeriyorsa (örneğin beklenen format yerine beş karakter uzunluğunda bir string), MCP server bir hata mesajı döndürür:

  AI Agent, basitçe başarısız olmak yerine bu yapılandırılmış yanıtı alıp kullanıcı dostu geri bildirime dönüştürebilir:

  “Sağladığınız dosya ID’si çok kısa görünüyor. Google Drive dosya ID’leri genellikle 28 karakter uzunluğundadır. Kontrol edip tekrar deneyebilir misiniz?”

  Bu yaklaşım, hataların çıkmazlara yol açmamasını sağlar. Bunun yerine AI Agent’ın kullanıcıyı başarılı bir çözüme yönlendirmesi için fırsat oluşturur.

• Kullanıcının sorusunu/isteğini yanıtlama. MCP server bir sonuç döndürdüğünde MCP client bu veriyi AI app’e geri verir. Model daha sonra sonucu muhakemesine veya kullanıcı için ürettiği çıktıya doğrudan dahil eder.

  Kullanıcı yeni bir Google Sheets dosyası oluşturulmasını isterse server’ın yanıtı (dosya ID’si ve oluşturulan bağlantıyı içeren) modele verilir. Model daha sonra kullanıcıya şu şekilde yanıt verir: “İyi haber! Yeni Google Sheets dosyanız hazır. Buradan erişebilirsiniz: [link].”

Bu süreç boyunca AI akışın kontrolünü elinde tutar: bir aracı ne zaman çağıracağına ve sonucu yanıtını oluştururken nasıl kullanacağına karar verir. Bu arada geliştiricinin bu adımları manuel olarak düzenlemesi gerekmez, MCP framework’ü ve AI modeli bunu yönetir. Sonuç olarak kullanıcı, AI’ye harici bilgi veya eylem gerektiren karmaşık sorular veya görevler verebilir. AI de bunları MCP üzerinden otonom olarak gerçekleştirebilir ve bir sonuç döndürebilir.

MCP kullanmanın faydaları

Bu yaklaşımın birçok ayrıntıyı nasıl soyutladığına dikkat edin: client API anahtarlarını veya HTTP durum kodlarını yönetmedi, bunlar MCP server tarafından ele alındı.

Ana nokta, entegrasyon noktasındaki basitliktir: müşterileri “isteriz” ve onları alırız. Bunların nasıl getirileceğine dair mantık başka bir yerde kapsüllenmiştir. Bu, AI tarafında çalışan bir geliştiricinin her yeni eylem için yeni HTTP çağrıları yazması gerekmediği anlamına gelir, yalnızca araçları adlarıyla çağırır. Ağır iş (kimlik doğrulama, Google Drive endpoint’lerini çağırma, yanıtı formatlama) yeniden kullanılabilir ve standartlaştırılmış MCP server kodunda yapılır.

Temel faydaların özeti:

• API’ye özgü bağlantı kodunu azaltır. MCP’den önce bir AI’nin harici bir servisi kullanmasını sağlamak genellikle çok sayıda “glue” kod yazmayı gerektirirdi: API’yi çağırmak, yanıtı modelin işleyebileceği metne dönüştürmek, ardından modelin çıktısını ayrıştırıp belki başka bir API’yi çağırmak vb. MCP ile bu bağlantı kodunun büyük kısmı ortadan kalkar. Modelin client’ı ve server, veri alışverişini yapılandırılmış şekilde yönetir. Bu nedenle JSON gibi diğer formatları manuel olarak metne veya tersine dönüştürmeniz gerekmez, protokol bunu yapar. Ayrıca ne zaman neyin çağrılacağına karar veren mantığı yazmanız da gerekmez. AI (araç açıklamaları ve kendi muhakemesi veya prompt’u tarafından yönlendirilerek) bunu yapar.

• Tek seferlik API wrapper’ları yerine yeniden kullanılabilir, paylaşılan connector’lar. MCP ile bir entegrasyonu bir kez yazarsınız ve birçok projede ve AI sisteminde yeniden kullanabilirsiniz. Örneğin şirketinizin dahili wiki’si için bir MCP server oluşturabilirsiniz. MCP’yi destekleyen herhangi bir AI app, wiki’yi sorgulamak için bu tek server’a bağlanabilir. Her yeni AI chatbot veya her farklı LLM sağlayıcısı için “wiki arama”yı yeniden uygulamanız gerekmez. Bu yeniden kullanılabilirlik, geçmişte her ekibin aynı API için biraz farklı kendi entegrasyonunu yazdığı yaklaşımdan bir değişimdir. MCP, paylaşılabilen ve birlikte iyileştirilebilen bir connector kütüphanesini teşvik eder.

• Farklı LLM’lerle tak ve çalıştır entegrasyon. MCP modelden bağımsızdır. Client Claude, GPT-4, DeepSeek veya gelecekteki herhangi bir model olsun, client MCP arayüzünü yönetebildiği sürece protokol bunu önemsemez. Gelecekte başka bir modele geçmek isterseniz tüm entegrasyonlarınızı yeniden yazmadan bunu yapabilirsiniz.

• Daha kolay bakım. Açık bir standart olduğu için, sıfırdan oluşturmak yerine yararlanabileceğiniz hazır server’lara (veritabanları, popüler API’ler vb. için) katkı yapan büyüyen bir topluluk vardır. Daha fazla sistemi entegre ettikçe MCP, çok sayıda noktadan noktaya entegrasyonun oluşturduğu “spagetti” yapısından kaçınmaya yardımcı olur. Ayrıca diğer sağlayıcıların tüm API güncellemelerini izlemeniz gerekmez.

API entegrasyonları kullanım dışı mı kalacak?

Hem geleneksel API entegrasyonlarının hem de MCP’nin yeri vardır. En iyi yaklaşım projenin doğasına, ekibin uzmanlığına ve uzun vadeli hedeflere bağlı olabilir.

Yalnızca bir veya iki harici servisle entegre olmanız gerekiyorsa ve etkileşimler görece basitse, doğrudan API entegrasyonu çoğu zaman en hızlı çözümdür. Web uygulamanızın ödeme sırasında yalnızca bir Stripe ödeme token’ını doğrulaması gerekiyorsa, Stripe API’sini doğrudan çağırmak basit ve etkilidir. Bu senaryoda MCP’yi dahil etmek gereksiz olabilir. İncelenmiş tek bir HTTP Action ile bir AI Agent’ı herhangi bir belgelenmiş REST API’ye bağlayabilir veya MCP server çalıştırmadan lead’leri ve demo taleplerini kaydetmek için Google Sheets gibi tek tıkla entegrasyon kullanabilirsiniz.

İstek/yanıt üzerinde çok sıkı kontrole ihtiyaç duyduğunuz durumlarda (performans ayarı, özel veri işleme veya tescilli protokoller için), API’ye doğrudan yazmak daha iyi olabilir. Geleneksel entegrasyonlar, bir API’nin tüm gelişmiş özelliklerini kullanmanıza ve çağrıları tam olarak uyarlamanıza olanak tanır. Bir API’nin olağandışı gereksinimleri varsa veya en yüksek açıklık ve kontrol için herhangi bir soyutlama katmanından kaçınmak istiyorsanız geleneksel yaklaşım uygundur.

MCP araçlarının özel API action’larıyla birlikte üretimdeki bir AI Agent’a nasıl sunulduğuna dair somut bir örnek için Quickchat AI Agents yaklaşımının her iki yöntemi nasıl birleştirdiğine bakın. MCP, tekil AI Actions veya “Generate from Text” ne zaman kullanılmalı konusundaki daha derin tartışma AI Agent’lar için API’ler: MCP’den Özel Endpoint’lere yazısında yer alır. Kendiniz denemek için canlı bir aracı konuşma sırasında çağırması amacıyla AI Agent’ınızı uzak bir MCP server’a bağlama adım adım kılavuzunu izleyin.

Kullanılabilir MCP server’ların listesi

MCP ile başlamanız gerekiyorsa aşağıdaki MCP server dizinlerine bakın:

• https://github.com/modelcontextprotocol/servers
• https://smithery.ai

Ayrıca hiç kod yazmadan da bir tane çalıştırabilirsiniz: Her Quickchat AI Agent bir MCP server’a dönüştürülebilir. Claude, ChatGPT ve Cursor’ın araç olarak çağırdığı barındırılan bir URL ile çalışır. Bağlantı diğer yönde de çalışır: Bir Quickchat AI Agent, araçları olarak bir satıcının barındırılan MCP server’ını çağırabilir. Calendly’nin MCP server’ı üzerine kurulu AI planlama asistanının gerçek uygunluğu kontrol edip sohbetten toplantı rezervasyonu yapması ve Notion AI chatbot’unun canlı bir yardım merkezinden yanıt verip destek taleplerini bir Notion veritabanına geri kaydetmesi bu şekilde çalışır.

Quickchat AI ayrıca kendi hesabınız için uzak bir MCP server çalıştırır. Bunu ChatGPT, Claude, Cursor veya Codex’e bağlayabilir ve AI Agents’larınızı oradan yönetebilirsiniz: analizler, konuşma transkriptleri, knowledge base güncellemeleri ve yeni Agent oluşturma, tek bir OAuth oturum açmasının arkasında. Her client için kurulum adımları ChatGPT, Claude ve Codex’ten MCP ile AI Agent’ınızı Yönetin yazısında yer alır.

FAQ

Yalnızca Claude ile mi çalışır?

MCP modelden bağımsızdır. Client Claude, GPT-4, yerel bir LLaMA türevi veya gelecekteki herhangi bir model olsun, client MCP arayüzünü yönetebildiği sürece protokol bunu önemsemez. Bu, araç entegrasyonlarınızı oluştururken tek bir AI sağlayıcısına kilitlenmediğiniz anlamına gelir.

MCP, modele ihtiyaç duyduğu tüm bilgileri baştan vermekten nasıl farklıdır? Neden veriyi prompt’a doldurmayalım?

MCP, modelin prompt’una veri doldurmaktan temelde farklıdır. Çünkü modelin statik ve önceden yüklenmiş bir prompt ile çalışması yerine, gerektiğinde bilgiyi dinamik olarak almasına olanak tanır. Prompt’a metin doldurmak sınırlamalarla karşılaşır, çünkü AI modellerinin sabit bir context penceresi vardır. Bu, çok fazla verinin önemli ayrıntıların kaybolmasına, yanıtların yavaşlamasına ve API maliyetlerinin artmasına neden olabileceği anlamına gelir (LLM sağlayıcılarının kullandığı token başına fiyatlandırma modelleri nedeniyle). Ayrıca yalnızca zamanın tek bir noktasındaki bilgiyi sağlar. MCP ise canlı harici verilere gerçek zamanlı erişimi mümkün kılar ve AI’nin eylem almasını sağlar, yalnızca bilgi okumasını değil. Dolu bir prompt’a sahip bir AI müşteri ayrıntılarını bilebilir, ancak kayıtları güncelleyemez veya işlemleri gerçekleştiremez.

AI’ye düzinelerce araç bağlarsak ne olur? Bu modeli bunaltmaz mı veya araçları yanlış kullanmasına neden olmaz mı?

Bu implementasyona bağlıdır, ancak mevcut LLM’lerin birçok seçenek arasında ayrım yapma ve seçim yapma konusunda sınırlamaları olduğu doğrudur. Bir modele örneğin 50 olası araç sunarsanız, yanlış olanı seçme riski vardır. MCP yaklaşımının kendisi her şeyi aynı anda yüklemeyi zorunlu kılmaz. İlgili araçları context’e göre bağlamalısınız. En iyi uygulama, yalnızca eldeki görev/alan için gereken araçları bağlamak ve multiagent collaboration kullanmaktır. Bu, bir tür araç yönlendirmesi veya önce hangi araç alt kümesinin dikkate alınacağına karar veren bir agent olabilir.

MCP ile Function Calling karşılaştırması

Geleneksel function calling (OpenAI API’sinde veya diğer LLM’lerde görüldüğü gibi), geliştiricinin bir fonksiyon kümesi tanımlamasına, tanımlarını modele vermesine ve modelin bunları argümanlarla adlarına göre “çağırmasına” olanak tanır. Bu, AI entegrasyonu için büyük bir adımdı, ancak sınırlamaları vardır. Temel farklardan biri araçların ne zaman ve nasıl tanımlandığıdır. Klasik function calling’de tüm olası fonksiyonların prompt içinde veya API aracılığıyla baştan (tasarım zamanında) bildirilmesi gerekir. Model yalnızca bu sabit fonksiyonları çağırabilir. MCP’de araçlar çalışma zamanında keşfedilebilir, AI neyin kullanılabilir olduğunu sorgulayabilir ve oturum ortasında yeni araçlar bile alabilir.

MCP ile GPT Actions ve Plugins karşılaştırması

GPT Actions/Plugins, ChatGPT için plugin’leri (web tarayıcısı veya PDF okuyucu gibi) etkinleştirebildiğiniz OpenAI ekosistemini veya araç kullanımı olabilen “GPTs”i (özel ChatGPT agent’ları) ifade eder. Bunlar heyecan vericiydi, ancak her plugin için özel geliştirme gerektiriyordu ve OpenAI platformlarıyla sınırlıydı. Bir görev için ChatGPT plugin’i istiyorsanız bir API ve manifest oluşturmanız, OpenAI onayından geçmeniz veya en azından manuel olarak etkinleştirmeniz gerekiyordu. Her plugin esasen bir silo idi, hava durumu plugin’i, seyahat plugin’i vb. Her biri kendi endpoint’lerine ve mantığına sahipti. MCP bu kavramı birleştirerek ve açarak geliştirir.

MCP ile RAG (Retrieval-Augmented Generation) karşılaştırması

Retrieval-Augmented Generation (RAG), bir LLM’in harici bir knowledge base ile desteklendiği bir tekniktir. Tipik olarak RAG, bir vektör veritabanı veya arama dizini içerir: kullanıcının sorgusu ilgili belgeleri veya verileri almak için kullanılır (anlamsal arama veya diğer yöntemlerle) ve bu belgeler yanıt oluşturulurken “okunacak” ek context olarak modele sağlanır. RAG, modele başlangıçta sahip olmadığı bilgiyi vermekle ilgilidir. Özellikle olgusal soru-cevap veya alana özgü bilgi için yararlıdır. Ancak RAG salt okunurdur, model metin pasajlarını alır, ancak alma işleminin ötesinde eylem gerçekleştirmez.

Buna karşılık MCP, yalnızca bilgilendirici context almakla değil, eylem almak veya keyfi işlemler gerçekleştirmekle ilgilidir. MCP ile bir AI bir şeyler yapabilir: veritabanına yazabilir, e-posta gönderebilir, kod çalıştırabilir vb. Bilgi getirmekle sınırlı değildir, harici sistemlerde değişiklikleri tetikleyebilir. Bu nedenle RAG ve MCP birçok açıdan farklı amaçlara hizmet eder.