Model Context Protocol (MCP) ve Otonom Ajan Orkestrasyonu

Model Context Protocol (MCP) ve Otonom Ajan Orkestrasyonu#

Bir yapay zekâ modeline bağlanmak birkaç yıl önce neredeyse bütün hikâyenin kendisiydi.

API anahtarını verirdin.

Prompt'u yazardın.

Model sana cevap verirdi.

Sonra sistemler büyüdü.

Modelin sadece konuşması yetmedi. GitHub'dan issue okuması, veritabanından müşteri bulması, dosya oluşturması, takvim kontrol etmesi, API çağırması, bir servise kayıt açması ve gerekiyorsa bütün bunları birkaç adım halinde arka arkaya gerçekleştirmesi gerekti.

İşte o noktada başka bir problem ortaya çıktı:

Yapay zekâ çok şey biliyor ama hiçbir yere bağlı değil.

Bir modele "GitHub'daki son issue'lara bak" demek, modelin gerçekten GitHub'a erişebildiği anlamına gelmiyor.

"Veritabanındaki son 10 müşteriyi getir" demek de modelin PostgreSQL'e sihirli bir tünel açtığı anlamına gelmiyor.

Her entegrasyon için ayrı kod yazmak mümkün.

Ama 20 farklı araç, 10 farklı model ve onlarca ajan olduğunda bu yaklaşım kısa sürede entegrasyon çöplüğüne dönüşüyor.

2024'ün sonunda ortaya çıkan Model Context Protocol, tam olarak bu probleme standart bir katman eklemeyi amaçladı. 2026'ya geldiğimizde ise MCP artık yalnızca "LLM'e birkaç tool bağlama" fikrinden çok daha geniş bir mimariye dönüşmüş durumda. Özellikle 28 Temmuz 2026 tarihli MCP spesifikasyonu; stateless çalışma, daha güçlü yetkilendirme, uzun süren görevler, MCP Apps ve ölçeklenebilir uzak sunucular gibi konuları doğrudan protokolün geleceğinin bir parçası haline getirdi.

Bu yazıda MCP'nin ne olduğunu anlatırken biraz daha ileri gideceğiz.

Asıl soru şu:

Bir LLM'i nasıl gerçekten çalışan bir ajana dönüştürürüz?

Ve daha da önemlisi:

Bunu kendi bilgisayarımızda çalışan bir modelle de yapabilir miyiz?

1. Önce problemi anlayalım#

Bir LLM'in dünyasını basitleştirirsek yaklaşık olarak şöyle düşünebiliriz:

Kullanıcı
   ↓
Prompt
   ↓
LLM
   ↓
Cevap

Bu mimaride modelin yaptığı şey oldukça nettir:

Girdiyi alır, çıktı üretir.

Ama gerçek hayattaki yazılımlarda kullanıcı senden sadece cevap istemez.

Örneğin şöyle bir komut düşünelim:

"GitHub'daki açık issue'ları kontrol et, kritik olanları bul, bunları özetle ve bana Slack'ten gönder."

Burada artık tek bir cevap yok.

Modelin:

1. GitHub'a erişmesi,
2. Issue'ları çekmesi,
3. Verileri analiz etmesi,
4. Kritik olanları belirlemesi,
5. Slack'e bağlanması,
6. Mesaj göndermesi

gerekir.

Dolayısıyla mimari şu hale gelir:

                 ┌──────────────┐
                 │     LLM      │
                 └──────┬───────┘
                        │
                  "Ne yapmalıyım?"
                        │
                 ┌──────▼───────┐
                 │    Agent     │
                 └──────┬───────┘
                        │
            ┌───────────┼───────────┐
            │           │           │
            ▼           ▼           ▼
         GitHub       Slack      Database

Burada ortaya çıkan kavram agent.

Bir agent, yalnızca cevap üreten model değildir.

Modeli;

• araçlarla,
• veri kaynaklarıyla,
• hafızayla,
• dış servislerle,
• görev mantığıyla

birlikte kullanarak belirli hedeflere ulaşmaya çalışan bir sistem haline getirir.

MCP ise bu sistemin araç ve veri tarafındaki bağlantı problemini standartlaştırır.

2. MCP tam olarak nedir?#

Model Context Protocol, yapay zekâ uygulamalarının veri ve araçların bulunduğu sistemlerle standart bir şekilde iletişim kurmasını sağlayan açık bir protokoldür. Anthropic, MCP'yi AI uygulamaları için bir tür USB-C olarak tanımlıyor: nasıl USB-C farklı cihazları ortak bir bağlantı üzerinden birbirine bağlayabiliyorsa, MCP de AI uygulamalarını farklı veri kaynakları ve araçlara bağlamayı hedefliyor.

