Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
作者による説明(英語の原文)
Manage and publish restaurant and local business websites through MCP.
この3つを1つのスコアにまとめることはしません。意見、測定、人気はそれぞれ別のものだからです。
このサーバーのやさしい解説はまだ書いていません。以下はレジストリから読み取った事実です。
使っているAIアプリを選んで、設定をコピーしてください。
必要なもの
どのアプリを使っていますか?
上でアプリを選んでください。選んだアプリを覚えておくので、次からはボタンに「…にインストール」と表示されます。
ウェブ、デスクトップ、モバイルのClaudeで使えます:
https://krabiclaw.com/api/mcpターミナルでこれを実行します
claude mcp add --transport http krabiclaw https://krabiclaw.com/api/mcpプロジェクトの .cursor/mcp.json、または ~/.cursor/mcp.json に貼り付けます
{
"mcpServers": {
"krabiclaw": {
"url": "https://krabiclaw.com/api/mcp"
}
}
}ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。
プロジェクトの .vscode/mcp.json に貼り付けます
{
"servers": {
"krabiclaw": {
"type": "http",
"url": "https://krabiclaw.com/api/mcp"
}
}
}ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。
ChatGPTがつなげるのは、インターネット上のサーバーだけです:
https://krabiclaw.com/api/mcpメニューの名前は、プランや時期によって少し違うことがあります。
選んだアプリは、この端末のCookieに保存されます。アカウントは不要です。
この設定は、作者のレジストリ登録情報から作成しています。READMEと違う場合は、READMEに従ってください。
このサーバーのツール一覧はまだ読み取っていません。エンドポイントは順番にチェックしています。
誰でも見られる情報をチェックしており、コードは読んでいません。当てはまらない項目は数に入れていません。 · 2026年11月6日にチェック
レジストリ名は、リポジトリを所有するGitHubアカウント krabiclaw で確認済みです
このリポジトリはまだGitHubから読み取っていません
このリポジトリはまだGitHubから読み取っていません
まだチェックしていません。エンドポイントは順番にチェックしています
まだチェックしていません。エンドポイントは順番にチェックしています
まだチェックしていません。エンドポイントをチェックするときにツール一覧を読み取ります
レジストリでこのカテゴリにある有効なすべてのサーバーと比較しています。スターは、公開者がリポジトリの所有者である場合だけ数えます。
当てはまる基本チェック1項目のうち1項目に合格しました。コードは読んでいません。キーやトークンを追加する前に、サーバーがどんなアクセスを求めているかを確認し、必要な権限だけを持つキーを使ってください。
レジストリには必須のキーは載っていません。ただし、最初に使うときにサインインを求めるサーバーもあります。
作者のクラウドで動きます。インストール不要でインターネット経由でつながりますが、送った内容は作者のサーバーを通ります。
GitHubリポジトリの最終更新は–、最新バージョン(1.0.0)がレジストリに届いたのは22 日前です。
Claude Desktop、Claude Code、Cursor、VS CodeなどのMCP対応アプリで使えます。URLでつながるので、リモートMCPサーバーに対応したアプリ(開発者モードのChatGPTなど)でも使えます。
同じカテゴリには:Spec Driven Development, Remote Desktop Commander, Reelsaw
同じカテゴリで、ほかの作者が作ったサーバー。スターの多い順。
カードの見方:★ GitHubスターi3つの柱:レビュー · チェック · 利用状況i更新=最新バージョンをレジストリに公開した日i
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Drive a self-hosted Reelsaw: turn long videos into vertical clips, edit, re-render and export them.
作者のリポジトリから書かれたとおりにコピーしたものです。PopNx MCPは内容を確認・推奨していません。HTML、画像、スクリプトは取り除いています。リンクはこのサイトの外へ移動します。
KrabiClaw runs the website, bookings, payments and messaging for restaurants, experience operators, law firms and lodging hosts, managed from the dashboard or from ChatGPT and Claude through one MCP service. Lodging includes homes, nightly availability and prices, direct stay bookings and guest messaging.
Open source under AGPL-3.0.
Nuxt 5 nightly + Nitro 3 + Cloudflare Workers + D1.
Package manager: yarn only. Never npm or pnpm.
| Command | What it does |
|---|---|
yarn dev | Nuxt development server with HMR and locally emulated Cloudflare bindings at http://localhost:3000. |
yarn local:setup | Reset local Wrangler state and migrate an empty local D1. |
yarn local:seed | Build the synthetic E2E businesses in the running local Worker. |
yarn dev:worker | Build and run the production-like Worker locally with Wrangler at http://localhost:3000. |
yarn dev:worker:start | Run the existing .output Worker build locally without rebuilding it. |
yarn build | Production build → .output/ |
yarn db:generate | Generate a new migrations/*.sql file from server/db/schema.ts |
yarn drizzle:check | Verify server/db/schema.ts hasn't drifted from the live D1 schema |
yarn stripe:listen | Forward Stripe webhooks to localhost (local dev only) |
yarn canary:prod | Production-safe authenticated browser canary (read-only checks). |
yarn canary:notifications | Production provider-level email/WhatsApp notification canary. |
Real-send production canaries are intentionally off on normal main deploys to avoid accidental email/WhatsApp spend on every merge. To run them on demand, use the GitHub Actions workflow Production Real-Send Canaries and choose whether to send:
That workflow always runs production smoke first, then only sends the real canaries you explicitly selected for that run.
See docs/notification-testing.md for the full policy on log-only vs live email/WhatsApp testing, production-safe verification, and which public submission paths send for real in production.
corepack yarn install
The repository uses Node.js 24.18.1. Use the exact version declared in .nvmrc before installing dependencies. When changing Node, follow the Node runtime upgrade runbook so local development, CI, type definitions, and Worker builds move together.
Yarn accepts new direct and transitive package releases only after seven days. Routine yarn add and yarn up commands apply this rule automatically. CI installs the package graph immutably and rechecks registry metadata in its hardened job.
For an urgent reviewed security fix, update only the affected package:
corepack yarn up <package>@<fixed-version> --no-time-gate
Record the advisory and the reason for bypassing the wait in the pull request. Do not add a package to npmPreapprovedPackages or disable the age gate in .yarnrc.yml.
Copy .env.example to .env and fill in the application secrets there. This is the single local configuration for Nuxt, Wrangler, setup scripts, and E2E tests. See local development for setup and migrating an older .dev.vars file. No second secret file or symlink is needed.
corepack yarn local:setup
It leaves an empty local D1 at the current migration. Start the app (step 4), then build the synthetic businesses Playwright also uses:
corepack yarn local:seed
Sign in at /login as platform-admin@playwright.example with E2E_PASSWORD from config/development-auth-fixtures.ts: a Better Auth admin who owns every seeded business.
corepack yarn dev
App at http://localhost:3000.
yarn dev is the normal application-development loop. Nitro reads the bindings declared in wrangler.toml, emulates local D1/KV/R2 resources, and preserves Nuxt hot module replacement. It never resets D1. Run corepack yarn local:setup and corepack yarn local:seed again to start over.
Open tenant dashboards from the dashboard UI instead of guessing their URLs. When a route must be constructed manually, the dashboard segment is the organization's slug, not its subdomain, and everything else sits directly under it: Kikuzuki's locations are /dashboard/org-bVY8SxxUuG6Ctk2CQnfCk8T2cPsj4jJX/locations.
For production-runtime browser verification, use the generated Worker locally. Wrangler reads the same .env as Nuxt. Playwright also loads it and supplies test-specific local URLs and delivery settings to the Worker.
yarn test:e2e:local tests/e2e/tenant-content.spec.ts
For a production-like local Worker:
yarn dev:worker
After a successful build, yarn dev:worker:start restarts that same .output without rebuilding. Source edits are not compiled into .output automatically; use yarn dev for the normal HMR editing loop.
Playwright applies the local D1 schema to an empty database, builds the Cloudflare Worker, starts it under local workerd, and seeds the synthetic businesses through the app's own boundaries (tests/e2e/seed). Authenticated tests sign in through Better Auth as the seeded fixtures; no email inbox or authentication bypass route is involved.
Local tenant tests use a shared-host routing contract: the browser targets localhost and the test helper supplies x-preview-tenant for the selected fixture. Deployed staging uses direct first-level tenant aliases instead. This is the authoritative local browser path; do not rely on direct *.localhost navigation for Worker browser verification.
http://localhost:3000/ (x-preview-tenant: harbor-legal)
http://localhost:3000/services (x-preview-tenant: harbor-legal) http://localhost:3000/experiences (x-preview-tenant: clayhouse) http://localhost:3000/reservations (x-preview-tenant: demo)
ulimit -n 65536
Deployment follows the branches in .github/workflows/ci.yml:
Checks and the E2E suite against a local Worker and a local D1 seeded with synthetic businesses (tests/e2e/seed). Nothing is deployed for a pull request, and no production data is read.staging run Checks, then deploy the staging Worker, apply staging migrations, and run read-only MCP and tenant rendering against staging itself. Nothing writes test data into real staging.main run Checks, then deploy the production Worker, apply production migrations, and run read-only production browser verification.CI invokes native Wrangler commands only in the matching branch job.
During an incident, use Cloudflare's deployment history to restore the last known-good production deployment without changing D1 data. Then land the source fix through staging and main and repeat the browser gates.
Production secrets live in the Cloudflare dashboard → Workers & Pages → krabiclaw → Settings → Variables.
Set protected internal job secrets with Wrangler:
openssl rand -base64 32
yarn wrangler secret put CRON_SECRET
CRON_SECRET protects internal scheduled endpoints. Local commands read their configuration from .env; deployed Workers use Cloudflare secrets and the variables in wrangler.toml.
MCP reconnect triage and Cloudflare auth debugging are documented in docs/observability.md.
The mandatory deployed-browser release gate and outage recovery rules are documented in docs/operations/release-and-outage-prevention.md.
server/db/schema.ts is the only schema source of truth; migrations/ holds generated output. Hand-written migrations are prohibited.
yarn stripe:listen
Copy the whsec_... signing secret it outputs into .env as STRIPE_WEBHOOK_SECRET. Swap back to the production webhook secret before deploying.
Native marketplace onboarding uses a separate Accounts v2 thin-event destination and signing secret. See Stripe Connect onboarding.