PinAppAI

← Tüm belgeler

AI ajanları için MCP sunucusu

PinAppAI iteration döngüsünü Claude Code, Codex, Cursor, Continue veya MCP destekli ajandan sür: kur, apply ile Inbox’u boşalt, /changes/ üret.


PinAppAI MCP sunucusu, projene AI-native arayüzdür. Karar dökümlerini editörüne yapıştırmak yerine ajanın apply workflow’unu çalıştırır ve iteration döngüsünün tamamını uçtan uca yürütür: canlı durumu okur, kod düzenlemeleri önerir, bir sonraki yeniden-üretimin sınırını bilmesi için marker yazar ve commit’lemeden önce SORAR.

MCP sunucusu npm’de @pinappai/mcp olarak yayınlanır ve ajanın yanında bir stdio sunucusu olarak çalışır. Kurulum gerektirmeyen, barındırılan bir HTTP endpoint’i olarak da erişilebilir.

Bağlanmanın iki yolu

Yol Ne gerekir En uygun
Barındırılan bağlayıcı Bir URL, sonra tarayıcından giriş yap (veya bir API anahtarı yapıştır) HTTP üzerinden MCP konuşan her client, sıfır kurulum
npm paketi İki komut: npx @pinappai/mcp install, sonra login CI/headless kurulumlar, belirli bir sürüme pin’leme, offline çalışma

İkisi de aynı sunucuya bağlanır: aynı 38 tool, aynı 10 workflow. Hiçbiri daraltılmış bir yüzey değil.

Üç yüzey ve kimin kullandığı

Karıştırılması kolay olduğu için baştan netleştirelim:

Yüzey Kim kullanır Örnek
10 workflow Sen çalıştırırsın apply workflow’u. Nasıl çalıştırdığın client’ına bağlı, bkz. Workflow nasıl çalıştırılır.
38 tool Ajanın protokol üzerinden çağırır list_projects. Bunları asla yazmazsın.
6 CLI komutu Sen, terminalde npx @pinappai/mcp login

Kaçınılması gereken tek hata: workflow bir shell komutu değildir. Terminale pinappai-mcp apply yazmak çalışmaz. Workflow’lar AI client’ının içinde çalıştırılır.

Barındırılan bağlayıcı

MCP’yi HTTP üzerinden konuşan client’lar için, npx @pinappai/mcp’yi yerelde çalıştırmak yerine doğrudan barındırılan bir endpoint’e bağlanabilirsin.

Endpoint: https://mcp.pinappai.com/mcp (Streamable HTTP).

Kimlik doğrulamanın iki yolu var:

  • Tarayıcıdan giriş, yapıştırılacak anahtar yok. Client’ın MCP tarayıcı girişini destekliyorsa (Claude Code destekliyor), endpoint’i hiçbir kimlik bilgisi olmadan ekle. Client’ın tarayıcını açar, erişimi onaylarsın ve ajanın çalışacağı workspace’i seçersin, sonra bağlanır. Elle kopyalanacak ya da saklanacak bir şey yok.
  • API anahtarı. Statik bir header ile kimlik doğrulayan client’lar için bir bearer anahtarı geç: Authorization: Bearer ppk_.... Anahtarı app.pinappai.com/api-keys’den üret (bir ppk_ anahtarının neyi kapsadığı için aşağıdaki npm paketi bölümüne bak).

Her iki durumda da kimlik bilgisi olmayan bir client sunucuyu yine keşfedebilir: tool’ları listeler, workflow’ları okur. Kimlik doğrulama gerektiren kısım bir tool’u çalıştırmaktır.

Claude Code, tarayıcıdan giriş

claude mcp add --transport http pinappai https://mcp.pinappai.com/mcp

Komutta anahtar yok. Client’ın ilk kullanımda, erişimi onaylaman için tarayıcıyı açar.

Claude Code, API anahtarı

claude mcp add --transport http pinappai https://mcp.pinappai.com/mcp --header "Authorization: Bearer ppk_SENIN_ANAHTARIN"

JSON config’i olan her client (Cursor ve benzerleri)

{ "url": "https://mcp.pinappai.com/mcp", "headers": { "Authorization": "Bearer ppk_SENIN_ANAHTARIN" } }