Bu benzetme aslında oldukça güzel.

Eskiden bir cihaz için:

Model → GitHub entegrasyonu
Model → Slack entegrasyonu
Model → PostgreSQL entegrasyonu
Model → Google Drive entegrasyonu

gibi ayrı ayrı bağlantılar yazabilirdin.

MCP ile düşünce şu:

                   MCP
                    │
        ┌───────────┼───────────┐
        │           │           │
     GitHub       Slack      PostgreSQL
        │           │           │
      MCP          MCP          MCP
     Server       Server       Server

Modelin kendisine her sistemin özel API'sini öğretmek yerine araya ortak bir protokol koyuyorsun.

Bu küçük gibi görünen değişiklik, agent mimarisinde ciddi bir fark yaratıyor.

Çünkü artık model ile araç arasında doğrudan ve özel bir ilişki kurmak zorunda değilsin.

3. MCP mimarisinin üç temel parçası#

MCP'yi anlamanın en kolay yolu üç kavramı ayırmak:

Host#

Kullanıcının AI uygulamasıdır.

Örneğin:

• Claude Desktop
• Claude Code
• VS Code
• Cursor
• kendi yazdığın agent uygulaması

Host, modelin çalıştığı ve MCP bağlantılarının yönetildiği ana uygulamadır.

Client#

Host içerisindeki MCP konuşan bileşendir.

Client'ın görevi MCP server'larla iletişim kurmaktır.

Server#

Asıl araçları ve verileri sunan taraftır.

Örneğin:

GitHub MCP Server
PostgreSQL MCP Server
Filesystem MCP Server
Notion MCP Server
Slack MCP Server

Her MCP server belirli yetenekler sunabilir.

Basit bir mimari:

┌─────────────────────────────────────┐
│               HOST                  │
│                                     │
│  ┌───────────────┐                  │
│  │      LLM      │                  │
│  └───────┬───────┘                  │
│          │                          │
│  ┌───────▼───────┐                  │
│  │  MCP Client   │                  │
│  └───────┬───────┘                  │
└──────────┼──────────────────────────┘
           │
           │ MCP
           │
     ┌─────▼─────┐
     │ MCP Server│
     └─────┬─────┘
           │
    ┌──────┼────────┐
    │      │        │
    ▼      ▼        ▼
 Database GitHub   API

Bu ayrım özellikle büyük sistemlerde önem kazanıyor.

Çünkü modelin hangi veritabanını kullandığını bilmek zorunda olmaması mümkün.

Model sadece şunu bilir:

get_customer

veya

search_issues

veya

create_invoice

gibi bir araç mevcut.

Gerisini MCP server halleder.

4. Peki MCP Server ne sunuyor?#

MCP'nin temel yapı taşlarını üç kategoride düşünebiliriz:

Tools#

Model tarafından çağrılabilen fonksiyonlardır.

Örneğin:

search_customer()
create_invoice()
send_email()
get_weather()
create_github_issue()

Bunlar aktif eylemlerdir.

Model:

"Bu müşterinin siparişlerini getir."

dediğinde uygun tool'u çağırabilir.

Resources#

Modele sağlanan veri veya bağlamdır.

Örneğin:

file://project/readme.md
db://customer/123
docs://company/security-policy

Resources daha çok "bilgi sağlama" tarafındadır.

Prompts#

Önceden tanımlanmış prompt şablonlarıdır.

Örneğin:

review-code
summarize-document
analyze-security-log

Burada önemli bir ayrıntı var:

Tools model tarafından kontrol edilirken, prompts kullanıcı tarafından seçilen akışlara daha yakındır. Resources ise uygulamanın modele sağlayabileceği bağlamı temsil eder. MCP dokümantasyonu bu üç primitive'i özellikle ayrı kontrol modelleriyle tanımlıyor.

Bu ayrım ilk bakışta teorik gelebilir.

Ama agent tasarlarken oldukça değerlidir.

5. İlk MCP Server'ımızı yazalım#

2026 itibarıyla resmi Python SDK'nın v2 sürümü, 28 Temmuz 2026 MCP spesifikasyonunu temel alan kararlı sürüm hattı olarak konumlanıyor. SDK'nın güzel tarafı, protokolün büyük bölümünü senin yerine yönetmesi.

Basit bir MCP server:

from mcp.server import MCPServer

mcp = MCPServer("demo")


@mcp.tool()
def add(a: int, b: int) -> int:
    """Add two numbers."""
    return a + b

