MCP ile Yapay Zeka Asistanını SMM Paneline Bağlama

Bir SMM panelinde günün büyük bölümü aynı üç işe gider: katalogda doğru servisi bulmak, tutarı hesaplamak ve açılmış siparişlerin ne durumda olduğunu kontrol etmek. Üçü de tıklamayla yapılır, üçü de sıkıcıdır ve üçü de dikkat ister. Panel Follows artık bu üç işi bir yapay zeka asistanına devretmene izin veriyor: asistanına "Instagram takipçi fiyatlarını karşılaştır" ya da "son on siparişimde takılan var mı" diyebiliyorsun ve asistan cevabı panelden okuyup getiriyor.

Bunu mümkün kılan şey MCP adında bir protokol. Bu yazı, MCP'nin ne olduğunu, panelde nasıl kurulduğunu, asistanın tam olarak hangi yetkileri aldığını ve hangi yetkileri asla alamadığını anlatıyor. Pazarlama metni değil: gerçek uç noktaları, gerçek araç adlarını, gerçek süreleri ve gerçek sınırları sırayla veriyorum.

Baştan bir uyarı yapayım, çünkü bu konuda yanlış beklenti kurmak kolay. Asistanı bağlamak sipariş verme kararını asistana devretmek demek değildir. Sipariş açan araçlar gerçek para harcar ve geri alınamaz, o yüzden sunucu modele "önce ara, sonra fiyatı önizle, sonra kullanıcıdan açık onay al" akışını dayatıyor. Sen onaylamadan sipariş açılmaz. İstersen bağlantıyı en baştan "yalnız görüntüleme" izniyle kurup sipariş araçlarını tamamen kapatabilirsin.

MCP nedir ve bir SMM panelinde ne işe yarar?

MCP (Model Context Protocol), bir yapay zeka asistanının dış sistemlerdeki araçları standart tek bir arayüzden çağırmasını sağlayan açık bir protokoldür; Panel Follows'ta bu, asistanının senin hesabında servis araması, fiyat hesaplaması ve senin onayınla sipariş açması anlamına gelir. Kısacası bir MCP sunucusu, yapay zekaya "şu işleri yapabilirsin, parametreleri de şunlardır" diyen makine okunabilir bir kataloğdur.

Bu yaklaşımın klasik entegrasyondan farkı şu: normalde bir sisteme AI bağlamak için ortada bir aracı yazılım olması gerekir. Birinin API belgelerini okuması, uç noktaları fonksiyonlara çevirmesi ve modele hangi fonksiyonu ne zaman çağıracağını öğretmesi gerekir. MCP bu katmanı standartlaştırır. Sunucu araçlarını kendi tanıtır, istemci de o tanımı olduğu gibi modele verir. Yani ortada yazılacak bir tutkal kod kalmaz.

SMM paneli bağlamında kazanç üç yerde toplanıyor:

1. Katalog araması. Panelde binlerce servis var ve doğru olanı bulmak filtre çevirmekle geçiyor. Asistan aynı filtreleri tek cümlelik bir istekle uygular: platform, kategori, telafi desteği, fiyat aralığı.
2. Fiyat hesabı. Asistan sipariş açmadan önce tutarı önizleyip sana söyleyebilir. Böylece butona basmadan önce hesabından ne çıkacağını konuşarak öğrenirsin.
3. Durum takibi. "Hangi siparişlerim yarım kaldı" sorusunun cevabı normalde tabloyu gözle taramaktır. Asistan aynı listeyi okuyup özetler.

Bir de dördüncü, daha az konuşulan kazanç var: ajans işi yapıyorsan asistan senin operasyon dilini konuşur. Müşteri adını, hedef adedi ve bağlantıyı söylersin; asistan hangi servisin uygun olduğunu, tutarın ne olacağını ve bakiyenin yetip yetmediğini tek turda getirir. Panelin genel işleyişini hiç bilmiyorsan önce Panel Follows kullanım kılavuzunu okumanı öneririm; bu yazı onun üstüne biner.

Panelde iki ayrı MCP sunucusu var: hangisi kimin için?

Panel Follows'ta birbirinden bağımsız iki MCP sunucusu çalışıyor ve bu yazının konusu neredeyse tamamen birincisi. Karıştırmamak önemli, çünkü ikisinin adresi, kimlik doğrulaması ve yetki alanı tamamen farklı.

	Kullanıcı sunucusu	Yönetim sunucusu
Uç nokta	POST /api/mcp/user	POST /api/mcp
Kim bağlanır	panelin müşterisi	panel sahibi
Kimlik	OAuth 2.1 jetonu veya hesabın API anahtarı	tek gizli anahtar (MCP_SECRET)
Yetki alanı	yalnız kendi hesabı, 18 araç	panelin tamamı, 57 araç
Denetim kaydı	aiAuditLog (hesap kimliği dolu)	aiAuditLog (hesap kimliği boş)

Kullanıcı sunucusu her istekte tek bir hesaba bağlıdır. Araçlar başka bir kullanıcının verisini göremez, fiyat değiştiremez, sağlayıcı ayarlarına dokunamaz. Yani bir müşteri asistanını bağladığında panelin yönetim tarafına dair hiçbir kapı açılmaz; kendi hesabının içindeki işlemleri yapar, o kadar.

İki sunucu aynı çekirdeği paylaşıyor. Protokol katmanı, araç kaydı, hata biçimi ve denetim günlüğü ortak. Bunun pratik anlamı şu: kullanıcı tarafında gördüğün davranış (hata biçimi, kırpma sınırı, desteklenen metotlar) yönetim tarafında da aynı şekilde çalışır. Ortak katmanın tek istisnası yetkilendirme: biri OAuth ve API anahtarı kabul ederken diğeri tek bir gizli anahtarla korunuyor.

Bu yazının 19. bölümünde yönetim sunucusuna kısaca değineceğim, ama odak müşteri tarafında kalacak. Sen bir bayi ya da ajanssan ilgilendiğin sunucu /api/mcp/user olacak.

Asistanın erişebildiği 18 araç neler?

Kullanıcı sunucusu tam yetkili bir bağlantıya 18 araç açar. Araçların hepsi panelin geliştirici API'sinin (v3) aynasıdır: parametre adları birebir aynıdır, dönen alanlar aynıdır. Yani MCP tarafında öğrendiğin her şey API belgelerinde de aynen geçerlidir.

Alan	Araçlar
Hesap	get_account
Katalog	list_platforms, list_categories, search_services, get_service
Sipariş	preview_order, create_order, create_orders_bulk, list_orders, get_order, cancel_order, refill_order
Telafi	list_refills, get_refill
Otomasyon	list_events, list_webhooks, create_webhook, delete_webhook

Bu 18 aracın 12'si salt okunurdur: get_account, list_platforms, list_categories, search_services, get_service, preview_order, list_orders, get_order, list_refills, get_refill, list_events, list_webhooks. Geriye kalan 6 tanesi yazar: create_order, create_orders_bulk, cancel_order, refill_order, create_webhook, delete_webhook.

Yazan araçların hepsi eşit değil. Protokol düzeyinde her araç readOnlyHint ve destructiveHint adında iki ipucuyla listeleniyor ve istemciler bu ipuçlarına göre farklı davranabiliyor. create_order, create_orders_bulk, cancel_order ve delete_webhook yıkıcı işaretlidir. refill_order ve create_webhook yazar ama yıkıcı sayılmaz, çünkü ikisi de mevcut bir şeyi bozmaz: telafi ücretsizdir ve bakiyeye dokunmaz, webhook eklemek de var olanı değiştirmez.

Birkaç aracın davranışını ayrıca bilmekte fayda var:

• get_account hesabın kimliğini, e-postasını, kullanılabilir bakiyesini (USD) ve istek limitini döner. Asistan sipariş önermeden önce genelde buraya bakar.
• search_services şu süzgeçleri kabul eder: search, platform, category, type, refill, cancel, dripfeed, min_rate, max_rate. Sayfa boyutu varsayılan 20, en fazla 50.
• get_service tek servisin tüm künyesini verir: fiyat, min/max, telafi ve iptal desteği, damla besleme desteği, ortalama süre ve sipariş alanları listesi (fields). Bu son alan önemlidir, çünkü model hangi alanların zorunlu olduğunu tahmin etmez, buradan okur.
• list_orders durum süzgeci kabul eder: pending, in_progress, completed, partial, canceled, refunded, failed. Varsayılan 20, en fazla 100 kayıt.
• Listeleme araçlarının hepsi imleçle sayfalanır. starting_after parametresi gönderilir, yanıtta next_cursor döner.