npm paketi (npx @pinappai/mcp) tam desteklenmeye devam ediyor: CI/headless kurulumlar, belirli bir sürüme pin’leme veya offline çalışmak için doğru seçim. Barındırılan endpoint ikinci bir bağlanma yolu, yerine geçen değil.

npm paketi

İki komut (Claude Code, Codex CLI, Cursor, Claude Desktop, Continue dahil tüm AI client’lar için aynı):

npx @pinappai/mcp install   # makinendeki her AI client config'ine MCP sunucu girişini yazar
npx @pinappai/mcp login     # tarayıcıyı açar, makineye özel anahtarı üretir ve yerel olarak kaydeder

install makinendeki tüm AI client config’lerine MCP sunucu girişini yazar (~/.claude.json, ~/.cursor/mcp.json, ~/.codex/config.toml, ~/.continue/config.yaml, ~/Library/Application Support/Claude/claude_desktop_config.json). Bu adımda kimlik bilgisi yazılmaz.

login ise tarayıcı sign-in akışı çalıştırır: bir URL + kısa bir onay kodu yazdırır, tarayıcını açar, birden fazla workspace’in varsa seçtirir ve üretilen API anahtarını makinende yerel olarak kaydeder. MCP sunucusu bir sonraki başlangıçta bu anahtarı otomatik alır.

ppk_… API anahtarı widget’ın pk_* anahtarından ayrıdır: workspace kapsamında bir makine kimliğidir ve yaptığı her çağrı, login’i onaylayan üyenin workspace rolüyle çalışır.

Altı CLI komutu:

Komut Amaç
npx @pinappai/mcp install MCP girişini her algılanan AI client config’ine yaz
npx @pinappai/mcp login Tarayıcı sign-in; makineye özel anahtarı üret + kaydet
npx @pinappai/mcp logout Anahtarı sunucu tarafında iptal et ve yerel credentials dosyasını sil
npx @pinappai/mcp uninstall MCP girişini AI client config’lerinden kaldır ve oturumu kapat (anahtarı iptal et + sil)
npx @pinappai/mcp --help Bu sürümün açtığı tüm workflow ve tool’ları yazdır
npx @pinappai/mcp --version Kurulu sürümü yazdır

--help canlı sunucuyu okur, yani her zaman elindeki sürümü anlatır. “Bu şey ne yapabiliyor?” sorusunun her client’ta ve her terminalde aynı çalışan tek cevabıdır.

Kurulumu doğrula

AI client’ını yeniden başlat, sonra ondan düz metinle iste:

pinappai projelerimi listele

Projelerinle cevap verirse sunucu bağlı ve kimlik doğrulaması tamam. Bu kontrol her client’ta çalışır, çünkü her client’ın uyguladığı tool’ları kullanır.

Doğrulamak için slash komutu yazma. Workflow’ların slash komutu olarak görünüp görünmediği tamamen client’ına bağlıdır; açılmayan bir slash komutu kurulumun çalışıp çalışmadığı hakkında hiçbir şey söylemez. Bkz. Workflow nasıl çalıştırılır.

CI / headless kurulum

Tarayıcı tabanlı login interactive olmayan bağlamlara uygun değil. MCP’yi başlatan ortamda PINAPPAI_API_KEY=ppk_… env değişkenini ayarla: MCP sunucusu önce env’i, sonra credentials dosyasını okur. Anahtarı app.pinappai.com/api-keys’den üret; sonradan temiz revoke için makineye / pipeline’a göre adlandır.

Manuel kurulum

Tek bir client’ı elle bağlamak istersen (ya da belirli bir version’a pin’lemen gerekiyorsa), install’ın senin için yazdığı per-client config snippet’leri:

Claude Code

claude mcp add-json pinappai '{"type":"stdio","command":"npx","args":["-y","@pinappai/mcp"],"env":{"PINAPPAI_API_KEY":"ppk_..."}}'

Cursor: ~/.cursor/mcp.json

{ "mcpServers": { "pinappai": { "command": "npx", "args": ["-y", "@pinappai/mcp"], "env": { "PINAPPAI_API_KEY": "ppk_..." } } } }

Claude Desktop: ~/Library/Application Support/Claude/claude_desktop_config.json

{ "mcpServers": { "pinappai": { "command": "npx", "args": ["-y", "@pinappai/mcp"], "env": { "PINAPPAI_API_KEY": "ppk_..." } } } }