Hepsi bu.

Burada ayrı bir JSON Schema yazmadık.

Ayrı bir HTTP handler yazmadık.

Tool çağrılarını elle parse etmedik.

Protokol mesajlarını kendimiz oluşturmadık.

SDK, Python type hint'lerinden ve docstring'den tool'un şemasını oluşturabiliyor. Resmî SDK örneği de aynı yaklaşımı kullanıyor.

Örneğin:

def add(a: int, b: int) -> int:

ifadesinden modelin görebileceği kabaca şöyle bir yapı çıkıyor:

{
  "name": "add",
  "description": "Add two numbers.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "a": {
        "type": "integer"
      },
      "b": {
        "type": "integer"
      }
    },
    "required": ["a", "b"]
  }
}

Buradaki kritik fikir şu:

Model fonksiyonun kaynak kodunu değil, o fonksiyonun yetenek tanımını görür.

Böylece model "hangi araç ne işe yarıyor?" sorusuna standart bir cevap alabilir.

6. Asıl sihir: Tool calling#

Şimdi bir kullanıcı şöyle desin:

"105 numaralı müşterinin son siparişini getir."

Modelin zihninde buna benzer bir süreç oluşabilir:

Kullanıcı isteği
       ↓
Model
       ↓
"Bu bilgiyi kendim bilmiyorum."
       ↓
get_customer_order tool'u uygun
       ↓
MCP Client
       ↓
MCP Server
       ↓
Database
       ↓
Sonuç
       ↓
Model
       ↓
Kullanıcıya cevap

Örneğin MCP server:

@mcp.tool()
def get_order(order_id: str) -> dict:
    order = database.get_order(order_id)

    return {
        "order_id": order.id,
        "status": order.status,
        "total": order.total
    }

Model doğrudan PostgreSQL konuşmak zorunda değildir.

SQL yazmak zorunda değildir.

Database credentials bilmek zorunda değildir.

Model yalnızca:

get_order(order_id="105")

gibi bir araç çağrısı üretir.

Bu çağrıyı gerçek sisteme dönüştüren taraf MCP server'dır.

7. Burada küçük ama önemli bir ayrım var#

MCP bir LLM değildir.

MCP bir agent framework'ü de değildir.

MCP bir workflow engine değildir.

MCP'nin temel görevi:

AI uygulaması ile veri/araç sistemleri arasındaki iletişimi standartlaştırmaktır.

Bu ayrımı kaçırmamak önemli.

Örneğin:

Claude
Gemini
Qwen
Llama
GPT

bunlar modellerdir.

MCP

ise bağlantı protokolüdür.

Şuna benzetebiliriz:

LLM        → Beyin
Agent      → Karar ve görev döngüsü
MCP        → Ortak bağlantı protokolü
Tool       → El
Database   → Hafıza / bilgi kaynağı
API        → Dış dünya

Tek başına beyin yeterli değil.

Tek başına eller de yeterli değil.

İşin ilginçleştiği nokta bu bileşenlerin birlikte çalışması.

8. 2026 neden MCP açısından farklı?#

MCP 2024'te duyuruldu.

Ancak 2026'da önemli olan şey yalnızca kullanımının artması değil.

Protokolün kendisi de olgunlaşıyor.

MCP'nin 2026 yol haritasında özellikle:

• transport ölçeklenebilirliği,
• agent iletişimi,
• yönetişim,
• enterprise ihtiyaçları

öne çıkarıldı. 28 Temmuz 2026 spesifikasyonu ise stateless protokol çekirdeği, Tasks, MCP Apps, authorization geliştirmeleri ve resmi deprecation mekanizması gibi özellikleri beraberinde getirdi.

Bu değişiklikler aslında MCP'nin deneysel bir oyuncak olmaktan çıkıp daha ciddi altyapı problemlerine yöneldiğini gösteriyor.

Örneğin eski sistemlerde bağlantı durumunu taşıyan session modeli önemliydi.

2026-07-28 spesifikasyonu ise protokol seviyesinde session yaklaşımını kaldırarak daha stateless bir mimariye yöneldi.

Bunun sonucunda remote MCP server'lar normal HTTP altyapılarının arkasında daha rahat ölçeklenebilecek şekilde tasarlanabiliyor.

Bu küçük bir detay gibi duruyor.

Aslında production sistemleri için hiç küçük değil.

9. Local LLM + MCP#

Şimdi işin benim en sevdiğim kısmına gelelim.

MCP kullanmak için illa Claude veya Gemini gibi cloud modellerine mecbur değilsin.

