← notlar · 2026-10-08 · 5 dk okuma · ai · agents · web

WebMCP: siteler artık yapay zeka ajanlarına da arayüz sunuyor

Google ve Microsoft'un önerdiği WebMCP, bir sitenin kendi işlevlerini tarayıcıdaki ajanlara araç olarak açmasını sağlıyor. Ne olduğu, nasıl kurulduğu, Ekim 2026 itibarıyla nerede durduğu ve neden şimdiden ilgilenmeye değer olduğu.

Bugün bir yapay zeka ajanı bir sitede uçuş aradığında ne yapıyor? Sayfanın ekran görüntüsünü alıyor ya da DOM'u okuyor, "Kalkış" yazan kutuyu tahmin ediyor, tıklıyor, takvimin açılmasını bekliyor, yanlış güne basıyor, tekrar deniyor. İnsan için tasarlanmış arayüzü taklit ediyor. Yavaş, pahalı ve kırılgan; sitenin tasarımı değiştiği gün bozuluyor.

WebMCP bu soruna başka bir yerden bakıyor: ajan arayüzü tahmin etmesin, site ona ne yapabileceğini doğrudan söylesin.

WebMCP nedir

WebMCP (Web Model Context Protocol), bir web sayfasının kendi işlevlerini "araç" (tool) olarak tarayıcıdaki ajanlara açmasını sağlayan bir tarayıcı API'si önerisi. Site bir araç tanımlıyor: adı, ne işe yaradığını anlatan bir açıklama, JSON Schema ile tarif edilmiş girdiler ve çalıştırılacak fonksiyon. Ajan sayfaya geldiğinde bu listeyi görüyor ve butonları kurcalamak yerine doğrudan search_flights({ from, to, date }) çağırıyor.

İsmini Anthropic'in MCP'sinden alıyor ve aynı araç modelini kullanıyor, ama çalıştığı yer farklı. MCP'de ayrı bir sunucu kurarsın, kimlik doğrulamayı ayrıca çözersin. WebMCP'de araç sayfanın içinde, kullanıcının zaten açık olan oturumuyla çalışıyor: ayrı sunucu yok, ayrı OAuth akışı yok. Kullanıcı da ekranın başında; ajanın yaptığı her şey sekmede görünüyor.

Kısaca: MCP ajanı servislerine bağlar, WebMCP ajanı kullanıcının açık sekmesine bağlar.

Nereden çıktı, nerede duruyor

Ağustos 2025. Öneri Microsoft Edge ekibinden geldi, Google kısa süre sonra ortak yazar oldu. Fikrin öncülü Alex Nahas'ın açık kaynak projesi MCP-B.
Şubat 2026. W3C Web Machine Learning Community Group'ta ilk taslak rapor yayınlandı; editörler Microsoft ve Google'dan. Chrome 146'da bayrak arkasında ilk uygulama geldi.
Mayıs 2026, Google I/O. Chrome 149 ile origin trial başladı; site sahipleri bir token ile özelliği gerçek kullanıcılarda açabiliyor. Google, Gemini in Chrome'un WebMCP araçlarını kullanacağını duyurdu.
Haziran 2026. Edge 147'de bayrak arkasında deneysel destek.
Temmuz 2026. API navigator.modelContext'ten document.modelContext'e taşındı; araçlar tarayıcıya değil belgeye ait. Chrome 150 eski konumu kullanımdan kaldırıyor.
Ağustos 2026. Cloudflare, herhangi bir siteye tek ayarla WebMCP katmanı ekleyen bir geliştirici önizlemesi çıkardı.
Ekim 2026. İlk kurumsal duyurular geliyor. Orgvue, kullanıcının kendi ajanını açık çalışma sekmesine WebMCP üzerinden bağlamasını sunuyor.

Tabloyu dürüst çizmek gerekirse: WebMCP henüz bir W3C standardı değil, standart yoluna da girmiş değil; bir topluluk grubu taslağı. Firefox ve Safari tarafında uygulama taahhüdü yok. Sahada kullanım çok düşük ve Gemini in Chrome desteğinin genel kullanıma açıldığına dair bir duyuru henüz yok. Yine de Chrome ve Edge'in aynı taslak üzerinde birlikte çalışması, bunun bir laboratuvar fikri olmaktan çıktığını gösteriyor.

Nasıl yapılır

İki yol var.

1. Bildirimsel (declarative) API: mevcut formlar. Elinde zaten bir HTML form varsa, birkaç öznitelikle onu araca çevirebilirsin. Form aracın kimliği, alanlar da parametreleri oluyor:

<form toolname="search_flights"
      tooldescription="İki şehir arasında belirli bir tarih için uçuş arar."
      action="/search">
  <input name="from" required>
  <input name="to" required>
  <input name="date" type="date" required>
  <button type="submit">Ara</button>
</form>

Gönderimi ajanın yapıp yapmadığını submit olayındaki agentInvoked ile anlayabiliyor, sonucu respondWith() ile modele geri verebiliyorsun.

2. Emredici (imperative) API: JavaScript. Form yoksa ya da iş birden çok adımlıysa araç kodla tanımlanıyor:

const mc = document.modelContext ?? navigator.modelContext;

if (mc) {
  await mc.registerTool({
    name: "search_flights",
    description: "İki şehir arasında belirli bir tarih için uçuş arar.",
    inputSchema: {
      type: "object",
      properties: {
        from: { type: "string", description: "Kalkış havalimanı (IATA kodu)" },
        to: { type: "string", description: "Varış havalimanı (IATA kodu)" },
        date: { type: "string", format: "date" },
      },
      required: ["from", "to", "date"],
    },
    annotations: { readOnlyHint: true },
    execute: async ({ from, to, date }) => {
      const results = await searchFlights(from, to, date); // sitenin mevcut fonksiyonu
      return JSON.stringify(results);
    },
  });
}

Dikkat edilmesi gerekenler:

Özellik tespiti yap, site onsuz da çalışsın. API bir yıl içinde iki kez değişti; document.modelContext ?? navigator.modelContext geçiş döneminde ikisini de yakalar.
Annotation'lar bir güvenlik sözleşmesi. readOnlyHint aracın yalnızca okuduğunu söyler. consequentialHint geri dönüşü zor işler içindir: ödeme, rezervasyon, silme. untrustedContentHint çıktıda kullanıcı yorumu gibi dışarıdan gelen veri olduğunu işaretler ve ajanı prompt injection'a karşı uyarır.
Açıklamayı model için yaz. Aracın ne zaman kullanılacağını söyleyen kısa, net bir cümle ve parametreler için örnek format yeterli. Chrome'un önerdiği karakter sınırları da kısa tutmaya zorluyor.
Araç, arayüzün yapabildiğinden fazlasını yapmamalı. Ajan kullanıcının oturumuyla çalışıyor; araç arayüzde olmayan bir yetki açıyorsa bu bir güvenlik açığıdır.
Erişim varsayılan olarak aynı origin'le sınırlı. tools Permissions Policy cross-origin iframe'leri engelliyor, gerekiyorsa allow="tools" ile açılıyor. exposedTo ile aracı hangi origin'lerin göreceğini daraltabiliyorsun.

Denemek için Chrome'da chrome://flags/#enable-webmcp-testing bayrağını açmak yeterli. DevTools kayıtlı araçları ve JSON Schema'nın nasıl ayrıştırıldığını gösteriyor.

Neden şimdi ilgilenmeli

Geçen ay bu sitenin her sayfasına bir Markdown ikizi ve bir llms.txt ekledim (notu burada). O iş, sitenin yapay zeka motorları tarafından okunabilir olmasıyla ilgiliydi. WebMCP bir sonraki katman: sitenin ajanlar tarafından kullanılabilir olması.

Bir dönem "site mobil uyumlu mu" sorusu bir işin kaderini belirledi. Benzer bir soru geliyor: bir ajan bu sitede işini tamamlayabiliyor mu? Ekranı okuyarak ilerleyen ajan yavaş ve hataya açık, araç çağıran ajan hızlı ve öngörülebilir. Ajanlar kullanıcı adına seçim yapmaya başladığında, işini kolay bitirebildikleri siteleri tercih edeceklerini tahmin etmek zor değil.

Benim beklentim şu: 2026'nın geri kalanı deneme dönemi olacak ve API birkaç kez daha değişecek. Asıl kırılma, Gemini in Chrome gibi milyonlarca kullanıcıya ulaşan bir ajan araçları gerçekten çağırmaya başladığında gelecek. O gün geldiğinde formlarını şimdiden etiketlemiş siteler hazır olacak.

Bugün atılabilecek en ucuz adım, en önemli bir iki formuna toolname ve tooldescription eklemek. Tarayıcı desteklemiyorsa hiçbir şey değişmez; desteklediği gün siten ajanlarla konuşmaya başlar.

Bu sitede

Yazıyı yazdıktan sonra aynısını bu siteye de uyguladım. WebMCP destekleyen bir tarayıcıda necatidogrul.dev artık beş araç sunuyor:

get_profile: kim olduğum, iletişim bilgileri ve bağlantılar
list_ios_apps: App Store'daki uygulamalarım
list_writing: notlar ve vaka çalışmaları, etikete göre filtrelenebilir
read_writing: bir yazının tam metni
go_to_section: sayfayı istenen bölüme kaydırır

Sitede form olmadığı için bildirimsel API yerine emredici API'yi kullandım. İlk dört araç readOnlyHint ile işaretli, yalnızca okuyorlar; beşincisi ekranda görünür bir değişiklik yapıyor ama geri alınamaz bir şey yapmıyor. Yeni bir backend yazmadım: araçlar tek bir istemci bileşeninde, sitede zaten olan verilerden besleniyor. Geçen ayki Markdown ikizleri de burada işe yaradı, read_writing doğrudan onları döndürüyor. Tarayıcı WebMCP desteklemiyorsa bileşen hiçbir şey yapmıyor.

Chrome 152'de test ettim: getTools() beş aracı listeliyor, executeTool() ile her biri beklenen yanıtı veriyor. Denemek istersen chrome://flags/#enable-webmcp-testing bayrağını aç, bu sayfada konsola await document.modelContext.getTools() yaz.