AI asistanını panele nasıl bağlarsın?

Bağlantı üç adımdan ibaret ve hiçbirinde parola paylaşmıyorsun. Panelde bu işin sayfası sol menüdeki "AI Asistan" öğesi, adresi de /dashboard/mcp.

1. Adresi kopyala. Sayfanın "Bağlantı adresi" kartında panelin MCP adresi yazar ve yanında "Kopyala" butonu bulunur. Ana panelde bu adres https://panelfollows.com/api/mcp/user biçimindedir. Kartın altındaki not durumu özetler: "Bu adresi AI istemcine ekle. Onay bu panelde alınır; parolan istemciye asla verilmez."
2. İstemcine MCP sunucusu olarak ekle. İstemci adresi eklediği anda kimliksiz bir istek atar, 401 yanıtı alır ve bu yanıttan yetkilendirmenin nasıl yapılacağını öğrenir. Sonra tarayıcını açıp seni panelin kendi onay ekranına yönlendirir.
3. Onayla. Onay ekranında istemcinin adı, hesabının e-postası ve verilecek izinler yazar. "Bağlantıyı onayla" dediğinde istemci jetonunu alır ve bağlantı kurulur.

Üçüncü adım bittiğinde asistanına doğrudan konuşarak istek verebilirsin. Panelin kendi ifadesiyle: "Artık asistanına 'Instagram takipçi fiyatlarını göster' ya da 'son siparişlerim ne durumda' diyebilirsin."

Panelde oturumun açık değilse ikinci adımda önce giriş ekranına yönlendirilirsin, giriş yaptıktan sonra aynı onay ekranına geri dönersin. Yani akış ortada kopmaz. Onay ekranının adresi /mcp/connect şeklindedir, ama bu sayfayı doğrudan açmanın bir anlamı yoktur: yalnızca istemcinin başlattığı bir akışın içinde anlamlıdır ve arama motorlarına kapalıdır.

Bir noktayı net söyleyeyim: OAuth 2.1 destekleyen her MCP istemcisi çalışır. Panel belirli bir markaya bağlı değil. Sayfadaki not da bunu söylüyor: "OAuth 2.1 destekleyen her MCP istemcisi çalışır. Başlık gönderebilen istemcilerde API anahtarı da kullanılabilir."

İstemciye göre kurulum: komut satırı, JSON ve düz istek

Panel sayfası istemci tipine göre üç ayrı kurulum örneği veriyor. Aşağıdaki örnekler paneldeki metinlerin birebir aynısıdır, yani ekranda gördüğünle burada okuduğun aynıdır.

Komut satırından ekleyen istemcilerde tek satır yeterli:

claude mcp add --transport http panel https://panelfollows.com/api/mcp/user

Yapılandırmayı JSON dosyasından okuyan istemcilerde sunucu tanımı şu biçimdedir:

{ "mcpServers": { "panel": { "type": "http", "url": "https://panelfollows.com/api/mcp/user" } } }

Başlık gönderebilen istemcilerde OAuth akışını hiç çalıştırmadan doğrudan API anahtarıyla da bağlanabilirsin:

claude mcp add --transport http panel https://panelfollows.com/api/mcp/user \
  --header "Authorization: Bearer pf_live_..."

Bağlantının çalışıp çalışmadığını herhangi bir istemci olmadan sınamak istersen düz bir HTTP isteği yeterlidir. Aşağıdaki istek sunucudaki araç listesini döner:

curl -s https://panelfollows.com/api/mcp/user \
  -H "Authorization: Bearer pf_live_..." \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

İstemci tipi	Nasıl eklenir	Kimlik yolu
Komut satırı istemcisi	claude mcp add --transport http ...	OAuth ya da --header ile API anahtarı
Yapılandırma dosyası okuyan masaüstü istemcisi	mcpServers bloğuna type: http ve adres	OAuth (tarayıcı açılır)
Kendi yazdığın bot veya betik	doğrudan HTTP POST	API anahtarı (Authorization: Bearer ya da X-Api-Key)
Editör eklentisi (özel şema ile dönüş yapan)	istemcinin kendi MCP ayarı	OAuth, dönüş adresi cursor:// ya da vscode:// olabilir

Bir uyarı: adres tam olarak /api/mcp/user ile bitmelidir. Sondaki user parçasını düşürürsen yönetim sunucusuna gitmiş olursun ve o uç nokta senin kimliğini kabul etmez. Alt panel müşterisiysen adresteki alan adı da kendi panelinin alan adı olmalıdır, ana panelin adresi değil.

OAuth 2.1 akışı arka planda tam olarak ne yapıyor?

Onay ekranında iki tıklama yapıyorsun ama arka planda altı adımlı standart bir akış işliyor. Bunu bilmenin pratik faydası var: bir şey ters gittiğinde hangi adımda takıldığını anlarsın.

1. Keşif tetiklenir. İstemci kimliksiz istek atar ve 401 alır. Yanıttaki WWW-Authenticate başlığı hem hatayı hem de kaynak meta verisinin adresini taşır (RFC 9728). Yani istemciye "yetkin yok, izni şu adresten öğren" denmiş olur.
2. Meta veri okunur. İstemci önce /.well-known/oauth-protected-resource belgesini, oradan da /.well-known/oauth-authorization-server belgesini okur (RFC 8414). İkinci belge yetkilendirme ve jeton uçlarının adreslerini bildirir.
3. İstemci kendini kaydeder. POST /api/mcp/oauth/register ile dinamik kayıt yapılır (RFC 7591). Kaydedilen istemci gizli anahtarsızdır (public client); kimlik doğrulaması PKCE ile yapılır. Kayıt IP başına saatte 10 denemeyle sınırlıdır.
4. Tarayıcı açılır. İstemci seni GET /api/mcp/oauth/authorize adresine gönderir, o da panelin kendi onay ekranı olan /mcp/connect adresine yönlendirir. Oturumun yoksa önce girişe düşer, giriş sonrası aynı ekrana dönersin.
5. Sen onaylarsın. İstersen "yalnız görüntüleme" kutusunu işaretlersin. Onaylayınca panel istemciye kısa ömürlü bir yetkilendirme kodu döner.
6. Kod jetona çevrilir. İstemci POST /api/mcp/oauth/token ile kodu erişim jetonuna çevirir. PKCE S256 zorunludur, plain kabul edilmez. Bu OAuth 2.1 kuralıdır ve panel istisna tanımaz.

Belgede bildirilen alan	Değer	Ne anlama geliyor
response_types_supported	["code"]	yalnız yetkilendirme kodu akışı
grant_types_supported	["authorization_code", "refresh_token"]	kod ve yenileme jetonu
token_endpoint_auth_methods_supported	["none"]	istemci gizli anahtarı yok, PKCE var
code_challenge_methods_supported	["S256"]	plain PKCE reddedilir
authorization_response_iss_parameter_supported	true	yanıtta issuer bildirilir (RFC 9207)
resource_indicators_supported	true	kaynak göstergesi desteklenir (RFC 8707)