Bilgisayarında bir LLM çalıştırabilirsin.

Örneğin:

Ollama
LM Studio

gibi araçlar üzerinden local model çalıştırıp agent benzeri sistemler oluşturabilirsin.

Bu noktada çok önemli bir ayrım var:

Modelin local olması, bütün sistemin local olması anlamına gelmez.

Örneğin:

                   MacBook
              ┌─────────────────┐
              │ Local LLM        │
              │ Qwen / Llama     │
              │       ↓          │
              │   MCP Client     │
              └────────┬────────┘
                       │
                 Streamable HTTP
                       │
             ┌─────────▼─────────┐
             │ Remote MCP Server │
             └─────────┬─────────┘
                       │
                 GitHub / API

Model bilgisayarında çalışıyor olabilir.

Ama MCP server internette olabilir.

Tam tersine:

Local LLM
   ↓
Local MCP
   ↓
Local PostgreSQL
   ↓
Local Filesystem

şeklinde tamamen offline veya büyük ölçüde lokal bir sistem de kurabilirsin.

İşte local agent dünyasının asıl güzelliği burada başlıyor.

10. Ollama ile local agent fikri#

Ollama tarafında tool calling ve MCP desteği özellikle agent kullanım senaryoları açısından gelişti. Ollama'nın 2025'te yayımladığı MCP/tool streaming yaklaşımı, modelin MCP araç çağrılarını stream ederek kullanabilmesini sağladı. 2026 içinde ise Ollama'nın ekosistemi local modelleri coding agent'larla kullanmaya yönelik daha kapsamlı hale geldi.

Örneğin bilgisayarında bir local model çalıştırdığını düşün:

qwen3-coder

ve senin üç MCP server'ın olsun:

filesystem
github
postgres

Artık modele:

"Projede authentication ile ilgili açık bir bug var mı? Kodları incele, ilgili issue'ları bul ve gerekiyorsa düzeltme önerisini hazırla."

dediğinde sistem teorik olarak şu yolu izleyebilir:

User
 ↓
Local LLM
 ↓
Agent loop
 ↓
Filesystem MCP
 ↓
GitHub MCP
 ↓
Local repository
 ↓
Analysis
 ↓
Result

Buradaki en önemli değişim:

LLM artık sadece konuşan bir arayüz olmaktan çıkıyor.

Bilgisayarının üzerinde çalışan bir işçi haline geliyor.

11. LM Studio tarafında durum#

LM Studio da MCP'yi doğrudan destekleyen local AI uygulamalarından biri.

Güncel dokümantasyona göre LM Studio hem local hem remote MCP server'ları bağlayabiliyor. Ayrıca API üzerinden MCP kullanımını da destekliyor; böylece MCP bağlantısını sadece masaüstü arayüzünde değil, kendi uygulamanın içinden de kullanabiliyorsun.

Örneğin mimarin:

                    ┌──────────────┐
                    │  LM Studio   │
                    │              │
                    │   Local LLM  │
                    └──────┬───────┘
                           │
                      MCP Client
                           │
            ┌──────────────┼──────────────┐
            │              │              │
            ▼              ▼              ▼
        Notion          Linear         Sentry
         MCP              MCP            MCP

olabilir.

Bu noktada MCP'nin neden değerli olduğu daha net görülüyor.

Model değişebilir.

Modelin çalıştığı uygulama değişebilir.

Fakat araç katmanı aynı kalabilir.

Örneğin:

LLM 1 → GitHub MCP
LLM 2 → GitHub MCP
LLM 3 → GitHub MCP

Aynı GitHub yeteneklerini farklı modeller kullanabilir.

Bu da bizi önemli bir mimari prensibe götürüyor:

Model ile araçları mümkün olduğunca birbirinden bağımsız tasarlamak.

12. Claude ve Gemini ile Remote MCP#

MCP'nin değerli hale geldiği bir diğer alan da cloud modeller.

Anthropic tarafında MCP, Claude ekosisteminin farklı bölümlerine entegre edilmiş durumda; resmi dokümantasyon MCP'yi Claude Code, Claude Desktop, Claude.ai ve Messages API tarafında desteklenen bir bağlantı modeli olarak gösteriyor.

Google tarafında ise Gemini Interactions API, remote MCP server'lara doğrudan bağlanabiliyor.

Örneğin konsept olarak:

const interaction = await client.interactions.create({
  model: "gemini-3.8-flash",
  input: "GitHub'daki açık issue'ları kontrol et.",
  tools: [
    {
      type: "mcp_server",
      name: "github",
      url: "https://example.com/mcp"
    }
  ]
});