Codex CLI: ~/.codex/config.toml

[mcp_servers.pinappai]
command = "npx"
args = ["-y", "@pinappai/mcp"]

[mcp_servers.pinappai.env]
PINAPPAI_API_KEY = "ppk_..."

Continue: ~/.continue/config.yaml

mcpServers:
  - name: pinappai
    command: npx
    args: ["-y", "@pinappai/mcp"]
    env:
      PINAPPAI_API_KEY: ppk_...

PINAPPAI_API_BASE opsiyoneldir; default değeri https://api.pinappai.com.

Workflow nasıl çalıştırılır

Workflow’lar MCP sunucusunun içinde gelir. Ek kurulum yok.

Nasıl çalıştırdığın client’ına bağlı. MCP spesifikasyonu bunu bilerek her client’a bırakır; yani her yerde çalışan tek bir sözdizimi yok. Kendi client’ını bul:

AI client’ın apply workflow’unu çalıştır
Claude Code /pinappai:apply yaz. /pinappai: yazınca menü açılır.
Codex Şunu iste: “pinappai apply workflow’unu çalıştır”. Codex prosedürü çeker ve uygular.
Continue (VS Code / JetBrains, agent mode) /apply yaz. Continue workflow’ları sunucu ön ekiyle listelemez.
Cursor / yaz ve menüden seç.
Claude Desktop + menüsü, sonra pinappai, sonra apply.
MCP bilen diğer her ajan Codex gibi, düz metinle iste.

apply yerine aşağıdaki herhangi bir workflow adını koy.

Bilinmesi gereken iki not. Codex workflow’ları slash komutu olarak hiç göstermez: orada /pinappai: yazmak Unrecognized command cevabı verir. Düz metinle istemek desteklenen yoldur ve aynı prosedürü çalıştırır. Continue workflow’lara ön ek koymaz, yani bizimkiler /apply, /remove gibi gelir ve senin kendi prompt dosyalarınla aynı menüyü paylaşır. Continue ayrıca workflow’ları yalnızca editör eklentisinde ve agent mode’da gösterir, cn CLI’ında değil.

Client’ının neyi desteklediğinden emin değilsen düz metinle iste. O yol her yerde çalışır.

10 workflow

Workflow Amaç
setup-project Sıfırdan yeni proje kur: workspace, proje, widget snippet, reviewer’lar. Kurulumsuz review linkini teklif eder ve iterasyon sınır marker’ını başlatır.
embed-widget Widget snippet’ini mevcut bir projenin sitesine göm ve marker’ı başlat: “AI için embed prompt’unu kopyala”nın MCP-native karşılığı.
apply Döngünün motoru. Inbox’ı boşaltır: yeni uygulamalar, reddedilenler için geri almalar, değişiklik istenenler için yeni metinler, sonra turu tek atomik batch’te uygulandı olarak işaretler, yol üstünde /changes/’i yeniler.
generate-changes-page Çok sayfalı bir toplu düzenleme için /changes/ inceleme sayfasını üret ve maddelerini kaydet: büyük bir rewrite’ın ilk sayfası için, ya da apply turu dışında sayfa istediğinde.
remove Yayına çıkarken widget + /changes/ + yardımcıları temizle. .pinappai/’i tekrar kurulum için saklar; review linkini de kapatmayı teklif eder.
analyze Mevcut CR yığını üzerinde sadece-okuma triyaj raporu (değişiklik yapılmaz).
summarize Tamamlanan işten PR açıklaması, changelog veya müşteri e-postası üret, orijinal CR’lara atıfla.
audit-review Workspace’in son denetim günlüğü etkinliğini özetle (Business katmanı; owner rolü).
auth-help Bir tool 401 veya 403 dönerse API anahtarı / rol / kapsam sorunlarını tanıla.
reset-project Bir projenin inceleme verisini sıfırla: sunucudaki CR’lar, kararlar, pin’ler, ekran görüntüleri; istersen repodaki /changes/ + marker da. Geri alınamaz; iki kez sorar.

/tr/mcp/ sayfasında öne çıkan beşi (setup-project, embed-widget, apply, generate-changes-page, remove) iteration döngüsünün ana akışına eşlenir: kur (ya da mevcut siteye göm), Inbox’ı uygula, inceleme sayfasını üret, yayına çıkarken kaldır. Diğer beşi daha az başvurduğun yardımcılar.

