
KrabiClaw
io.github.paulchrisluke由 GitHub 帳號 paulchrisluke 發布v1.0.0更新於 Oct 11, 2026
Manage and publish restaurant and local business websites through MCP.
概覽
KrabiClaw 是託管的 MCP 服務,用來管理餐廳、住宿與在地商家網站,涵蓋預訂、付款與訊息溝通。
- 可以做什麼
- 管理與發布餐廳、體驗業者、律師事務所及住宿房東的網站
- 處理預訂、每晚空房與價格,以及直接住宿預訂
- 處理付款與旅客或客戶訊息
- 可在 KrabiClaw 儀表板操作,也可透過同一個 MCP 服務在 ChatGPT 與 Claude 中使用
- 適用情境
- 適合商家或營運者想讓助理協助打理 KrabiClaw 代管網站時使用,例如發布內容、調整空房與價格,或處理預訂與訊息而不必切換到儀表板。
- 執行需求
- 透過 streamable HTTP 連線到 krabiclaw.com 的遠端 MCP 端點;清單未宣告任何套件、環境變數或標頭。實際使用應需要 KrabiClaw 帳號與商家,但清單未宣告驗證方式。
安裝
在 SourceWeft 中
- 開啟 儀表板中的 KrabiClaw,將其新增到工作區。
- 為需要使用其工具的對話啟用該服務。
Web executable,透過 Streamable HTTP。 遠端服務在工作區中設定後即可從網頁執行環境執行。
交給代理程式安裝
把這段提示詞貼上到 Claude Code、Codex、Cursor 等代理程式,或 SourceWeft 對話中。代理程式會讀取該伺服器的安裝指南,先向你展示發布者、端點和登入方式,經你同意後再把它新增到你的客戶端。金鑰不會寫進任何命令。
閱讀 https://sourceweft.com/mcp/io.github.paulchrisluke%2Fkrabiclaw/install.md,並按其中說明把這個 MCP 伺服器接入我的客戶端。修改任何設定之前,先告訴我它的發布者、端點和登入方式,等我確認。不要把 API 金鑰寫進命令或我會提交的檔案;問我金鑰應從哪裡取得。其他 MCP 客戶端
把它新增到你客戶端的 mcpServers 設定中。
{
"mcpServers": {
"krabiclaw": {
"type": "http",
"url": "https://krabiclaw.com/api/mcp"
}
}
}README
KrabiClaw
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.
- Report a bug or request a feature: open an issue. Assistants filing for a user can prefill the form; see the field ids in .github/ISSUE_TEMPLATE.
- Account, billing or private data: krabiclaw.com/help.
- Security: SECURITY.md.
- Contributing: CONTRIBUTING.md.
Nuxt 5 nightly + Nitro 3 + Cloudflare Workers + D1.
Package manager: yarn only. Never npm or pnpm.
Scripts
Production Canary Runs
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:
- the auth OTP canary
- the notification email/WhatsApp canary
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.
Local Setup
1. 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:
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.
2. Environment
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.
3. Prepare local development
It leaves an empty local D1 at the current migration. Start the app (step 4), then build the synthetic businesses Playwright also uses:
Sign in at /login as [email protected] with E2E_PASSWORD
from config/development-auth-fixtures.ts: a Better Auth admin who owns every
seeded business.
4. Run
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.
For a production-like local 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.
macOS file limit fix
Deployment
Deployment follows the branches in .github/workflows/ci.yml:
- Pull requests run
Checksand theE2Esuite 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. - Pushes to
stagingrunChecks, 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. - Pushes to
mainrunChecks, 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:
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.
Schema
server/db/schema.ts is the only schema source of truth; migrations/ holds generated output. Hand-written migrations are prohibited.
Stripe (local)
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.
來源:README.md,提交 74574de
工具
0版本歷史
1- v1.0.0最新Sep 16, 2026
評分
已滿足適用檢查項的 50%
該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。
- 近 30 天內可連通必需25 分
請保持端點能夠回應 MCP 握手;SourceWeft 每 30 天探測一次。
- 已宣告認證方式必需10 分
請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。
- 已列出工具15 分
請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。
- 描述必需15 分
- 圖示10 分
- 文件15 分
- 授權條款10 分