şeklindeki yapı ile modelin dış bir MCP server'ın sunduğu araçlara erişmesi mümkün.

Google'ın güncel dokümantasyonuna göre Remote MCP bağlantısı Streamable HTTP sunucularıyla çalışıyor ve allowed_tools ile modelin erişebileceği araçlar sınırlandırılabiliyor.

Bu oldukça önemli.

Çünkü artık şöyle düşünebiliriz:

              ┌──────────────┐
              │ Claude       │
              └──────┬───────┘
                     │
                     │
                     ▼
                 GitHub MCP
                     ▲
                     │
                     │
              ┌──────┴───────┐
              │    Gemini    │
              └──────────────┘

Aynı MCP server farklı AI istemcileri tarafından kullanılabilir.

Bu da MCP'nin asıl gücünü gösteriyor:

Modelin kendisini değil, modelin bağlanabildiği dünyayı standartlaştırmak.

13. Agent tam olarak nerede devreye giriyor?#

Şimdi MCP'yi agent ile birleştirelim.

Kullanıcının istediği şey:

"Bu haftaki satışları analiz et, geçen haftayla karşılaştır ve önemli bir düşüş varsa bana bildir."

Modelin tek cevap üretmesi yeterli olmayabilir.

Agent loop kabaca şöyle çalışabilir:

1. Kullanıcı isteğini al
             ↓
2. Hedefi analiz et
             ↓
3. Kullanılabilecek araçları keşfet
             ↓
4. Gerekli tool'u seç
             ↓
5. Tool'u çağır
             ↓
6. Sonucu değerlendir
             ↓
7. Gerekirse başka tool çağır
             ↓
8. Görevin tamamlanıp tamamlanmadığını kontrol et
             ↓
9. Sonucu kullanıcıya sun

Örneğin:

get_sales(this_week)
        ↓
get_sales(last_week)
        ↓
compare_sales()
        ↓
detect_anomalies()
        ↓
send_notification()

İşin güzel tarafı şu:

Agent'ın bütün bu adımları önceden hard-code edilmek zorunda değil.

Daha gelişmiş sistemlerde model, hedefe ulaşmak için gerekli araçları seçebilir.

Buna kabaca agentic tool use diyebiliriz.

14. Ama burada büyük bir problem var#

Bir modele araç vermek otomatik olarak güvenli bir agent oluşturmaz.

Hatta tam tersine.

Modelin:

database.write()
delete_file()
send_email()
issue_refund()
deploy_production()

gibi araçlara erişimi varsa işler ciddi hale gelir.

Çünkü artık model sadece bilgi üretmiyor.

Eylem gerçekleştiriyor.

Bu yüzden MCP kullanırken en önemli konulardan biri:

Yetki sınırları#

Örneğin bir agent'a:

database.read

verebilirsin.

Ama:

database.delete

vermek istemeyebilirsin.

Ya da:

github.issue.read
github.issue.create

izin verip:

github.repository.delete

gibi bir yetkiyi tamamen kapatabilirsin.

Google'ın güncel Remote MCP entegrasyonlarında allowed_tools desteğinin bulunması da tam olarak bu tip sınırlandırmaların önemini gösteriyor.

Agent tasarımında temel prensiplerden biri şu olmalı:

Modelin yapabileceği şeyleri mümkün olan en dar yetki setiyle sınırla.

15. MCP server'a neden "akıllı API" gibi bakıyorum?#

REST API ile MCP arasında güzel bir benzerlik var.

Klasik API'de:

GET /customers/123
POST /orders
DELETE /files

gibi endpoint'ler bulunur.

MCP'de bunun yerine modelin kullanabileceği yetenekler tanımlarsın:

get_customer
create_order
delete_file

Ama burada kritik fark şu:

REST API:

"İstemci bu endpoint'e nasıl istek atacağını bilmelidir."

MCP:

"AI uygulaması bu yeteneği makinenin anlayabileceği bir araç tanımı üzerinden keşfedebilir."

Bu nedenle MCP server'ı bir anlamda:

LLM-friendly API

olarak düşünmek faydalı.

Ama yalnızca "API'nin başka bir çeşidi" demek de eksik kalır.

Çünkü MCP;

• tools,
• resources,
• prompts,
• capability discovery,
• authorization,
• transport

gibi AI uygulamalarının ihtiyaç duyduğu daha geniş bir iletişim katmanı tanımlar.

16. MCP ile neler yapılabilir?#

Burada hayal gücü gerçekten biraz kontrolden çıkabiliyor.

