Herdr UI
Herdr의 TUI가 뛰어나며, 창을 통해 추가되는 기능
kitchen은 클라우드플레어 기반 오픈소스 MCP 서버로 가정의 요리 도우미들이 레시피와 장보기록, 선호 음식 메모를 공유한다
kitchen is an open-source MCP server on Cloudflare that lets every cooking assistant in your household share recipes, one grocery list, and notes about what you like to eat.
개발 도구TypeScript · HTMLGitHub @lesentiel온라인운영자 미확인
써 보셨어요? 한 번만 눌러 주세요. 로그인은 필요 없어요.
아직 감지된 업데이트가 없습니다. GitHub 릴리스가 나오면 여기에 보입니다.
개인 계정의 공개 저장소 소유자는 GitHub로 로그인해 운영자를 확인하고 소개를 직접 관리할 수 있습니다. 관리자 승인은 필요하지 않습니다.
로그인한 뒤 확인 파일을 만들어 이 저장소의 기본 브랜치에 30분 안에 커밋해 주세요. 다른 브랜치나 포크의 파일은 인정하지 않습니다. 파일을 올린 뒤 아래에서 확인하면 관리자 승인 없이 관리할 수 있습니다. 자격을 유지하려면 파일을 남겨 두세요.
로그인이 필요하면 로그인 화면으로 이동합니다. 로그인 후 이곳으로 돌아와 원하는 확인 버튼을 다시 눌러 주세요.
프로젝트 폴더에서 /nomorevibe verify를 실행하면 소유권을 확인하고 소개를 직접 관리할 수 있습니다.
1분 만에 확인하기Self-hostable Cloudflare MCP server for a shared kitchen: recipes, groceries, and notes shared by two cook bots.
저장소 README에서 가져옴
README 전체를 불러오는 중입니다. 아래는 저장된 발췌입니다.
A shared kitchen for your cooking assistants. kitchen is a small, self-hostable remote MCP server on Cloudflare Workers + D1. Each person in a household connects their own AI cook bot (built for Grok bots; any MCP client works). The bots then share:
• Recipes: create, read, update (with conflict detection), delete, search.
• One grocery list: add items, check them off, remove them, clear checked items, add a recipe's ingredients in one call.
• Context notes: preferences, dietary needs, summaries of what someone discussed with their bot, meal plans. Each note records its author and timestamps.README 전문 보기 ↗A shared kitchen for your cooking assistants. kitchen is a small, self-hostable remote MCP server on Cloudflare Workers + D1. Each person in a household connects their own AI cook bot (built for Grok bots; any MCP client works). The bots then share:
Everything is an MCP tool. There's no web UI. Each member has their own revocable bearer token, and partners join with single-use invite codes.
The button has not yet been verified with this project's
cloudflare.config.ts(the project uses the newcfCLI rather than Wrangler). See open questions. The manualcf deploypath below is the reference.
Design notes (tool schemas, D1 schema, auth flow, trade-offs): docs/DESIGN.md.
KITCHEN_ADMIN_SECRET.https://<your-worker>/mcp without a token and calls create_kitchen with that secret. It gets back a token for you.Authorization: Bearer <token>. Call invite_member, which returns a code like KTCH-7QX4-M9PB-2RZD (single use, 60 minutes by default).redeem_invite with the code. It gets back its own token.Lost or leaked token? Call rotate_token. Remove someone? Call revoke_member.
cf CLI comes as a dev dependency: pnpm exec cf …, or npx cf …pnpm install
cp .dev.vars.example .dev.vars # set KITCHEN_ADMIN_SECRET to anything for local use
pnpm dev # cf dev → http://localhost:5173/mcp
The Worker creates its D1 tables on the first request, so there's no migration step. Local data lives in .cloudflare/state. Delete that folder to start over.
Run the end-to-end sample session against the dev server (create kitchen → invite → redeem → recipe → groceries → note → read back as the partner):
pnpm sample-session # or: node scripts/sample-session.ts http://localhost:5173/mcp
Explore by hand with the MCP Inspector: npx @modelcontextprotocol/inspector, Streamable HTTP, URL http://localhost:5173/mcp, then add an Authorization: Bearer … header once you have a token.
pnpm test # Vitest 4 + @cloudflare/vitest-pool-workers: runs inside workerd with a real D1
pnpm typecheck # cf workers types && tsc
pnpm install
pnpm exec cf auth login
pnpm run deploy # cf deploy: builds, provisions the "kitchen" D1 database, uploads
pnpm exec cf workers secrets update KITCHEN_ADMIN_SECRET --worker kitchen --text "$(openssl rand -base64 32)"
Alternatively, put KITCHEN_ADMIN_SECRET=… in a file and pass it at deploy time with pnpm exec cf deploy --secrets-file <file>. Keep the secret somewhere safe: anyone who has it can create kitchens on your server.
The schema is applied by the Worker on its first request (src/migrate.ts), using the same d1_migrations bookkeeping as cf d1 migrations apply, so you don't need to look up the database ID.
The intended production deployment is https://kitchen.lesentiel.com/mcp. That domain is attached only in the lesentiel mode:
pnpm run deploy:lesentiel # cf deploy --mode lesentiel
For your own domain, edit the domains line in cloudflare.config.ts. The zone must be on the account you deploy to. A plain pnpm run deploy stays on *.workers.dev.
plugin/ is a Grok plugin: an MCP server config plus a skill that teaches Grok the setup flow and tools. Install it with grok plugin install lesentiel/kitchen#plugin --trust, then set KITCHEN_TOKEN (and KITCHEN_MCP_URL if you self-host). See plugin/README.md. Validate changes with grok plugin validate plugin.
Any MCP client that supports remote Streamable HTTP servers with custom headers:
https://<your-worker-or-domain>/mcpAuthorization: Bearer kit_… (omit it only for create_kitchen / redeem_invite)The server speaks the 2026-07-28 MCP protocol and also serves 2025-era clients statelessly.
cloudflare.config.ts cf config: D1 binding, secret, domain (generated by `cf init`, then extended)
migrations/ D1 schema (applied by the Worker at runtime; compatible with `cf d1 migrations`)
src/index.ts fetch entry: homepage at /, bearer auth, MCP handler at /mcp
site/index.html the one-page homepage (bundled into the Worker)
src/server.ts MCP tools and zod schemas
src/{kitchen,recipes,grocery,notes}.ts data access, always scoped to the caller's kitchen
test/ Workers-runtime tests
scripts/ sample session
plugin/ Grok plugin (manifest, .mcp.json, skill)
docs/DESIGN.md design and decisions
MIT