01Standart neden bu kadar hızlı tuttuWhy the standard caught on so fast
MCP'den önce tablo şuydu: her yapay zekâ uygulaması, bağlanmak istediği her servis için ayrı bir entegrasyon yazıyordu. On uygulama, on servis — yüz ayrı entegrasyon. MCP bu N×M problemini N+M'e indirir: servis bir kez MCP server olarak açılır, uygulama bir kez MCP client'ı konuşur ve ikisi ortada standart bir sözleşmede buluşur.
Before MCP the picture was this: every AI application wrote a separate integration for every service it wanted to reach. Ten apps, ten services — a hundred integrations. MCP collapses that N×M problem into N+M: a service is exposed once as an MCP server, an app speaks the MCP client side once, and the two meet in the middle on a standard contract.
Protokol 2024 sonunda Anthropic tarafından açık kaynak olarak yayımlandı; kısa sürede büyük model sağlayıcıları, IDE'ler ve ajan framework'leri tarafından benimsendi. Hızın sırrı da basit: kimse yüz entegrasyon bakımını sevmez ve mesaj formatı zaten tanıdık — altında JSON-RPC var. Topluluğun benzetmesi yerinde: MCP, yapay zekâ uygulamaları için USB-C gibi — cihaza değil, standarda entegre olursunuz.
Anthropic published the protocol as open source in late 2024; within months it was adopted by the major model providers, IDEs and agent frameworks. The secret to that speed is simple: nobody enjoys maintaining a hundred integrations, and the wire format is already familiar — it's JSON-RPC underneath. The community's analogy holds: MCP is USB-C for AI applications — you integrate against the standard, not the device.
MCP bir framework değil, bir sözleşme: bir kez açarsınız, herkes bağlanır.
MCP isn't a framework; it's a contract: expose once, everyone connects.
02Mimari: server, client, iki transportThe architecture: server, client, two transports
Roller nettir. Server, yeteneklerinizi açan taraftır; client, o yetenekleri kullanan yapay zekâ uygulamasıdır — bir IDE asistanı, bir chat uygulaması, bir ajan. Bağlantı kurulurken taraflar yeteneklerini karşılıklı bildirir. Server üç şey sunar:
The roles are clean. A server is the side exposing your capabilities; a client is the AI application using them — an IDE assistant, a chat app, an agent. On connection the two sides negotiate what each supports. A server offers three things:
- Tool'lar. Modelin çağırabildiği eylemler: sipariş ara, kayıt oluştur, sorgu çalıştır. Ad, açıklama ve girdi şemasıyla tanımlanır.
- Tools. Actions the model can invoke: search an order, create a record, run a query. Defined by a name, a description and an input schema.
- Resource'lar. Modelin okuyabileceği veri: dosyalar, kayıtlar, dokümanlar. Eylem değil, bağlam.
- Resources. Data the model can read: files, records, documents. Not actions — context.
- Prompt'lar. Server'ın beraberinde getirdiği hazır şablonlar; kullanıcı isterse devreye girer.
- Prompts. Reusable templates the server ships with, invoked when the user asks for them.
Transport tarafında iki pratik seçenek var: aynı makinede çalışan server'lar için stdio, uzaktaki servisler için HTTP. Server kodu aynı kalır; değişen yalnızca mesajların taşındığı kanal.
On the transport side there are two practical options: stdio for servers running on the same machine, HTTP for remote services. The server code stays the same; only the channel carrying the messages changes.
03Küçük bir MCP server yazmakBuilding a small MCP server
İşin özü göründüğünden küçüktür. Resmî SDK'lardan birini alırsınız, mevcut servis mantığınızı birkaç tool olarak tanımlarsınız, transport'u seçersiniz, bir client ile keşif ve çağrıyı test edersiniz. Yeni bir backend yazmıyorsunuz; var olanın önüne ince bir kapı koyuyorsunuz.
The core of the work is smaller than it looks. You take one of the official SDKs, define your existing service logic as a few tools, pick a transport, and test discovery and calls with a client. You're not writing a new backend; you're putting a thin door in front of the one you have.
# tool tanımı / tool definition name: "search_orders" description: "Sipariş no veya e-posta ile arar / Finds orders by id or email" input: { query: string, limit?: number } # client tarafı / client side → tools/list # keşif / discovery → tools/call search_orders {"query":"#48211"} ← { "status": "shipped", "eta": "2026-07-04" }
En kritik satır, tool açıklamasıdır. Model hangi tool'u ne zaman çağıracağına o açıklamayı okuyarak karar verir; yani bu dokümantasyon değil, prompt mühendisliğidir. Az sayıda, kaba taneli, iyi anlatılmış tool; çok sayıda mikro-endpoint'ten her zaman daha iyi çalışır.
The most critical line is the tool description. The model decides which tool to call, and when, by reading it — so this is prompt engineering, not documentation. A few coarse-grained, well-described tools always beat a pile of micro-endpoints.
Pratikte iki şey daha gerekir. Birincisi test: server'ı gerçek bir client'a bağlamadan önce bir inspector aracıyla keşfi, şemaları ve hata yollarını elle gezin — modelin göreceği yüzey tam olarak budur. İkincisi sınırlar: her tool çağrısına zaman aşımı, sayfalama ve anlamlı hata mesajı koyun. Model, stack trace yerine "sonuç yok, tarih aralığını daraltın" cevabından çok daha iyi bir sonraki adım seçer.
In practice you need two more things. First, testing: before wiring the server to a real client, walk the discovery, schemas and error paths by hand with an inspector tool — that is exactly the surface the model will see. Second, limits: give every tool call a timeout, pagination and meaningful error messages. A model picks a far better next step from "no results, narrow the date range" than from a stack trace.
04Güvenlik gerçekleri — ve ne zaman uğraşmayınSecurity realities — and when not to bother
Her tool dış dünyaya açılan bir kapıdır ve kapının iki yönü vardır. Birincisi yetki: tool çağrıları kullanıcı onayına bağlanmalı, kimlik bilgileri en düşük yetkiyle (least privilege) verilmelidir — okumak yetiyorsa yazma izni yok. İkincisi daha sinsidir: prompt injection artık tool sonuçlarının içinden gelir. Server'ınızın döndürdüğü bir doküman, modelin bağlamına giren güvensiz girdidir; "içeriğe gömülü talimat" senaryosunu tasarımın istisnası değil, parçası sayın.
Every tool is a door to the outside world, and the door swings both ways. First, permissions: tool calls should require user consent, and credentials should follow least privilege — if read is enough, no write. The second is sneakier: prompt injection now arrives inside tool results. A document your server returns is untrusted input entering the model's context; treat "instructions embedded in content" as part of the design, not an exception to it.
Dürüst soru: her servis MCP server olmak zorunda mı? Hayır. Tek bir uygulamadan tek bir servise bağlanıyorsanız doğrudan fonksiyon çağrısı ya da iyi dokümante edilmiş bir REST API hâlâ en kısa yoldur. MCP, aynı yeteneği birden fazla client'a açacağınız anda değer üretir. Ajanlara açılan yüzey de tek biçimli olmak zorunda değil: biz naylalabs.com'da ajanların okuyabileceği bir /llms.txt ve yapılandırılmış bir teklif endpoint'i yayınlıyoruz — MCP'nin yanında tamamlayıcı bir yüzey olarak.
The honest question: does every service need to be an MCP server? No. If one application talks to one service, a direct function call or a well-documented REST API is still the shortest path. MCP pays off the moment the same capability needs to reach more than one client. And the agent-facing surface doesn't have to be one shape: at naylalabs.com we publish an agent-readable /llms.txt and a structured quote endpoint — a complementary surface alongside MCP.