Mesela kendi bilgisayarında şöyle bir agent oluşturduğunu düşün:

Local Developer Agent

Bu agent'ın şu MCP server'ları var:

Filesystem
GitHub
PostgreSQL
Browser
Sentry
Slack

Kullanıcı:

"Son deploy'dan sonra hata oranı artmış. Problemi bul."

diyor.

Agent:

Sentry
 ↓
Hataları bul

GitHub
 ↓
Son commit'leri bul

Filesystem
 ↓
Kod değişikliklerini incele

PostgreSQL
 ↓
İlgili datayı kontrol et

GitHub
 ↓
Bug issue oluştur

Slack
 ↓
Ekibe rapor gönder

Bütün bunların sonunda kullanıcıya:

"Problemin son authentication değişikliğinden kaynaklandığını düşünüyorum. İlgili issue'yu oluşturdum ve Slack kanalına rapor gönderdim."

diyebilir.

Burada model artık chatbot gibi davranmıyor.

Bir görev orkestratörü gibi davranıyor.

17. Asıl büyük fikir: Model değişir, araçlar kalır#

Bence MCP'nin uzun vadede en ilginç taraflarından biri bu.

Bugün:

Claude

kullanabilirsin.

Yarın:

Gemini

kullanabilirsin.

Öbür gün:

Qwen
Llama
GPT

kullanabilirsin.

Hatta:

Local LLM

çalıştırabilirsin.

Eğer agent katmanını ve MCP server'larını temiz ayırdıysan, sistemin geri kalanının büyük bölümünü yeniden yazman gerekmeyebilir.

Kabaca:

             ┌────────────┐
             │   Model    │
             └─────┬──────┘
                   │
                   ▼
             ┌────────────┐
             │   Agent    │
             └─────┬──────┘
                   │
                   ▼
             ┌────────────┐
             │ MCP Client │
             └─────┬──────┘
                   │
       ┌───────────┼───────────┐
       ▼           ▼           ▼
    GitHub      Database     Slack
      MCP          MCP         MCP

Bu ayrım software architecture açısından oldukça temiz bir yaklaşım.

Model bir dependency.

Tool layer başka bir dependency.

Aralarında ortak bir protokol var.

18. 2026'da MCP'nin yöneldiği yer#

MCP'nin 2026 spesifikasyonunda yalnızca "tool çağırma" tarafına değil, production ortamında ihtiyaç duyulan başka problemlere de daha fazla ağırlık veriliyor.

Örneğin:

Stateless çalışma#

Remote MCP server'ların klasik HTTP altyapılarıyla daha rahat ölçeklenebilmesi hedefleniyor.

Tasks#

Uzun süren işlerin protokol içerisinde daha doğal bir şekilde ele alınması amaçlanıyor.

Örneğin:

"Bu 5.000 müşteriyi analiz et."

gibi birkaç saniyeyi aşan işler.

MCP Apps#

MCP'nin yalnızca veri döndürmesi yerine arayüz bileşenleriyle de etkileşebilmesini sağlayan yaklaşım.

Yani modelin çağırdığı:

show_report()

gibi bir tool sadece JSON döndürmek yerine kullanıcıya etkileşimli bir UI gösterebilir.

MCP Apps mimarisi, tool metadata'sı üzerinden UI kaynaklarının bağlanması ve host tarafında sandbox edilmiş bir iframe içinde çalıştırılması yaklaşımını kullanıyor.

Daha ciddi authorization#

MCP'nin enterprise kullanımına yaklaşmasıyla authentication ve authorization konusu daha merkezi hale geliyor. 2026 spesifikasyonu OAuth/OIDC tabanlı sistemlerle daha uyumlu bir güvenlik modeli üzerinde ilerliyor.

Bunların hepsi aynı yere çıkıyor:

MCP artık sadece "AI'ya tool verelim" seviyesinde kalmak istemiyor.

Daha ölçeklenebilir, daha güvenli ve daha üretim odaklı bir agent altyapısı olmaya çalışıyor.

19. Peki gerçekten otonom ajanlar mümkün mü?#

"Evet" demek kolay.

Ama burada biraz dikkatli olmak gerekiyor.

Bir modelin tool çağırabilmesi onu otomatik olarak iyi bir agent yapmaz.

Agent'ın gerçekten işe yarayabilmesi için:

Model capability
+
Tool quality
+
Context quality
+
Permission design
+
Error handling
+
Observability
+
Good agent loop

birlikte çalışmalı.

Örneğin model çok iyi olabilir.

Ama tool description kötüyse yanlış tool seçebilir.