İteration döngüsü, tek bakışta

reviewer'lar canlı sitede değişiklik talebi pinler (#N atanır)


Inbox ──── apply workflow ────▶ InReview
  ▲                                 │
  │  Reject / Request change        ├── Approve → Closed
  └─────────────────────────────────┘

Her pin, dashboard Inbox’ına numaralı bir değişiklik talebi olarak düşer. Tek bir apply çalıştırması Inbox’ı boşaltır: ajan kaynağını düzenler, /changes/’i yeniden üretir ve turu kaydeder; uygulanan her CR InReview’a geçer. Reviewer kararları CR’ı ya kapatır ya da bir sonraki tur için Inbox’a geri gönderir: aynı CR, aynı #N. Ayrı bir triyaj töreni yoktur.

Tam durum modeli (alt durumlar, defer, reopen, first-action-wins) iterasyon döngüsü sayfasında.

.pinappai/ dizini

Repo kökünde küçük bir klasör. İterasyon döngüsü için taşıyıcıdır: commit’le, gitignore’a ekleme.

Dosya Amaç
.pinappai/last-applied.json İterasyon sınır marker’ı. Her apply çalıştırmasının sonunda yazılan ISO zaman damgası. Bir sonraki /changes/ regen “git log –since=” kapsamında çalışır.
.pinappai/context.json Proje şekli önbelleği: algılanan stack (Astro / Next / Hugo / vb.), build / lint komutları, kaynak dizini, route düzeni, yerelleştirme şekli ve text_lives_in (pages-inline / component-props / i18n-files / content-files / mixed). Bir kez kaydedilir, sonra her prompt yeniden algılamak yerine bunu okur.

İki dosya da minicik (birkaç yüz bayt). Commit’lemek, bir takım arkadaşının ilk MCP çalıştırmasının projenin şeklini zaten bilmesi demek: makine başına ikinci bir “stack’in ne?” turu yok.

.pinappai/ gitignore’daysa ya da working tree salt-okunursa prompt’lar bellek-içi algılamaya düşer: döngü yine çalışır, sadece daha az verimli.

Landing-chooser: AI asla otomatik commit’lemez

Repona dokunan her workflow (setup-project, embed-widget, apply, remove, reset-project) şu blokla biter:

✅ <tek satır özet>
Etkilenen dosyalar: <.pinappai/last-applied.json dahil liste>

Bunu nasıl commit'leyelim? Birini seç:

  (a) Yeni feature branch — önerilen ad: pinappai/<batch>-YYYY-MM-DD-HHMM
      Mevcut HEAD'inden branch açarım, TÜM etkilenen dosyaları
      commit'lerim, push edip etmemek senin kararın.
  (b) Mevcut branch'e commit — aynı commit, branch değişikliği yok.
  (c) Sadece stage — commit'lemeden bırakırım, önce diff'i incelersin.
  (d) Atla — git'e dokunmam, sen halledersin.

Önerilen commit mesajı: <prefix>(<scope>): <özet>

Hangi seçenek (a / b / c / d), push edilsin mi ve commit mesajında
değişiklik var mı — söyle. Bekliyorum.

Ajan sen seçene kadar orada durur. Sözleşme bu: sen seçmeden git add yok, git commit yok, git push yok. Branch korumasına saygı duyulur; --no-verify asla kullanılmaz. “Sen karar ver, yap gitsin” dersen default (b): mevcut branch’e commit + push yok.

Ön kontrol de kapsanır: kaynağa dokunan her prompt düzenlemeden önce git status + git branch --show-current çalıştırır. Kirli working tree → sessizce stash’lemek yerine diff’i gösterip sorar.

Sunucunun sunduğu tool’lar

Okuma + yazma yüzeylerinde 38 tool. Ajanın bunları çağırır; sen asla yazmazsın. En sık dokunacağın 6 read tool:

Tool Ne döner
list_projects API anahtarının görebildiği tüm projeler
list_change_requests Son geri bildirim satırları (pin’ler, yorumlar, kararlar) status / tür / sayfa filtreleri ve cursor sayfalamayla
get_change_request Tek satırın tam detayı: sayfa URL’i, selector, önce/sonra metni, reviewer, karar, ekran görüntüsü URL’i
get_review_summary Toplam sayılar: bekleyen vs karara bağlanan, approved/rejected/change-requested dağılımı, sayfa bazında döküm
get_screenshot Ekli ekran görüntüsünün PNG baytları, ajan için base64
analyze_patterns Kararlar genelinde reviewer’ların tutarlı reddettiği kalıplar (örnekli kümeler döner)

Workflow’ları taşıyan tek bir tool var:

Tool Ne yapar
pinappai_get_workflow Bir workflow’un tam prosedürünü metin olarak döndürür. Workflow’ları slash komutu olarak göstermeyen client’lar gerçek prosedürü böyle çalıştırır: ajan adından uydurmak yerine prosedürün kendisini çeker ve uygular. Codex’te “pinappai apply workflow’unu çalıştır” demeyi çalıştıran şey budur. Salt okunur.

Dört tool apply döngüsünü sürer (apply ve generate-changes-page workflow’larının perde arkasında çağırdıkları bunlar):

Tool Ne yapar
pinappai_list_apply_inbox Şu an Apply’a uygun her şey: yeni, reddedilen (geri alma gerek), değişiklik istenen (yeni metin gerek); ajanın kaynağı düzenlemesi için gereken alanlarla
pinappai_apply_change_requests Atomik tur-sonu çağrısı: CR başına önce/sonra çiftlerini alır, tek iterasyon kaydeder, her CR’ı tek batch’te InReview’a taşır
pinappai_register_change_items Yeni yazılmış bir /changes/ sayfasının maddelerini API’ye kaydeder: karar barları, sayfa-içi chip ve verdicts böyle canlanır
pinappai_reset_review_data reset-project workflow’unun arkasındaki nükleer seçenek: projenin CR’larını, kararlarını, pin’lerini ve ekran görüntülerini siler

İki tool daha apply geçmişini açar: pinappai_list_iterations (geçmiş turlar, dondurulmuş manifest’leriyle) ve pinappai_get_iteration_coverage (bu tur ne kadar tamam: karara bağlanan vs bekleyen, reviewer bazında).

Kalan 25 tool tam admin yaşam döngüsünü kapsar. Bu tabloyla 38’in tamamı listelenmiş oluyor:

Alan Tool’lar
Hesap & GDPR get_me, update_me_profile, export_my_data (Md. 15 dışa aktarım)
API anahtarları list_api_keys, get_api_key, revoke_api_key, restore_api_key
Workspace’ler list_workspaces, get_workspace, create_workspace, update_workspace, delete_workspace
Projeler get_project, create_project, update_project, archive_project, unarchive_project
Üyeler list_members, invite_member, update_member_role, remove_member
Reviewer’lar list_reviewers, invite_reviewer, revoke_reviewer
Denetim günlüğü list_audit_events (Business planı)

Her yazma, çağıranın rolüne göre kapılıdır: editor apply döngüsünü sürebilir ve /changes/ maddesi kaydedebilir ama üye davet edemez; admin kalıcı-silme hariç her şeyi yapabilir (o tasarım gereği admin-UI’da kalır).

Auth modeli

ppk_ anahtarlar tek projeye değil workspace’e kapsamlıdır: bir anahtar workspace’teki her projeye erişir. Her anahtarı bir workspace üyesi üretir ve yapılan her çağrı o üyenin güncel rolüyle çalışır (viewer / editor / admin / owner): viewer anahtarı yalnız okur; admin anahtarı tüm yaşam döngüsünü sürer. Üyenin rolü değişirse anahtarın erişimi de değişir; üye çıkarılırsa anahtar çalışmayı durdurur.

Bir ajanı ikinci bir workspace’e bağlamak için orada bir anahtar üret ve sunucuyu farklı bir adla tekrar ekle (ör. pinappai-staging). Birden fazla sunucu bir arada yaşayabilir; ajan doğal-dil bağlamına göre seçer.

Anahtarlar admin’den her an revoke edilebilir. O anahtarın bir sonraki MCP çağrısı 401 döner. Ajan bunu “erişimi kaybettim, yeni anahtar gerekli” olarak ele almalı.

Kaynak

Sunucu kaynağı ve changelog npm’de @pinappai/mcp altında. Hata raporları ve issue’lar projenin GitHub reposuna.