"Servisin zaten bir API'si varken neden MCP kullanayım?" sorusu, dizinimize ilk kez bakan geliştiricilerden en sık aldığımız sorudur. Bu haklı bir soru ve cevabı oldukça kısa: MCP'yi bir API yerine kullanmazsınız. MCP'yi, belirli bir çağırıcı türü için API'nin üzerine inşa edersiniz.
Bu çağırıcı bir AI modelidir. Bir modelin, normal bir programın ihtiyaç duymadığı şeylere ihtiyaç duyduğunu bir kez anladığınızda, MCP ile API arasındaki fark belirsizliğini yitirir. Bu kılavuz; somut bir örnek, karşılaştırmalı bir tablo ve MCP'yi tamamen atlamanız gereken durumlarla konuyu detaylandırıyor.
Önemli çıkarımlar
- MCP bir API'nin yerini almaz. Çoğu MCP server, halihazırda var olan bir API üzerinde ince bir katmandır.
- Fark çağırıcıdadır: Bir API, bir geliştiricinin yazdığı koda hizmet eder; MCP ise çalışma zamanında (runtime) araçları keşfeden bir modele hizmet eder.
- Function calling, model tarafındaki kısımdır; MCP ise araçların uygulamalar arasında nasıl tanımlandığını, bulunduğunu ve bunlara nasıl erişildiğini standartlaştırır.
- Bir model karar vermediğinde doğrudan API'yi, tek bir uygulamadaki tek bir özellik için function calling yapısını, birçok uygulama veya agent araca ihtiyaç duyduğunda ise MCP kullanın.
Tek paragraflık cevap
İster REST, ister GraphQL ister gRPC olsun, bir API bir yazılımın diğerinden bir şey yapmasını isteme yöntemidir. Çağıran tarafın hangi endpoint'e gideceğini, ne göndereceğini ve nasıl kimlik doğrulaması yapacağını zaten bildiğini varsayar; çünkü bu kodu bir geliştirici yazmıştır. MCP ise yapay zeka uygulamalarının çalışma zamanında (runtime) araçları keşfetmesi ve bir model adına bu araçları çağırması için tasarlanmış bir protokoldür. Bir MCP server, düz dilde açıklamalar ve girdi şemaları içeren bir araç listesi yayınlar, model bunlardan birini seçer ve server asıl API çağrılarını gerçekleştirir. HostedMCP üzerinde bulacağınız çoğu MCP server tam olarak budur: halihazırda var olan bir API'nin üzerine inşa edilmiş ince bir katman.
Somut bir örnek: Stripe üzerinden iade işlemleri
Bir yapay zeka asistanının "bu müşteri için son ödemeyi iade et" komutunu yerine getirmesini istediğinizi varsayalım.
Sadece API kullanarak, birinin asistan için bu entegrasyonu yazması gerekir. Modelin anlayabileceği isim ve açıklamalara sahip bir fonksiyon şeması tanımlarlar. API anahtarını yönetirler. Müşteriyi bulurlar, ödemeleri listelerler, en sonuncusunu seçerler, iadeyi oluştururlar ve Stripe hata kodlarını modelin aksiyon alabileceği bir formata dönüştürürler. Ardından bunu tek bir uygulama içinde yayına alırlar. Destek ekibi aynı özelliği Claude içinde istediğinde veya geliştiriciler Cursor içinde istediğinde, aynı iş farklı bir formatta ve farklı bir kod tabanında tekrar yapılır.
MCP ile bu ara kod tek bir server içine taşınır. Model için yazılmış açıklamalarla birlikte list_charges ve create_refund gibi araçları (tools) duyurur. API anahtarını veya OAuth token'ı bünyesinde tutar. Claude, Cursor, ChatGPT, VS Code gibi herhangi bir MCP client buna bağlanabilir ve aynı davranışı elde edebilir. Stripe API'si hiç değişmedi. Değişen şey, yapay zekaya özel kısımları kimin yazmak zorunda olduğu ve bu işin kaç kez yapıldığıdır.
Yan yana karşılaştırma
| Geleneksel API | MCP | |
|---|---|---|
| Çağıran kim | Bir geliştiricinin yazdığı kod | Bir host uygulama aracılığıyla bir AI modeli |
| Çağıran mevcut olanları nasıl öğrenir | Derleme aşamasında dokümantasyon okuyarak | Çalışma zamanında sunucuya sorarak (tools/list) |
| Açıklamalar kimin için yazılır | Geliştiriciler için | Modeller için: aracın ne yaptığı ve ne zaman kullanılacağı |
| Mesaj formatı | Değişkenlik gösterir: REST, GraphQL, gRPC | Her sunucu için JSON-RPC 2.0 |
| Kimlik Doğrulama (Auth) | API keys, OAuth veya servisin seçtiği yöntem | Yerel sunucular için Env vars, uzak sunucular için OAuth 2.1 |
| İşlem kapsamı | API'nin sunduğu her şey | Sadece sunucunun sunmayı seçtiği araçlar |
| Tek bir entegrasyon nerede çalışır | Tek bir uygulamada | Tüm MCP istemcilerinde |
| Tipik gecikme (latency) | Tek bir ağ sıçraması (network hop) | Sunucu üzerinden fazladan bir sıçrama |
İki satır, normalde olduğundan daha fazla dikkat edilmeyi hak ediyor.
Keşfedilebilirlik (Discovery) asıl farkı yaratan unsurdur. Bir API'yi çağıran program, çalışma zamanında asla "neler yapabilirsin?" diye sormaz; geliştirici bunu zaten biliyordur. Bir modelin ise her oturumda bunu sorması gerekir ve cevabı üzerinde muhakeme yapabileceği kelimelerle alması şarttır. Bu yüzden bir MCP araç açıklaması, referans dokümantasyonundan ziyade bir tavsiye gibi okunur ("Bunu, belirli bir dizini etkileyen açık pull request'leri bulmak için kullanın").
Kapsam (Scope) ise bir güvenlik özelliğidir. Bir servis için kullanılan bir API key, genellikle o anahtarın yapmasına izin verilen her şeyi yapma yetkisi verir. Bir MCP server ise hangi işlemlerin mevcut olacağına bizzat karar verir. Salt okunur (read-only) bir analitik sunucusu, bir delete aracını basitçe dahil etmeyebilir. Bir modele "lütfen hiçbir şeyi silme" diyerek aynı garantiyi alamazsınız.
MCP ile function calling arasındaki farklar
Function calling (veya bazı sağlayıcıların tabiriyle tool use), bir model API'sinin özelliğidir: isteğinizde fonksiyonları listelersiniz ve model "şu argümanlarla şu fonksiyonu çağır" şeklinde yanıt verebilir. MCP de nihayetinde bu özelliği kullandığı için genellikle birbirleriyle karıştırılırlar.
Bu ikisinin nasıl bir arada çalıştığını şöyle açıklayabiliriz. Host uygulamanız (örneğin Claude Code), MCP server'lara bağlanır ve onların araçlarını (tools) toplar. Modele bir istek gönderdiğinde, bu araçları fonksiyon tanımları olarak iletir. Model bir fonksiyonun çağrılmasını istediğinde, host bu çağrıyı doğru MCP server'a yönlendirir ve sonucu modele geri besler. Yani function calling model tarafındaki kısmı oluştururken; MCP, diğer taraftaki her şey için (araçların sağlayıcılar arasında nasıl tanımlandığı, keşfedildiği, yetkilendirildiği ve bunlara nasıl erişildiği) kullanılan standarttır.
Eğer tek bir uygulamada, tek bir model ile tek bir özellik geliştiriyorsanız, düz function calling kullanmak daha az iş yükü getirir ve gayet yeterlidir. MCP ise aynı aracın birçok uygulamada çalışması gerektiğinde veya kullanıcıların kendi AI istemcilerini (client) getirmesini istediğinizde avantaj sağlar.
| Function calling | MCP | |
|---|---|---|
| Nedir | Tek bir model API'sinin bir özelliğidir | AI uygulamaları ile tool server'lar arasındaki bir protokoldür |
| Araçlar nerede tanımlanır | Uygulamanızın modele gönderdiği istekte | Herhangi bir istemcinin bağlanabileceği ayrı bir server'da |
| Nerede çalışır | Yazdığınız uygulamada | Tüm MCP client'larda |
| Keşif (Discovery) | Listeyi her istekte siz iletirsiniz | İstemci, çalışma zamanında (runtime) server'a sorar |
| En iyi kullanım alanı | Tek bir özellik, tek bir uygulama, tek bir model | Uygulamalar, agent'lar ve sağlayıcılar arasında paylaşılan araçlar |
Bir API ne zaman doğru tercihtir
Herhangi bir modelin dahil olmadığı durumlarda MCP kullanmaktan kaçının. Bir web frontend'i, mobil uygulama, gece çalışan bir senkronizasyon işi (nightly sync job) veya bir iş ortağı entegrasyonu doğrudan API'nizle konuşmalıdır. Bu senaryolarda bir MCP katmanı eklemek size bir avantaj sağlamaz, aksine sürece fazladan bir adım ekler.
Her çağrı üzerinde hassas kontrol sağlamanız gereken durumlarda MCP kullanmayın. Ödeme işlemleri, toplu silme işlemleri veya testleri ve denetim izleri (audit trails) olan, insan tarafından yazılmış bir kod yoluna ihtiyaç duyduğunuz her şey, o kodu yazarken bir yapay zeka size yardımcı olmuş olsa bile, API'yi çağıran normal kodun içinde yer almalıdır.
Modelin sadece halihazırda elinizde bulunan verilere ihtiyaç duyduğu durumlarda da MCP kullanmayın. Eğer uygulamanız bir müşteri kaydını çekip prompt içine yapıştırıyorsa, bu bir tool değil, context'tir ve bir server gerektirmez.
| Durum | Kullanılacak Yöntem |
|---|---|
| Bir web veya mobil frontend backend'inizi çağırıyorsa | API |
| Gece çalışan bir senkronizasyon veya iş ortağı entegrasyonu | API |
| Ödemeler, toplu silme veya denetim izi gerektiren işlemler | Test edilmiş kod üzerinden API |
| Uygulamanız veriye zaten sahipse ve prompt içine yapıştırıyorsa | Hiçbiri; bu bir tool değil, context'tir |
| Kontrol ettiğiniz tek bir uygulama içindeki tek bir yapay zeka özelliği | Function calling |
| Neye bakacağına veya ne yapacağına model karar vermeli ise | MCP |
| Müşterileriniz Claude, Cursor ve ChatGPT kullanıyorsa | MCP, ideal olarak hosted bir server |
| Birkaç dahili agent aynı sisteme ihtiyaç duyuyorsa | Tek bir paylaşılan MCP server |
MCP ne zaman doğru tercihtir
Bir modelin ne yapacağına karar vermesi gerektiğinde MCP'ye başvurun. Bilgi araştıran, destek talebi açan, veritabanı sorgulayan veya bir dağıtımı (deploy) kontrol eden agent'ların araçlara ihtiyacı vardır ve MCP, onlara araç sağlamanın standart yoludur.
Ürününüzün başkalarının kullandığı yapay zeka araçlarıyla da çalışmasını istiyorsanız, MCP doğru bir tercihtir. Müşterileriniz Claude, Cursor ve ChatGPT kullanıyorsa, tek bir MCP server hepsine ulaşabilir. GitHub, Linear, Notion ve Stripe gibi şirketlerin kendi sunucularını yayınlamasının nedeni budur. HostedMCP üzerinde resmi sunucuları ürüne göre inceleyebilir, hangilerinin barındırıldığını (hosted) hangilerinin yerel olarak çalıştırıldığını görebilirsiniz.
Ayrıca, şirket içinde birden fazla agent çalıştırıyorsanız da yardımcı olur. Her agent'ın içine kopyalanmış araç kodları yerine, her agent tarafından paylaşılan sistem başına bir MCP server kullanmak, güvenliği sağlamayı ve güncellemeyi çok daha kolay hale getirir.
Güvenlik de farklılık gösterir
API'ler ve MCP server yapıları, döngüde bir modelin yer alması nedeniyle farklı tehditlerle karşı karşıyadır.
Bir API kullanımında çağrıyı yapan sizin kodunuzdur ve yazdığınız şeyi yapar. MCP kullanımında ise çağrıyı yapan, web sayfaları, e-postalar veya issue yorumları gibi güvenilmeyen metinleri okuyan bir modeldir. Dikkatle yazılmış bir issue yorumu, modeli çalıştırmaması gereken bir aracı çağırmaya ikna etmeye çalışabilir. Bu durum prompt injection olarak adlandırılır; iyi host uygulamalarının veri değiştiren araçları çalıştırmadan önce onay istemesinin ve server'ların yalnızca en gerekli araç setini dışarı açmasının nedeni budur.
MCP spesifikasyonu token'lar konusunda da net bir duruş sergiler. Güvenlik en iyi uygulamaları uyarınca bir server, kendisine verilmemiş token'ları kabul etmemeli ve bir kullanıcının token'ını başka bir servise iletmemelidir. Bu hatalı kullanımın (anti-pattern) adı token passthrough'dur ve bir server'a güvenmeden önce kodunda kontrol edilmesi gereken ilk şeylerden biridir. Uzak server'lar için yetkilendirme OAuth 2.1 protokolünü takip eder ve 2026-07-28 revizyonu ile client kaydı Client ID Metadata Documents yapısına taşınır. Daha fazla bilgi için MCP güvenlik kılavuzumuza göz atabilirsiniz.
Dikkat edin
Bir MCP aracının aldığı her argümanı güvenilmeyen girdi olarak kabul edin. Aracı seçen model, onu yönlendirmek amacıyla yazılmış bir web sayfasını veya bir issue yorumunu okumuş olabilir.
Performans ve maliyet
Kullanıcılar bazen MCP'nin yavaş olmasından endişe edebiliyor. Yerel bir server, aynı makinedeki bir işleme yapılan ek bir çağrı ekler; uzak bir server ise bir HTTP gidiş-dönüş süresi (round trip) ekler. Her iki durum da, bir modelin cevabını yazarken harcadığı saniyelerin yanında oldukça küçüktür.
Asıl önemli olan maliyet context kullanımıdır. Host tarafından yüklenen her tool, modelin okuması gereken bir açıklama ve bir schema ile birlikte gelir; ayrıca her tool sonucu konuşmaya dahil edilir. Seksen adet detaylı tool içeren bir server, siz henüz bir şey sormadan context window'un önemli bir kısmını tüketebilir. HostedMCP üzerindeki her server sayfasında tüm tool listesini göstermemizin bir nedeni de budur: Bir server'ı kurmadan önce ne kadar büyük olduğunu görebilir ve eğer daha odaklanmış bir server işinizi görüyorsa daha küçük olanı seçebilirsiniz.
Bir API'yi başarılı bir MCP server haline getirmek
En cazip kısa yol, bir OpenAPI dosyasından her endpoint için bir tool üretmektir. Tam olarak bunu yapan araçlar mevcut ve hızlı prototipler için kullanışlılar. Ancak bunlar nadiren iyi bir server oluşturur. Birbirine çok benzeyen yüzlerce tool içeren birkaç listelemeyi açtığınızda sorunu göreceksiniz: model bunların her birini okumak zorunda kalıyor ve çoğu, bir konuşma sırasında kimsenin sormayacağı bir endpoint'e karşılık geliyor.
Bir model endpoint'ler üzerinden düşünmez. Görevler (tasks) üzerinden düşünür. "1042 numaralı fatura hakkında e-posta gönderen müşteriyi bul ve son üç ödemesini göster" ifadesi, birkaç endpoint'i kapsayan tek bir görevdir. İyi bir server, bu seviyede tool'lar sunar: bir e-posta, fatura numarası veya isim kabul eden find_customer ve kırk alanlı ham JSON yerine kısa, okunabilir bir özet döndüren recent_charges gibi.
| Endpoint tabanlı tool | Görev tabanlı tool |
|---|---|
GET /customers?email= |
e-posta, fatura numarası veya isim kabul eden find_customer |
40 alan döndüren GET /charges?customer= |
kısa, okunabilir bir özet döndüren recent_charges |
| Her endpoint için bir tool, toplamda yüzlerce tool | İnsanların sorduğu şeylerle eşleşen birkaç tool |
| Referans dokümanlardan kopyalanmış açıklamalar | Tool'un ne zaman kullanılacağını belirten açıklamalar |
Birkaç alışkanlık büyük fark yaratır.
-
Açıklamaları model için yazın. Sadece ne döndürdüğünü değil, tool'un ne işe yaradığını ve ne zaman kullanılacağını belirtin. "Ödemenin müşteriye ait olduğunu onaylamak için iade oluşturmadan önce bunu kullanın" ifadesi, bir model için alan listesinden çok daha değerlidir.
-
Daha az veri döndürün. Yanıtları bir insanın gerçekten bakacağı alanlarla sınırlayın ve net bir cursor ile sayfalama (pagination) yapın. Her ekstra alan context maliyeti yaratır ve modelin yanlış okuyabileceği daha fazla veri sunar.
-
Tehlikeli tool'ları belirgin hale getirin. Bunları
delete_projectgibi açıkça isimlendirin ve host'ların onay isteyebilmesi için spec'in sunduğu read-only ve destructive hint'lerini kullanın. Daha da iyisi, yıkıcı (destructive) işlemleri ilk versiyona dahil etmeyin. -
Her şeyi doğrulayın. Argümanlar, güvenilmeyen metinleri okumuş bir modelden gelir. Tipleri, aralıkları ve sahipliği (ownership), herhangi bir public endpoint için yapacağınız şekilde server tarafında kontrol edin.
Peki hangisini inşa etmelisiniz?
Henüz bir API'niz yoksa, önce API'yi inşa edin. Kendi uygulamanız, scriptleriniz ve iş ortaklarınız her halükarda buna ihtiyaç duyacaktır; sağlam bir API altyapısı olmayan bir MCP server, genellikle ikinci ve daha kötü bir API'ye dönüşme eğilimindedir.
Halihazırda bir API'niz varsa ve yapay zeka araçlarının ürününüzü kullanmasını istiyorsanız, API'nizin önüne bir MCP server ekleyin. İnsanların gerçekte talep ettiği şeylerle eşleşen birkaç araçla başlayın, açıklamaları bir geliştirici için değil bir model için yazın ve eğer mümkünse hem yerel bir paket hem de hosted bir endpoint olarak sunun. MCP server inşa etme kılavuzumuz, güncel SDK'lar ile TypeScript ve Python üzerinden bu süreci adım adım anlatmaktadır.
Eğer sadece kontrol ettiğiniz tek bir uygulama içinde tek bir yapay zeka özelliğine ihtiyacınız varsa, günümüzde function calling yeterlidir; bu fonksiyonları daha sonra alttaki API'yi değiştirmeden bir MCP server'a dönüştürebilirsiniz.
Bundan sonra ne yapmalı
Bunun pratikte nasıl göründüğünü görmek için GitHub server veya Postgres server seçeneklerinden herhangi biri gibi bilinen API'leri sarmalayan birkaç server açın ve bunların tool listelerini ilgili API dokümantasyonlarıyla karşılaştırın. Bilerek ne kadar çok şeyi dışarıda bıraktıklarını fark edeceksiniz. Eğer protokole yeni başlıyorsanız MCP nedir bölümünden başlayın; eğer sadece bir tanesini denemek istiyorsanız, client rehberlerimiz kullandığınız editör için gerekli konfigürasyonu tam olarak gösterecektir.