Tool doğru olabilir.

Ama modelin verdiği context eksikse yanlış parametre gönderebilir.

Hepsi doğru olabilir.

Ama agent'ın:

max_steps = 50

gibi bir sınırı yoksa model bir noktada gereksiz yere dönüp durabilir.

Bu yüzden üretim ortamında agent mimarisi sadece model seçmekten çok daha büyük bir problemdir.

20. İyi bir MCP Server nasıl yazılır?#

Bence en kritik noktalardan biri burası.

MCP server'a şu gözüyle bakmak gerekiyor:

"Model bunu nasıl kullanacak?"

İnsan için anlaşılır olan bir fonksiyon ismi model için yeterince iyi olmayabilir.

Örneğin:

@mcp.tool()
def process_data(data):
    ...

pek iyi bir tool değildir.

Model:

"process_data ne yapıyor?"

diye kalır.

Bunun yerine:

@mcp.tool()
def search_customers(
    query: str,
    limit: int = 10
):
    """Search customers by name, email or phone number."""
    ...

çok daha nettir.

Tool description'ları agent performansında önemli hale gelir çünkü modelin elindeki araçlar bir çeşit çalışma yüzeyi oluşturur.

MCP'nin resmi dokümantasyonunda da tool açıklamalarının ve server instructions gibi mekanizmaların modelin araçları doğru kullanmasında önemli olduğu özellikle vurgulanıyor.

Dolayısıyla:

Bad tool:
do_task()

Good tool:
search_customers()

Better tool:
search_customers_by_name_or_email()

gibi düşünmek gerekiyor.

21. MCP'nin zayıf tarafları da var#

Her teknoloji gibi MCP de sihirli bir değnek değil.

En önemli risklerden biri fazla araç.

Agent'ın önüne 100 farklı tool koyarsan:

tool_1
tool_2
tool_3
...
tool_100

modelin hangi aracı ne zaman kullanacağı daha karmaşık hale gelebilir.

Üstelik tool tanımlarının tamamı context'e dahil ediliyorsa token tüketimi de büyüyebilir.

LM Studio'nun güncel MCP dokümantasyonunda da fazla sayıda veya ağır tanımlı MCP server'ın local modellerde context overflow ve token tüketimi gibi sorunlar yaratabileceğine dikkat çekiliyor.

Bu yüzden:

Daha fazla tool ≠ daha iyi agent

Bazen daha az ama çok iyi tasarlanmış tool çok daha iyi sonuç verir.

22. Güvenlik tarafını sakın hafife almayın#

Bir MCP server'a erişim veriyorsan aslında modele dolaylı olarak sistem erişimi vermiş olabilirsin.

Örneğin filesystem MCP server:

read_file
write_file
delete_file

gibi yeteneklere sahipse modelin potansiyel olarak dosya sistemi üzerinde ciddi etkisi olabilir.

Remote MCP server'larda da aynı şekilde:

API key
OAuth token
database credentials
user data
internal APIs

gibi hassas kaynaklar söz konusu olabilir.

LM Studio'nun kendi dokümantasyonu bile MCP server'ların yerel dosyalara erişebileceği, ağ bağlantıları kullanabileceği ve keyfi kod çalıştırabilecekleri konusunda açık şekilde uyarıyor.

Dolayısıyla MCP kullanırken:

Least privilege
+
Authentication
+
Authorization
+
Audit logs
+
Tool allowlist
+
Sandboxing

gibi kavramlar artık "enterprise jargon" olmaktan çıkıyor.

Agent gerçekten bir şeyler yapabiliyorsa, güvenlik gerçek bir uygulama problemidir.

23. Ben olsam nasıl bir mimari kurardım?#

Bugün sıfırdan bir agent sistemi kuruyor olsaydım muhtemelen şöyle bir yapı düşünürdüm:

                         USER
                           │
                           ▼
                    ┌─────────────┐
                    │   Agent     │
                    │   Runtime   │
                    └──────┬──────┘
                           │
                    ┌──────▼──────┐
                    │ MCP Client  │
                    └──────┬──────┘
                           │
       ┌───────────────────┼───────────────────┐
       │                   │                   │
       ▼                   ▼                   ▼
  GitHub MCP          PostgreSQL MCP       Browser MCP
       │                   │                   │
       ▼                   ▼                   ▼
   GitHub API          Database             Web

Üst tarafta model değiştirilebilir:

Claude
Gemini
Local Qwen
Local Llama

Agent runtime aynı kalabilir.

MCP client aynı kalabilir.

Tool layer aynı kalabilir.

