KrabiClaw

io.github.krabiclaw由 GitHub 账号 krabiclaw 发布v1.0.0更新于 Oct 24, 2026

Manage and publish restaurant and local business websites through MCP.

已验证Streamable HTTP可网页运行效率与工作流商业与电商

概览

AI 生成的概览

远程 MCP 服务，可从 ChatGPT 或 Claude 管理餐厅、体验项目、律所与住宿商家的网站、预订、支付和消息。

可以做什么
  • 管理和发布餐厅及本地商家网站。
  • 处理预订与预约，包括住宿的每晚房态、价格和直接住宿预订。
  • 处理支付以及面向住客或客户的消息沟通。
  • 既可在 KrabiClaw 后台操作，也可通过 MCP 服务由助手完成。
适用场景
适合在 KrabiClaw 上运营餐厅、体验项目、律所或住宿网站，并希望助手协助管理网站内容、预订、支付或消息，而不只在后台操作的用户。
运行要求
远程 MCP 端点 krabiclaw.com，使用 streamable HTTP，需要 OAuth 认证。需要拥有商家或组织的 KrabiClaw 账号；未声明环境变量或请求头。
安装前请注意
该服务涉及真实业务数据：网站、预订、支付和客户消息，助手操作可能发布内容、产生预订或发送消息。OAuth 授权会访问你的账号，支付流程涉及真实资金。连接前请确认助手可执行的操作范围。

安装

在 SourceWeft 中

  1. 打开 控制台中的 KrabiClaw，将其添加到工作区。
  2. 连接 所需的 凭据。它们会被私密存储，绝不会在公开页面上展示。
  3. 为需要使用其工具的对话启用该服务。

Web executable，通过 Streamable HTTP。 远程服务在工作区中配置后即可从网页运行时运行。

交给智能体安装

把这段提示词粘贴到 Claude Code、Codex、Cursor 等智能体，或 SourceWeft 对话中。智能体会读取该服务器的安装指南，先向你展示发布者、端点和登录方式，经你同意后再把它添加到你的客户端。密钥不会写进任何命令。

阅读 https://sourceweft.com/mcp/io.github.krabiclaw%2Fkrabiclaw/install.md，并按其中说明把这个 MCP 服务器接入我的客户端。修改任何配置之前，先告诉我它的发布者、端点和登录方式，等我确认。不要把 API 密钥写进命令或我会提交的文件；问我密钥应从哪里获取。

查看智能体所依据的安装指南

其他 MCP 客户端

把它添加到你客户端的 mcpServers 配置中。 客户端会在首次连接时完成 OAuth 登录。

{
  "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.

Nuxt 5 nightly + Nitro 3 + Cloudflare Workers + D1.

Package manager: yarn only. Never npm or pnpm.

Scripts

CommandWhat it does
yarn devNuxt development server with HMR and locally emulated Cloudflare bindings at http://localhost:3000.
yarn local:setupReset local Wrangler state and migrate an empty local D1.
yarn local:seedBuild the synthetic E2E businesses in the running local Worker.
yarn dev:workerBuild and run the production-like Worker locally with Wrangler at http://localhost:3000.
yarn dev:worker:startRun the existing .output Worker build locally without rebuilding it.
yarn buildProduction build → .output/
yarn db:generateGenerate a new migrations/*.sql file from server/db/schema.ts
yarn drizzle:checkVerify server/db/schema.ts hasn't drifted from the live D1 schema
yarn stripe:listenForward Stripe webhooks to localhost (local dev only)
yarn canary:prodProduction-safe authenticated browser canary (read-only checks).
yarn canary:notificationsProduction provider-level email/WhatsApp notification canary.

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

bash
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:

bash
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.

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

bash
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:

bash
corepack yarn local:seed

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

bash
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.

bash
yarn test:e2e:local tests/e2e/tenant-content.spec.ts

For a production-like local Worker:

bash
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.

text
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)

macOS file limit fix

bash
ulimit -n 65536

Deployment

Deployment follows the branches in .github/workflows/ci.yml:

  1. Pull requests run 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.
  2. Pushes to 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.
  3. Pushes to 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:

bash
openssl rand -base64 32yarn 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.

Schema

server/db/schema.ts is the only schema source of truth; migrations/ holds generated output. Hand-written migrations are prohibited.

Stripe (local)

bash
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.

来源：README.md，提交 31744dd

工具

0
该服务器需要登录，因此 SourceWeft 无法在没有账号的情况下读取其工具，也未收录。已连接账号所能看到的内容可能因账号及其权限而异。

版本历史

1
  1. v1.0.0最新Oct 16, 2026

评分

已满足适用检查项的 85%

该评分衡量此收录条目的完整程度，依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价，也不表示服务器安全或当前可用：可连通性是带日期的检查结果，评分也不包含安装量或用户评价。

  • 近 30 天内可连通必需25 分
  • 已声明认证方式必需10 分
  • 已列出工具15 分

    请让服务器在无凭据时响应 tools/list，或发布可在沙箱中无凭据启动的软件包。

  • 描述必需15 分
  • 图标10 分
  • 文档15 分
  • 许可证10 分