İki ayrıntı daha var. Birincisi: kayıtlı dönüş adresleri (redirect_uris) olarak https, geri döngü http (127.0.0.1 ve localhost) ve özel şemalar (cursor://, vscode://) kabul edilir. Uzak bir adrese düz http ile dönmek reddedilir. Dönüş adresi kayıtlı listeyle eşleşmek zorundadır ve tek esneklik geri döngü portudur (RFC 8252). PKCE doğrulayıcısı da 43 ile 128 karakter arasında olmalıdır.

İkincisi ve bayiler için önemli olanı: bütün adresler isteğin kendi origin'inden üretilir. Alt panel sahibinin müşterisi kendi alan adından bağlandığında issuer da o alan adı olur. Ana panelin adresi müşteriye hiçbir aşamada görünmez.

API anahtarıyla bağlanmak ne zaman daha mantıklı?

OAuth akışı tarayıcı gerektirir. Tarayıcı açamayan ya da başlık göndermeyi tercih eden istemcilerde ikinci bir yol var: hesabının API anahtarıyla doğrudan bağlanmak.

Sunucu üç tür Bearer değerini kabul eder: OAuth erişim jetonu (pf_mcp_ ön ekli), geliştirici API'si v3 anahtarı (pf_live_ ön ekli) ve 64 haneli onaltılık eski bayi anahtarı. Authorization: Bearer başlığı yerine X-Api-Key başlığı da kullanılabilir. Hangi yolun kullanıldığı yalnızca ön ekten anlaşılır, yani ayrı bir ayar açman gerekmez.

	OAuth 2.1 ile bağlanma	API anahtarıyla bağlanma
Kurulum	tarayıcıda tek onay	anahtarı kopyalayıp başlığa yazma
Anahtar kopyalama	yok	var, anahtarı istemciye vermen gerekir
Kapsam kısıtı	var ("yalnız görüntüleme" seçilebilir)	yok, bağlantı her zaman tam yetkilidir
Süre	erişim jetonu 8 saat, kendi tazelenir	iptal edene kadar geçerli
Panelde görünürlük	"Bağlı asistanlar" listesinde satır olarak	ayrı bir bağlantı satırı oluşturmaz
Uygun olduğu yer	masaüstü ve editör istemcileri	sunucuda çalışan bot, betik, otomasyon

Bu tabloda dikkat etmen gereken satır kapsam satırı. Anahtarla gelen bağlantı her zaman tam yetkilidir; salt okunur kısıt yalnızca OAuth tarafında anlamlıdır. Yani "asistan sipariş açamasın" istiyorsan anahtar yolu bunu sağlamaz, OAuth akışını kullanıp onay ekranındaki kutuyu işaretlemen gerekir.

Anahtarını API sayfasından üretirsin. Panelin MCP sayfasında da aynı yere bir kısayol vardır ve notu şudur: "Anahtarla bağlanmayı tercih edersen anahtarını buradan oluştur." Anahtarı yenilersen eski anahtarla kurulmuş bütün bağlantılar aynı anda durur, bunu bilerek yenile.

Onay ekranında ne görüyorsun ve neyi onaylıyorsun?

Onay ekranı akışın en kritik noktasıdır, çünkü yetkiyi veren tıklama orada yapılır. Ekranın başlığı istemcinin adını taşır: "{istemci adı} hesabına bağlanmak istiyor". Altındaki açıklama net: "Onaylarsan bu uygulama hesabın adına aşağıdaki işlemleri yapabilir."

Ekranda dört bilgi ve iki buton bulunur:

1. "Hesap": bağlantının kurulacağı hesabın e-postası. Birden fazla hesabın varsa doğru hesapta olduğunu buradan doğrularsın.
2. "Yönlendirilecek adres": onaydan sonra tarayıcının gideceği adres. Bu satır güvenlik açısından önemlidir, çünkü jetonun teslim edileceği yeri gösterir. Tanımadığın bir adres görüyorsan onaylama.
3. İzin listesi: bağlantının alacağı yetkiler.
4. "Yalnız görüntüleme izni ver (sipariş açamasın)" kutusu.

Butonlar "Bağlantıyı onayla" ve "Reddet" şeklindedir. Onayladığında ekranda kısa bir "Yönlendiriliyor…" mesajı görürsün ve istemciye dönersin.

Ekran iki hata mesajı üretebilir. Birincisi: "Bağlantı isteği geçersiz ya da süresi dolmuş. İstemciden yeniden başlat." Bu mesajı görüyorsan ya sayfayı akış dışında açtın ya da yetkilendirme kodunun on dakikası doldu. İkincisi: "İşlem tamamlanamadı. Tekrar dene." Bu genel bir hatadır ve akışı baştan başlatman gerekir.

Onay ekranını doğrudan adresinden açmanın hiçbir işlevi yoktur. Sayfa yalnızca istemcinin başlattığı bir akışın parametreleriyle anlam kazanır ve arama motorlarına kapalıdır. Bir yerde bu sayfaya giden bir bağlantı görürsen, o bağlantı senin başlattığın bir akıştan gelmiyorsa tıklama.

"Yalnız görüntüleme" izni tam olarak neyi kapatır?

Panelde iki kapsam tanımlıdır: account:read ve account:write. İstemci hiçbir kapsam istemezse ikisi de verilir, yani varsayılan bağlantı tam yetkilidir. Onay ekranındaki kutuyu işaretlersen jeton yalnızca account:read alır.

Burada uygulamanın seçtiği yöntem önemli. Salt okunur bir bağlantıda sunucu yazma araçlarını modele hiç göstermez: araç listesi süzülür ve 18 araç yerine 12 araç görünür. Yani model "bu aracı çağırma" talimatını dinlemek zorunda kalmaz, aracın var olduğunu bile bilmez. Bu bilinçli bir tercihtir, çünkü yönergeye uymayı modelin insafına bırakmak güvenilir bir güvenlik yöntemi değildir.

Araç	Tam erişim	Yalnız görüntüleme
get_account, list_platforms, list_categories	var	var
search_services, get_service, preview_order	var	var
list_orders, get_order, list_refills, get_refill	var	var
list_events, list_webhooks	var	var
create_order, create_orders_bulk	var	yok
cancel_order, refill_order	var	yok
create_webhook, delete_webhook	var	yok

Araç listesini süzmenin yanında sunucu modele ek bir not da verir: bu bağlantının salt okunur olduğu ve kullanıcı sipariş vermek isterse panelden izni değiştirip yeniden bağlanması gerektiği söylenir. Yani asistan "bunu yapamıyorum" derken ne yapılması gerektiğini de bilir.

Kapsam kararı bağlantı başınadır, hesap başına değil. Aynı hesaba biri tam yetkili, biri salt okunur iki ayrı asistan bağlayabilirsin. Panelde her satırın yanında "Tam erişim" ya da "Yalnız görüntüleme" rozeti görünür, yani hangisinin ne yetkisi olduğunu tek bakışta ayırt edersin.

Son bir teknik ayrıntı: istemcinin istediği tanınmayan kapsamlar (openid, profile, email gibi) sessizce düşer. Yani bir istemci alışkanlıkla bu kapsamları isterse akış hata vermez, sadece o kapsamlar verilmez.

Asistan bir siparişi hangi sırayla veriyor?

Sipariş açan bir aracın yanlış sırayla çağrılması kullanıcıya doğrudan zarar verir, o yüzden sunucu modele sabit bir akış dayatıyor. Bu akış sunucunun yönergesinde yazılıdır ve asistan bağlandığı anda okur.

1. search_services ile uygun servisi bulur ve servis numarasını (id) not eder. Aramayı platform, kategori ya da serbest metinle daraltır.
2. get_service ile ayrıntıyı okur: min ve max sınırlar, telafi ve iptal desteği, ortalama süre ve zorunlu sipariş alanları.
3. preview_order ile tutarı hesaplar. Yanıttaki charge (ücret) ve sufficient_balance (bakiye yeterli mi) alanlarını sana net söylemesi istenir.
4. Senden açık onay alır. Onay olmadan create_order çağırması yasaklanmıştır; sipariş gerçek para harcar ve geri alınamaz.
5. create_order ile siparişi açar ve dönen sipariş numarasını sana bildirir.

Pratikte konuşma kabaca şöyle ilerler. Sen "şu profile 1000 Instagram takipçisi al" dersin. Asistan önce kataloğu tarar, birkaç uygun servisi karşılaştırır ve genelde telafi garantisi olanı öne çıkarır. Sonra seçtiği servisin künyesini okur, min ve max sınırların içinde olduğunu doğrular. Ardından tutarı önizler ve "bu sipariş şu kadar tutuyor, bakiyen sonrasında şu kadar kalıyor, açayım mı" diye sorar. Sen onaylarsın, sipariş açılır ve numarası sana söylenir.

Üçüncü adımı atlayan bir asistan kötü çalışıyor demektir, çünkü preview_order siparişi açmadan doğrular. Aynı parametreleri create_order ile birebir alır, tek farkı hiçbir şey oluşturmaması ve para harcamamasıdır. Yani "önce sor, sonra aç" akışının bedeli yoktur.

Adım dörtte onayın nasıl alınacağı istemciye göre biraz değişir. Bazı istemciler yıkıcı işaretli araçları çağırmadan önce kendileri bir onay penceresi gösterir; bu durumda iki kez onay vermiş olursun. Bu bir hata değil, koruma katmanlarının üst üste binmesidir.

Fiyat okumasında en sık yapılan hata: per_1000 ile per_order farkı

Panelde fiyatlar iki farklı mantıkla hesaplanır ve bu ayrımı kaçırmak tutarı 1000 kat yanlış hesaplatır. Bu, hem insanların hem modellerin en çok takıldığı yer.

Servis yanıtındaki pricing.unit alanı iki değer alabilir:

• per_1000: fiyat 1000 adet içindir. Normal servislerin çoğu böyledir. Tutar, birim fiyatın bine bölünüp adetle çarpılmasıyla bulunur.
• per_order: fiyat paketin tamamı içindir. Bine bölme uygulanmaz, yazan rakam siparişin bedelidir.

Panelde paket tipli servisler ve maksimum adedi 1 olan servisler ikinci gruba girer. Örnek üzerinden gidelim ve rakamların varsayımsal olduğunu baştan söyleyeyim: pricing.unit değeri per_1000 olan ve fiyatı 4 dolar görünen bir serviste 500 adetlik sipariş 2 dolara gelir. Aynı 4 dolar per_order bir serviste yazıyorsa ödeyeceğin tutar 4 dolardır, adetten bağımsız olarak.

Sunucu bu ayrımı modele açıkça söyler ve search_services aracının açıklamasında da tekrar eder. Yine de en güvenli yol preview_order çıktısına bakmaktır: o çağrı sunucudaki formülün aynısını çalıştırır ve charge alanında gerçek tutarı verir. Asistanın söylediği rakamla preview_order çıktısı çelişiyorsa doğru olan preview_order çıktısıdır.

İkinci bir kural daha var: tutarlar USD'dir ve ondalık dize olarak döner. Modelin bunları kayan noktaya çevirip yuvarlaması istenmez, çünkü yuvarlama küçük tutarlarda anlamlı fark yaratır. Asistanın sana "yaklaşık şu kadar" demesi normaldir ama karar verirken charge alanındaki tam değeri esas al.

Toplu sipariş asistanda nasıl çalışır?

Çok sayıda siparişi tek turda açmak için create_orders_bulk aracı var. Tek çağrıda en fazla 50 sipariş işlenir.

Aracın en önemli davranışı hata toleransıdır: kalemler sırayla işlenir ve biri başarısız olsa bile diğerleri açılmaya devam eder. Her kalem kendi sonucunu döner. Yani 50 satırlık bir gönderimde 3 satır hatalıysa 47 sipariş açılır, 3 satır kendi hata koduyla geri gelir. Hepsi birden iptal olmaz.

Bu davranış otomasyon açısından iyi bir haber ama dikkat gerektirir. Toplu çağrının sonucunu okumadan "hepsi geçti" varsaymak yanlıştır. Asistanına toplu iş verdiğinde sonuç özetini istemeyi alışkanlık hâline getir: kaç kalem açıldı, hangileri hata verdi ve hata kodları neydi.

Konu	Tekil sipariş (create_order)	Toplu sipariş (create_orders_bulk)
Tek çağrıdaki sipariş sayısı	1	en fazla 50
Hata davranışı	çağrı başarısız olur	başarısız kalem atlanır, diğerleri açılır
Sonuç biçimi	tek sipariş numarası	kalem başına ayrı sonuç
Önizleme	preview_order ile aynı parametrelerle	kalem kalem önizlenmeli
İşaret	yıkıcı	yıkıcı

Toplu siparişte fiyat önizlemesi ayrı bir konudur. preview_order tek kalem alır, yani 50 kalemlik bir işin toplam tutarını görmek istiyorsan asistanın kalemleri tek tek önizleyip toplaması gerekir. Bakiyenin yetip yetmeyeceğini önceden bilmek istiyorsan bunu açıkça iste, yoksa asistan doğrudan açmaya kalkabilir ve ortada bakiye biterse kalan kalemler insufficient_balance hatasıyla düşer.

Ajans tarafında düzenli toplu iş yapıyorsan, operasyonun büyüdükçe manuel konuşma yerine olay akışına ve webhook'lara geçmen daha sağlıklı olur. Bu geçişin ticari tarafını sosyal medya ajansı ölçekleme rehberinde ayrıca ele almıştık.

Damla besleme ve özel servis tipleri asistanda nasıl işler?

Asistanın kullandığı parametre adları geliştirici API'si v3 ile birebir aynıdır. Bu, ezberlemen gereken ikinci bir sözlük olmaması demek: panelde ya da API'de bildiğin alan adı MCP tarafında da aynıdır.

Standart sipariş alanları service, link ve quantity. Damla besleme destekleyen servislerde runs (parti sayısı) ve interval (dakika cinsinden aralık) eklenir. Özel tipli servislerde ise tipe göre değişen ek alanlar devreye girer: comments, username, posts, min, max, usernames, hashtag, hashtags, answer_number, groups, keywords ve media.

Burada asistanın tahmin yürütmesini engelleyen mekanizma get_service çıktısındaki fields listesidir. O liste seçilen servisin hangi alanları istediğini açıkça bildirir. Sunucu yönergesi de modele "hangi alanların zorunlu olduğunu tahmin etme, bu listeye bak" der. Pratik sonucu şudur: asistan bir yorum servisinde senden yorum metinlerini, bir anket servisinde şık numarasını ister; sen istemeden alan uydurmaz.

Yorum tipli servisler ayrı bir kural taşır: bu servislerde quantity gönderilmez. Her satıra bir yorum yazılır ve satır sayısı adedi belirler. Asistana on yorum verirsen sipariş on adetlik olur. "Hem yorum listesi hem adet" göndermeye çalışmak hatalıdır.

Damla beslemede ise adet okuması panelin form davranışıyla aynıdır: quantity parti başına miktardır, toplam teslimat parti sayısıyla çarpılarak bulunur ve ücret bu toplam üzerinden alınır. Yani quantity 1000 ve runs 10 gönderirsen 10.000 adetlik bir sipariş açmış olursun. Asistana damla beslemeli sipariş verdirirken tutarı mutlaka önizlet; bu, panelin form tarafında da en çok kaza çıkaran yerdir.

Damla beslemenin gerçekte neyi değiştirdiğini ve hangi beklentinin abartılı olduğunu kademeli teslimat ve otomatik servisler yazısında uzun uzun anlattık. Kısaca: teslimatın zamanlamasını değiştirir, hesabın güvenliğini değiştirmez.

Sipariş sonrası: durum takibi, iptal ve telafi asistanla nasıl yürür?

Sipariş açıldıktan sonraki üç iş de araçlarla yapılır: durumu okumak, iptal etmek ve telafi (refill) istemek. Üçünün de kendi koşulları var.

Durum takibi için iki araç kullanılır. get_order tek siparişin ayrıntısını verir; burada en işe yarayan iki alan başlangıç sayacı ve kalan adettir. list_orders ise listeyi döndürür ve durum süzgeci kabul eder. Sunucu yönergesi modele "sipariş açıldıktan sonra ilerleme anlıktır, get_order ile sayaçları oku, list_events ile durum değişikliklerini izle" der.

İptal yalnız iki koşul birlikte sağlanırsa mümkündür: servisin iptal desteği olmalı (features.cancel) ve sipariş henüz tamamlanmamış olmalı. Servis desteklemiyorsa araç cancel_not_supported kodunu döner. Bu kod sabittir, yani asistan mesajı yorumlamaz, olduğu gibi aktarır. İptalin nasıl işlediğini ve iadenin hangi koşulda yapıldığını daha ayrıntılı okumak istersen kullanım kılavuzundaki iptal bölümüne bakabilirsin.

Telafi yalnız tamamlanmış ve telafi garantili siparişlerde çalışır. Ücretsizdir ve bakiyeye dokunmaz, o yüzden yazan araçlar arasında yıkıcı işaretlenmeyenlerden biridir. Telafinin gerçekte neyi kapsadığını, hangi düşüşün telafi edilmediğini takipçi düşüşü ve telafi yazımızda ayrıntılı anlattık.

İşlem	Araç	Koşul	Bakiye etkisi
Durum okuma	get_order, list_orders	yok	yok
İptal	cancel_order	servis desteklemeli, sipariş tamamlanmamış olmalı	sağlayıcı iptal ederse iade
Telafi	refill_order	sipariş tamamlanmış ve telafi garantili olmalı	yok, ücretsizdir
Telafi takibi	list_refills, get_refill	yok	yok

Şunu net söyleyeyim: telafi ve iptal servise bağlıdır, panele değil. Telafi desteklemeyen bir serviste düşüş yaşanırsa asistan da senin gibi çaresizdir; araç hata döner ve o hata gerçeği söyler. Bu yüzden servis seçerken get_service çıktısındaki telafi ve iptal bayraklarına bakmak, sipariş açtıktan sonra çözüm aramaktan daha ucuzdur.

Asistan neleri yapamaz?

Sınırları bilmek yetkileri bilmek kadar önemli. Panel bu sınırları hem araç listesini kısıtlayarak hem de sunucu yönergesinde açıkça söyleyerek uyguluyor.

Asistan şunları yapamaz:

1. Bakiye yükleyemez. Ödeme akışlarının hiçbiri araç olarak tanımlı değildir.
2. Para çekemez. Hesaptan dışarı para çıkaran hiçbir işlem yoktur.
3. Fiyat değiştiremez. Fiyatlandırma yönetim tarafındadır ve kullanıcı sunucusunda karşılığı yoktur.
4. Destek talebi açamaz. Destek akışı panel üzerinden yürür.
5. Parolanı göremez. Parola hiçbir aşamada istemciye verilmez, OAuth akışının tamamı panelin kendi oturumu üzerinden işler.
6. Başka hesaplara erişemez. Sunucu her istekte tek bir hesaba bağlıdır; bağlı olduğu hesap sabittir.

Panelin MCP sayfasındaki üç satırlık özet de bunu aynı şekilde söylüyor. Okuma tarafı için: "Servisleri arar, fiyat hesaplar, siparişlerini ve bakiyeni görüntüler." Yazma tarafı için: "Sipariş açar, iptal eder, telafi (refill) talebi oluşturur. Sipariş açmadan önce senden onay ister." Ve sınır için: "Bakiye yükleyemez, para çekemez, parolanı göremez ve başka hesaplara erişemez."

Bunlara bir de yumuşak sınır eklemek gerekir. Asistanın bir aracı çağırıp hata alması protokol hatası sayılmaz: hata, içinde isError: true bulunan bir metin olarak döner. Bunun amacı modelin hatayı okuyup kendini düzeltebilmesidir. Yani asistan yanlış bir parametre gönderirse bağlantı kopmaz, hatayı okur ve genelde ikinci denemede doğrusunu yapar.

Son olarak yönerge modele bir davranış kuralı daha veriyor: hata kodları sabittir (örneğin insufficient_balance, quantity_out_of_range) ve mesaj kullanıcının dilindedir. Model mesajı olduğu gibi aktarmalı, uydurma çözüm önermemelidir. Asistanın "bakiyen yetmiyor" demesi bekleneni; "ben yükledim" demesi mümkün değildir.

Güvenlik: sırlar, ön ekler ve süreler

Sistemde beş tür sır dolaşıyor ve hepsinin kendi ön eki ile ömrü var. Ön ekler işini kolaylaştırmak için: bir kayıtta ya da günlükte gördüğün değerin ne olduğunu bakar bakmaz anlarsın.

Sır	Ön ek	Süre
Yetkilendirme kodu	pf_mca_	10 dakika, tek kullanımlık
Erişim jetonu	pf_mcp_	8 saat
Yenileme jetonu	pf_mcr_	90 gün, her kullanımda döner
İstemci kimliği	mcpc_	süresiz
API anahtarı (v3)	pf_live_	iptal edilene kadar

Üretim tarafında hepsi 32 baytlık (256 bit) rastgele değerlerden türetilir ve base64url ile kodlanır. Veritabanında ise yalnızca HMAC-SHA256 özeti durur; düz metin hiçbir yerde saklanmaz. Özet anahtarı (pepper) PANEL_SECRET_KEY değerinden, o tanımlı değilse BETTER_AUTH_SECRET değerinden türer. Bunun pratik anlamı şudur: veritabanını okuyabilen biri bile jetonları geri üretemez.

Bir de yeniden kullanım koruması var ve önemli. Bir yetkilendirme kodu ikinci kez kullanılırsa ya da iptal edilmiş bir yenileme jetonu tekrar gelirse, o istemcinin bu hesap için tüm jetonları iptal edilir. Yani çalınmış bir kodun ya da jetonun sessizce kullanılmaya devam etmesi mümkün değildir; sistem şüpheli durumda erişimi kesme yönünde davranır.

Süreler tarafında en çok merak edilen soru erişim jetonunun 8 saatlik ömrü. Bu süre dolduğunda istemci yenileme jetonuyla kendi tazeler ve sen hiçbir şey fark etmezsin. Yenileme jetonu da her kullanımda döner, yani aynı değer iki kez kullanılmaz. Yenileme jetonunun 90 günü dolarsa ya da bağlantıyı kestiysen istemci 401 invalid_token alır ve akışı baştan başlatman gerekir.

Her çağrı kayıt altında: denetim günlüğü ne tutuyor?

Asistanın yaptığı her araç çağrısı aiAuditLog tablosuna yazılır. Kayıtta şunlar durur: istemci bilgisi (User-Agent), hesap kimliği, araç adı, argümanlar, sonuç, hata ve çağrının süresi.

Bunun en somut faydası şu: bir siparişin panelden mi yoksa AI ile mi açıldığı sonradan görülebilir. Ekip çalışıyorsan ya da bir siparişin nereden geldiğini araştırıyorsan bu ayrım işe yarar.

Günlüğün üç davranışını bilmekte fayda var:

1. Maskeleme. Argümanlardaki gizli görünümlü alanlar *** ile maskelenir. Maskelenen anahtar adları şunlardır: apikey, api_key, secret, password, passphrase, token. Yani bir şekilde bir araca anahtar geçirilse bile günlüğe düz metin olarak düşmez.
2. Seçici sonuç kaydı. Okuma araçlarının sonucu günlüğe yazılmaz, çünkü hacmi büyük ve değeri azdır. Yazma araçlarının sonucu yazılır. Yani "ne yapıldı" kaydı tutulur, "ne okundu" kaydı gereksiz yere şişirilmez.
3. Kırpma. Argüman ve sonuç JSON'u 8.000 karakterde kırpılır. Bu, tek bir büyük çağrının günlüğü doldurmasını engeller.

Denetim yazımı best-effort çalışır. Günlük yazılamazsa ana akış bozulmaz, yani sipariş açılırken günlük tarafında bir sorun çıkarsa siparişin iptal olmaz. Bu bilinçli bir tercih: kayıt tutmak önemlidir ama işlemi durduracak kadar değil.

Bir de araç çıktısı tarafında ayrı bir sınır var: araçların döndürdüğü metin 100.000 karakterde kırpılır. Çok geniş bir listeyi tek çağrıda istersen kırpılmış bir yanıt alabilirsin. Çözüm imleçle sayfalamaktır: starting_after parametresini kullanıp next_cursor ile ilerlemek.

Bağlı asistanları nasıl görürsün ve bağlantıyı nasıl kesersin?

Bağlı asistanların tamamı /dashboard/mcp sayfasının "Bağlı asistanlar" bölümünde listelenir. Hiç bağlantın yoksa orada "Henüz bağlı bir AI asistanı yok." yazar.

Her satırda beş bilgi bulunur:

1. İstemcinin adı. Kayıt sırasında istemcinin bildirdiği ad.
2. Yetki rozeti. "Tam erişim" ya da "Yalnız görüntüleme".
3. Bağlanma tarihi. Satırda "Bağlandı" etiketiyle görünür.
4. Son kullanım tarihi. "Son kullanım" etiketiyle görünür; hiç kullanılmamışsa "Hiç" yazar.
5. "Bağlantıyı kes" butonu.

"Son kullanım" alanı pratikte en işe yarayanı. Aylardır dokunulmamış bir bağlantı görüyorsan onu kesmek en temiz hareket. Kullanmadığın her aktif jeton gereksiz bir yüzeydir.

Kesme işlemi onay ister. Butona bastığında şu soruyu görürsün: "Bu asistanın hesabına erişimi kesilecek. Devam edilsin mi?" Onayladığında "Bağlantı kesildi." mesajı çıkar, işlem başarısız olursa "Bağlantı kesilemedi." mesajını alırsın.

Kestikten sonra ne oluyor? İstemcinin elindeki jeton geçersiz hâle gelir ve bir sonraki çağrısında 401 alır. İstemci tarafında bunun görünümü genelde "sunucuya bağlanamıyorum" şeklindedir. Yeniden bağlanmak istersen akışı istemciden baştan başlatman gerekir; panelde "yeniden bağla" gibi bir kestirme yoktur, çünkü akışı her zaman istemci başlatır.

İptal işlemi standart uçtan da yapılabilir: POST /api/mcp/oauth/revoke. Yani jetonu programatik olarak iptal etmek isteyen bir istemci panele girmeden bunu yapabilir. Panelden tek tıkla kesmek ise aynı sonucu verir.

Otomasyon: olay akışı ve webhook'lar

Asistanla konuşmak tek yönlü bir iştir: sen sorarsın, o bakar. Sipariş durumlarının kendiliğinden sana ulaşmasını istiyorsan iki mekanizma var ve ikisi de araç olarak tanımlı.

Olay akışı hesabında olan biteni eskiden yeniye sıralayan bir kayıttır. list_events aracıyla okunur ve imleçle ilerlenir. Sunucu yönergesi modele bunu "durum değişikliklerini kaçırmadan izlemek için" öneriyor. Webhook kuramayan kullanıcılar için asıl çözüm budur: yerelde geliştiriyorsan, sabit bir IP adresin yoksa ya da dışarıdan istek alabilecek bir sunucun yoksa aynı bilgiye olay akışından ulaşırsın.

Olay türü	Ne zaman düşer
order.created	sipariş oluşturuldu
order.processing	sipariş işleme alındı
order.completed	sipariş tamamlandı
order.partial	sipariş kısmi tamamlandı
order.canceled	sipariş iptal edildi
order.updated	siparişte bir güncelleme oldu
refill.created	telafi talebi oluşturuldu
refill.updated	telafi durumu değişti

Olay adları çevrilmez, her dilde aynıdır. Yani asistan Türkçe konuşurken bile olay türünü order.completed olarak okur ve sana anlamını Türkçe anlatır.

Webhook tarafında üç araç var. list_webhooks kayıtlı adresleri listeler, create_webhook yeni bir adres ekler, delete_webhook siler. Silme işlemi bekleyen gönderimleri de düşürür, yani adresi sildiğinde kuyrukta kalan bir istek sonradan gitmez.

create_webhook çağrısında dikkat etmen gereken tek şey imza gizli anahtarıdır: bu anahtar yanıtta bir kez gösterilir. Asistan sana o anahtarı söylediğinde hemen güvenli bir yere kaydet, çünkü ikinci kez okuyamazsın. Anahtarı kaybedersen yapılacak şey adresi silip yeniden oluşturmaktır. Webhook imzasının nasıl doğrulanacağı ve olay gövdelerinin biçimi API belgelerinde ayrıntılı anlatılıyor.

Hazır komutlar: order_status, find_service ve reorder

MCP'de araçların yanında bir de "prompt" kavramı var: sunucunun istemciye sunduğu hazır komutlar. Bunlar istemcide genelde bir menü ya da eğik çizgi komutu olarak görünür ve seçtiğinde asistana önceden yazılmış bir yönerge gider. Panel Follows üç hazır komut sunuyor.

Komut	Ne yapar	Argümanlar
order_status	Son siparişleri özetler, takılan ve eksik kalanları işaretler	count (varsayılan 10)
find_service	Bir istek için 3 ile 5 servisi karşılaştırır ve fiyat çıkarır, sipariş açmaz	request (zorunlu), quantity
reorder	Geçmiş bir siparişin aynısını onay alarak yeniden açar	order_id (zorunlu)

order_status komutu siparişleri tek tek listeletir: numara, servis adı, durum, adet, kalan adet ve ücret. Tamamlanmayan ya da sağlayıcı hatası olan siparişleri ayrıca vurgulatır ve her biri için ne yapılabileceğini (iptal, telafi, bekleme) söyletir. Günün başında "bugün neye bakmam lazım" sorusunun cevabı olarak düşünebilirsin.

find_service komutu kasten sipariş açmaz. Yönergesi açık: seçenekleri ve tutarı sun, kararı kullanıcıya bırak. Adet verirsen en uygun bulduğu servis için önizleme de yaptırır. Yani katalog araştırmasını asistana devredip son sözü kendine saklarsın.

reorder komutu geçmiş bir siparişi okur, aynı servis, aynı bağlantı ve aynı adet için önizleme yapar, güncel tutarı gösterir ve onay ister. Onay gelmezse hiçbir şey yapmaz. Ayrıca aynı bağlantıya hâlâ devam eden bir sipariş varsa seni önceden uyarır. Düzenli olarak aynı işi tekrarlayan bayiler için en pratik komut budur.

Hazır komutların hepsi prompts/list ile listelenir ve prompts/get ile alınır. İstemcin bu metotları desteklemiyorsa komutlar görünmez; bu bir hata değildir, sadece istemcinin protokolün o parçasını uygulamadığı anlamına gelir. Araçlar yine çalışır.

Asistana ne sorabilirsin? Pratik istek örnekleri

Araç listesini okumak soyut kalabilir, o yüzden araçların gündelik dile nasıl döküldüğüne bakalım. Aşağıdaki istekler tipik kullanım kalıplarıdır; asistanın arkada hangi araçları çağıracağını da yazdım ki neyin mümkün olduğunu tahmin etmek zorunda kalmayasın.

Ne dersin	Asistan arkada ne yapar
"Instagram takipçi servislerini fiyata göre sırala"	list_platforms, search_services
"Telafi garantisi olan TikTok izlenme servislerini göster"	search_services (refill süzgeciyle)
"Şu servisin min ve max sınırı ne, ortalama süresi kaç?"	get_service
"1000 adet alsam ne tutar, bakiyem yeter mi?"	preview_order, gerekirse get_account
"Son on siparişimde takılan var mı?"	list_orders, gerekirse get_order
"Şu siparişin kaç adedi teslim edilmiş?"	get_order
"Geçen hafta açtığım şu siparişin aynısını tekrar aç"	get_order, preview_order, onay sonrası create_order
"Şu siparişi iptal edebilir miyiz?"	get_service (iptal desteği), cancel_order
"Tamamlanan siparişte düşüş var, telafi iste"	refill_order, sonra list_refills
"Sipariş durumları değişince bana haber gelsin"	create_webhook ya da list_events

Bu kalıpların hepsinde ortak bir şey var: sen ne istediğini söylüyorsun, hangi aracın çağrılacağını söylemiyorsun. Araç seçimi modelin işidir ve araç açıklamaları bunu yönlendirecek şekilde yazılmıştır. Örneğin search_services açıklaması modele fiyat biriminin per_1000 mi per_order mi olduğuna bakmasını, get_service açıklaması ise zorunlu alanları tahmin etmeyip fields listesinden okumasını söyler.

İyi sonuç almanın en pratik yolu isteği somutlaştırmaktır. "Takipçi al" demek yerine platformu, hedef bağlantıyı, adedi ve varsa telafi beklentini aynı cümlede vermek asistanın gereksiz tur atmasını engeller. Belirsiz bırakırsan asistan büyük ihtimalle sana soru soracaktır; bu kötü bir şey değil ama iki tur yerine tek tur yeter.

Bir alışkanlık daha öneririm: sipariş açtırmadan önce "tutarı ve bakiye sonrasını söyle" demeyi kural hâline getir. Yönerge zaten bunu şart koşuyor, ama açıkça istediğinde cevabı ekranda net bir rakam olarak görürsün ve onay verdiğin şeyin ne olduğu konusunda tereddüt kalmaz.

Taşıma katmanı: neden SSE yok ve bu ne anlama geliyor?

Panelin MCP sunucusu streamable HTTP üzerinde durumsuz JSON-RPC 2.0 konuşur. Durumsuz olması şu demek: sunucu oturum kimliği tutmaz, her istek kendi başına anlamlıdır ve önceki isteklerin hatırlanmasına dayanmaz.

Bilmen gereken en somut davranış şu: SSE akışı yoktur. GET isteği HTTP 405 döner ve yanıtta "SSE desteklenmiyor; JSON-RPC için POST kullanın" der. Yani adresi tarayıcıya yapıştırıp bir şey görmeyi bekleme, göremezsin. Bu bir arıza değil, bilinçli bir tasarım kararı.

Desteklenen metotlar şunlardır: initialize, tools/list, tools/call, prompts/list, prompts/get, ping, resources/list ve resources/templates/list. Son iki metot boş liste döner, çünkü panel MCP kaynağı (resource) yayımlamıyor; her şey araç olarak sunuluyor.

Protokol sürümü tarafında yerel sürüm 2025-06-18. Geriye dönük olarak 2025-03-26 ve 2024-11-05 de kabul edilir ve hangi sürümün kullanılacağı initialize sırasında uzlaşılır. Eski bir istemcin varsa bağlanmaması için bir sebep yok.

İki teknik ayrıntı daha: JSON-RPC batch (dizi) istekleri desteklenir, yani birden fazla çağrı tek gövdede gönderilebilir. Yalnızca bildirim içeren bir istek gövdesiz HTTP 202 alır. Ve araç hatası protokol hatası değildir: hata, isError: true taşıyan bir metin olarak döner, böylece model hatayı okuyup kendini düzeltebilir.

İstek sınırları: dakikada 600 istek ne demek?

Hesap başına dakikada 600 istek sınırı var. Bu tavan geliştirici API'si v3 ile ortaktır: aynı hesabın isteği MCP'den mi yoksa doğrudan HTTP'den mi geldi fark etmez, ikisi aynı sayaca yazılır.

Sınır aşıldığında HTTP 429 ve Retry-After: 60 başlığı dönersin. İstemcilerin çoğu bu başlığı okuyup bekler, yani asistan tarafında görünümü genelde kısa bir duraklamadır. Beklemeyen bir istemci kullanıyorsan hataları arka arkaya alırsın.

Sınır	Değer	Kapsam
Hesap başına	dakikada 600 istek	MCP ve API v3 ortak sayacı
IP başına (v3 katmanı)	dakikada 900 istek	aynı adresten gelen tüm istekler
OAuth istemci kaydı	IP başına saatte 10 kayıt	POST /api/mcp/oauth/register
Toplu sipariş	çağrı başına 50 kalem	create_orders_bulk
Araç çıktısı	100.000 karakter	kırpılır

Pratikte 600 istek gündelik kullanımda hissedilmeyecek kadar geniş bir tavandır. Bir konuşma turunda asistan tipik olarak birkaç araç çağırır, o kadar. Sınıra takılmanın gerçekçi yolu, bir betiğin döngü içinde durum sorgulaması yapmasıdır. Böyle bir işin varsa durum sorgulamak yerine olay akışını ya da webhook'ları kullanmak hem daha az istek harcar hem daha hızlı bilgi verir.

Bir de sayaç mantığını bilmekte fayda var: sayaç hesap başınadır, bağlantı başına değil. Aynı hesaba üç asistan bağlıysa üçünün istekleri aynı 600'lük tavanı paylaşır.

Bayiler ve alt panel sahipleri için ne değişir?

Kendi markanla bir alt panel işletiyorsan MCP tarafında kayda değer tek bir fark var ve o fark tamamen lehine: bütün adresler isteğin kendi origin'inden üretilir.

Bunun somut sonucu şu. Müşterin senin alan adından bağlandığında keşif belgesindeki issuer, yetkilendirme ucu, jeton ucu ve onay ekranı adresinin hepsi senin alan adını taşır. Ana panelin adresi müşterine hiçbir aşamada görünmez. Beyaz etiket bozulmaz, yani müşterin arka planda başka bir panelin çalıştığını MCP akışından anlamaz.

Alt panel müşterisi için işleyiş de aynıdır: kendi panelinin menüsünde "AI Asistan" öğesini görür, kendi alan adındaki bağlantı adresini kopyalar, kendi panelinin onay ekranında onaylar. Sen panel sahibi olarak ayrı bir kurulum yapmak zorunda değilsin, özellik alt panelde kendiliğinden çalışır.

Burada bir tuzak var ve destek yükü yaratabilir: alt panelden açılan hesap yalnızca o panelin alan adında geçerlidir. Müşterin yanlışlıkla ana panelin MCP adresini kullanırsa hesabı bulunamaz. Böyle bir şikâyet geldiğinde ilk bakacağın yer adresin alan adıdır, kimlik doğrulama değil.

Bayilik modelinin ticari tarafını, marj ayarını ve ödeme raylarını alt panel sayfasında ayrıntılı anlatıyoruz. Sıfırdan bayilik kurmayı düşünüyorsan SMM panel bayiliği rehberi daha geniş bir çerçeve veriyor. MCP'yi bu resme yerleştirmenin en pratik yolu şudur: müşterine sunduğun panelin üstüne, hiç kod yazmadan eklenen bir arayüz katmanı.

Panel sahibi tarafında: 57 araçlık yönetim sunucusu

Panelin kendisi de aynı protokolle yönetilebiliyor. POST /api/mcp adresindeki yönetim sunucusu 57 araç sunar ve tek bir gizli anahtarla (MCP_SECRET) korunur. Bu bölüm müşteriyi ilgilendirmez, ama panelin mimarisini merak edenler için kısaca değinmeye değer.

Anahtar tanımlı değilse uç nokta tamamen kapalıdır ve HTTP 503 döner. Yani özellik varsayılan olarak kapalıdır, açmak için bilinçli bir adım gerekir. Kabul edilen kimlik formları Authorization: Bearer başlığı, X-MCP-Secret başlığı ve ?key= sorgu parametresidir; karşılaştırma sabit zamanlı yapılır.

Araçlar şu alanlara yayılır: genel bakış ve arama, denetim, kullanıcılar, siparişler, sipariş talepleri, servisler, kategoriler, sağlayıcılar, ödemeler, destek talepleri, kuponlar ve ayarlar. Korumalar da yerinde: son aktif yönetici rolden düşürülemez ve yasaklanamaz, para işlemleri işlem ve satır kilidiyle atomik yürür, her çağrı denetim günlüğüne yazılır.

Buradan çıkarılacak asıl mesaj teknik değil operasyonel: panel yönetimi ve müşteri kullanımı aynı protokol üzerinde, aynı denetim günlüğünde ve aynı hata biçiminde çalışıyor. İki taraf birbirinden yetki olarak tamamen ayrılmış durumda.

MCP mi, API mi, panel mi? Hangisini ne zaman kullanmalı

Aynı işi üç farklı yoldan yapabiliyorsun ve üçünün de kendi doğal yeri var. Aşağıdaki tablo seçimi kolaylaştırır.

	Panel arayüzü	MCP (AI asistanı)	Geliştirici API'si (v3)
Kim kullanır	herkes	asistan kullanan herkes	geliştirici
Kurulum	yok	tek onay	anahtar üretme ve kod yazma
Güçlü olduğu iş	tek seferlik işler, görsel kontrol	araştırma, karşılaştırma, özet	tekrarlanan otomasyon
Toplu iş	100 satırlık toplu sipariş sayfası	çağrı başına 50 kalem	sınırsıza yakın, kendi kodun
Durum takibi	tablo	soru sorarak	webhook ve olay akışı
Yeni bir işlem eklemek	ürün geliştirmesi gerekir	araç eklenince kendiliğinden gelir	uç nokta eklenmesi gerekir
Zayıf yanı	tıklama maliyeti	belirsiz istekte yanlış yorum riski	geliştirme maliyeti

Kaba bir kural vermek gerekirse: kararın kendisi senin ve iş her seferinde biraz farklıysa MCP en verimli yoldur, çünkü araştırma ve özetleme kısmını devredersin. İş her seferinde tıpatıp aynıysa ve gün içinde yüzlerce kez tekrarlanıyorsa API doğrudan daha ucuzdur; ortada model tüketimi ve yorum riski olmaz. Görsel doğrulama istediğin, tek seferlik ya da hassas bir işse panel arayüzü hâlâ en güvenli yerdir.

Üçü birbirinin alternatifi değil, katmanı. Aynı hesap aynı anda üçünü de kullanabilir: sabah asistanla katalog araştırması yaparsın, tekrarlanan siparişleri kendi kodun API'den açar, aylık raporu panelden gözle kontrol edersin. Katalogun genel yapısını görmek için hizmetler sayfasına, teknik ayrıntılar için API sayfasına bakabilirsin.

Sorun giderme: sık görülen hatalar ve anlamları

Aşağıdaki tablo, bağlantı kurarken ya da asistanı kullanırken karşına çıkabilecek durumları, arkasındaki gerçek sebebi ve çözümü toplar.

Belirti	Sebep	Çözüm
401 invalid_token	erişim jetonunun 8 saati doldu	istemci yenileme jetonuyla kendi tazeler; tazelemiyorsa panelden yeniden bağla
Tarayıcıda 405	GET ile SSE denendi	protokol yalnız POST kabul eder
429	dakikada 600 istek aşıldı	Retry-After süresi kadar bekle
"Bağlantı isteği geçersiz ya da süresi dolmuş"	yetkilendirme kodunun 10 dakikası doldu ya da istemci kayıtlı değil	akışı istemciden yeniden başlat
Jeton ucu 400 veriyor	istemci plain PKCE gönderdi	yalnız S256 kabul edilir
Yönlendirme reddediliyor	redirect_uri kayıtlı listeyle eşleşmiyor	tek esneklik geri döngü portudur
Uç nokta 503	yönetim sunucusunda MCP_SECRET tanımlı değil	yalnız panel sahibini ilgilendirir
Hesap bulunamıyor	alt panelden açılan hesap yalnız o panelin alan adında geçerlidir	doğru alan adından bağlan

Tablodaki ilk satır en sık görülenidir ve genelde bir sorun değildir. Erişim jetonunun sekiz saati dolduğunda düzgün bir istemci yenileme jetonuyla sessizce tazeler. Hata yüzeye çıkıyorsa ya istemci yenilemeyi uygulamıyordur ya da yenileme jetonu iptal edilmiştir.

Dördüncü satır için ek bir not: yetkilendirme kodu tek kullanımlıktır. Onay ekranından döndükten sonra tarayıcıda geri tuşuna basıp akışı tekrarlamaya çalışırsan kod ikinci kez kullanılmış olur ve sistem bunu şüpheli sayıp o istemcinin bütün jetonlarını iptal eder. Böyle bir durumda tek çözüm akışı baştan başlatmaktır.

Buradaki hiçbir hata verinin kaybolduğu anlamına gelmez. Siparişlerin, bakiyen ve geçmişin bağlantıdan bağımsızdır; bağlantı kesilse de panelde her şey yerinde durur. Genel işleyişle ilgili başka sorularını sıkça sorulan sorular sayfasında bulabilirsin.

Sıkça Sorulan Sorular

MCP nedir, kısaca?

MCP (Model Context Protocol), bir yapay zeka asistanının dış sistemlerdeki araçları standart bir arayüzden çağırmasını sağlayan açık bir protokoldür. Panel Follows'ta bu, asistanının panel hesabında servis araması, fiyat hesaplaması ve senin onayınla sipariş açması anlamına gelir. Sunucu araçlarını kendi tanıtır, istemci de o tanımı modele verir, yani arada yazılacak bir tutkal kod kalmaz.

Asistana panel parolamı vermem gerekiyor mu?

Hayır. Parolan hiçbir aşamada istemciye verilmez. OAuth 2.1 akışında istemci seni panelin kendi onay ekranına yönlendirir, giriş ve onay panelin kendi oturumunda yapılır, istemciye yalnızca kısa ömürlü bir jeton döner. Panelin MCP sayfasındaki not da bunu söyler: "Onay bu panelde alınır; parolan istemciye asla verilmez."

Asistan iznim olmadan sipariş verebilir mi?

Sunucu yönergesi modele açık onay almadan create_order çağırmayı yasaklar ve önce preview_order ile tutarı gösterip onay istemesini şart koşar. Bunun ötesinde kesin bir garanti istiyorsan bağlantıyı "yalnız görüntüleme" izniyle kur: bu durumda sipariş açan araçlar asistana hiç gösterilmez, yani var olmadıkları için çağrılamazlar. Ayrıca birçok istemci yıkıcı işaretli araçlar için kendi onay penceresini de gösterir.

Hangi AI istemcileri destekleniyor?

OAuth 2.1 destekleyen her MCP istemcisi çalışır; panel belirli bir markaya bağlı değildir. Komut satırından ekleyen istemciler, mcpServers bloğu okuyan masaüstü uygulamaları ve editör eklentileri desteklenir. Başlık gönderebilen istemcilerde OAuth akışını hiç çalıştırmadan doğrudan API anahtarıyla da bağlanabilirsin.

Bağlantıyı nasıl keserim, kestikten sonra ne olur?

Panelde "AI Asistan" sayfasındaki "Bağlı asistanlar" listesinden ilgili satırın "Bağlantıyı kes" butonuna basarsın. Onay sorusunu geçtiğinde istemcinin elindeki jeton geçersiz olur ve bir sonraki çağrısında 401 alır. Verilerin etkilenmez: siparişlerin, bakiyen ve geçmişin panelde yerinde durur. Yeniden bağlanmak istersen akışı istemciden baştan başlatman gerekir.

Erişim jetonu ne kadar süre geçerli, tekrar bağlanmam gerekir mi?

Erişim jetonu 8 saat geçerlidir, yenileme jetonu ise 90 gün ve her kullanımda döner. Süre dolduğunda düzgün bir istemci yenileme jetonuyla kendi tazeler, yani sen hiçbir şey fark etmezsin. Yeniden bağlanman yalnızca yenileme jetonunun süresi dolduğunda, bağlantıyı kestiğinde ya da sistem şüpheli bir kullanım nedeniyle jetonları iptal ettiğinde gerekir.

Asistan bakiye yükleyebilir mi?

Hayır. Bakiye yükleme, para çekme, fiyat değiştirme ve destek talebi açma işlemleri araç olarak tanımlı değildir, yani asistanın çağırabileceği bir karşılıkları yoktur. Sunucu yönergesi modele bu işler için kullanıcıyı panele yönlendirmesini söyler. Asistan yalnızca mevcut bakiyeni okuyabilir ve siparişin bakiyeye yeteceğini önizleyebilir.

API anahtarıyla mı OAuth ile mi bağlanmalıyım?

Masaüstü ya da editör istemcisi kullanıyorsan OAuth daha rahattır: anahtar kopyalamazsın, bağlantı panelde satır olarak görünür ve istersen salt okunur kurulabilir. Sunucuda çalışan bir bot ya da betik yazıyorsan API anahtarı daha pratiktir, çünkü tarayıcı gerektirmez. Tek önemli fark şudur: anahtarla gelen bağlantı her zaman tam yetkilidir, salt okunur kısıt yalnız OAuth tarafında anlamlıdır.

Asistanın açtığı siparişleri panelde görebilir miyim?

Evet. Asistanın açtığı siparişler panelde açtığın siparişlerle aynı listede, aynı biçimde görünür; ayrı bir yerde durmaz. Bunun yanında her araç çağrısı denetim günlüğüne yazılır: istemci bilgisi, hesap kimliği, araç adı, argümanlar, sonuç, hata ve süre kaydedilir. Yani bir siparişin panelden mi yoksa AI ile mi açıldığı sonradan görülebilir.

Alt panel müşterileri de kendi asistanlarını bağlayabilir mi?

Evet, özellik alt panelde kendiliğinden çalışır ve panel sahibinin ayrı bir kurulum yapması gerekmez. Müşteri kendi panelinin menüsünden bağlantı adresini alır ve kendi panelinin onay ekranında onaylar. Bütün adresler isteğin kendi origin'inden üretildiği için ana panelin adresi müşteriye hiçbir aşamada görünmez.

Bir araç hata döndürürse ne olur?

Araç hatası protokol hatası sayılmaz: hata, içinde isError: true bulunan bir metin olarak döner ve model bunu okuyup kendini düzeltebilir. Yani yanlış bir parametre gönderildiğinde bağlantı kopmaz. Hata kodları sabittir (örneğin insufficient_balance, quantity_out_of_range) ve mesaj kullanıcının dilindedir; sunucu yönergesi modele mesajı olduğu gibi aktarmasını ve uydurma çözüm önermemesini söyler.

MCP kullanmak ekstra ücretli mi?

Panel tarafında MCP bağlantısı için ek bir ücret alınmaz; ödediğin tek şey açtığın siparişin kendi bedelidir. Kullandığın AI istemcisinin ya da modelin kendi ücretlendirmesi ayrı bir konudur ve panelle ilgisi yoktur. İstek sınırı da geliştirici API'siyle ortaktır, yani MCP'ye özel bir kota satın alman gerekmez.