Bu sayede AI modelini sistemin tamamına gömmek yerine modelden bağımsız bir mimari elde edebilirsin.

24. En ilginç senaryo: Local + Cloud hibrit agent#

Bence gelecekte çok daha sık göreceğimiz yapılardan biri bu.

Örneğin:

                 ┌────────────────┐
                 │ Local LLM      │
                 │ Qwen / Llama   │
                 └───────┬────────┘
                         │
                  sensitive work
                         │
                ┌────────▼────────┐
                │ Local MCP       │
                │ Database        │
                │ Files           │
                └─────────────────┘


                 Cloud LLM
                    │
                    │ complex reasoning
                    ▼
                Remote MCP
                    │
          ┌─────────┼─────────┐
          ▼         ▼         ▼
       GitHub     Search    External API

Burada hassas veriler local kalabilir.

Daha ağır reasoning isteyen iş cloud modele gönderilebilir.

Tool layer ise ortak MCP altyapısı üzerinden çalışabilir.

Bu, özellikle şirket içi agent sistemleri için oldukça ilginç bir mimari.

25. MCP bana göre neden önemli?#

MCP'nin bence en önemli tarafı "bir tool protokolü olması" değil.

Asıl önemli olan fikir şu:

AI uygulamalarını modellerden bağımsız bir dünyaya bağlamak.

Bugün AI alanındaki en hızlı değişen şeylerden biri model katmanı.

Birkaç ay içerisinde:

Model A

yerini:

Model B

ye bırakabiliyor.

Ama:

GitHub
PostgreSQL
Slack
Notion
Sentry
CRM
ERP
Filesystem

gibi sistemler ortadan kalkmıyor.

Bunlar gerçek dünyanın kendisi.

Dolayısıyla geleceğin AI mimarisinde belki de en değerli katman modelden ziyade:

Model ile gerçek dünya arasındaki interface

olabilir.

MCP bu interface'i standartlaştırmaya çalışıyor.

Sonuç#

Yapay zekânın ilk büyük aşaması:

"Model ne kadar iyi cevap verebiliyor?"

sorusuydu.

Sonra soru değişti:

"Model hangi araçları kullanabiliyor?"

Şimdi ise daha büyük bir soru var:

"Model kendi hedeflerine ulaşmak için farklı sistemleri nasıl orkestre edebiliyor?"

MCP bu hikâyenin tam ortasında duruyor.

Local LLM'ler sayesinde modelin kendisini bilgisayarında çalıştırabiliyorsun.

Ollama ve LM Studio gibi araçlarla local inference ve tool kullanımı gittikçe daha erişilebilir hale geliyor.

Claude ve Gemini gibi cloud modeller ise remote MCP server'larla dış dünyadaki araçlara erişebiliyor.

Sonuçta elimizde artık sadece:

Prompt → Response

yok.

Şuna doğru ilerleyen bir mimari var:

                    ┌───────────────┐
                    │     USER      │
                    └───────┬───────┘
                            │
                            ▼
                    ┌───────────────┐
                    │     AGENT     │
                    └───────┬───────┘
                            │
                            ▼
                    ┌───────────────┐
                    │      LLM      │
                    └───────┬───────┘
                            │
                       MCP Client
                            │
          ┌─────────────────┼──────────────────┐
          │                 │                  │
          ▼                 ▼                  ▼
     GitHub MCP        Database MCP       Browser MCP
          │                 │                  │
          ▼                 ▼                  ▼
       GitHub           PostgreSQL            Web

Ve bence asıl heyecan verici olan kısım burada başlıyor.

Çünkü bir modelin cevap vermesi artık başlı başına ilginç değil.

Asıl soru:

"Ona ne yaptırabiliriz?"

MCP'nin hikâyesi de tam olarak burada başlıyor.

Kaynak notları#

Bu yazı hazırlanırken özellikle aşağıdaki güncel teknik kaynaklar temel alınmıştır:

• Model Context Protocol — 2026-07-28 Specification
• Model Context Protocol — 2026 Roadmap
• MCP TypeScript SDK v2
• MCP Python SDK v2
• Anthropic — Model Context Protocol
• Google Gemini API — Remote MCP
• LM Studio — MCP Documentation
• Ollama — MCP / Tool Calling Documentation

Not: MCP ve ilgili SDK'lar aktif olarak gelişen teknolojiler. Özellikle API örnekleri, SDK import yolları ve spesifikasyon ayrıntıları zaman içinde değişebilir. Üretim kodunda kullanılan sürümün kendi dokümantasyonu kontrol edilmelidir.