The Problem
ChatGPT is good at planning meals and bad at remembering your kitchen. Every conversation starts from zero: you re-list what’s in the fridge, forget the half jar of tahini, and get recipes that assume equipment you don’t own. The model needs a durable, user-owned record of what’s actually on hand, and it needs to update that record reliably when you say “I finished the rice” or “I bought two more cans.”
How It Works
Mise is a remote MCP server that ChatGPT connects to through OAuth. When you mention your kitchen, ChatGPT reads your saved inventory and makes changes through four tools: read_kitchen, add_items, edit_items, and remove_items. A small web app lets you log in, approve the connection, and correct anything by hand.
ChatGPT → OAuth-protected /mcp (Next.js on Vercel) → kitchen service → Postgres
Website → authenticated APIs → same service → same dataIt’s live as a private ChatGPT app that I use for my own cooking.
Evaluation-Driven Tool Design
The first version exposed 12 tools: separate create/update/delete per resource, quantity operations, batch adjustments, and receipt import. Additions and edits felt unreliable, so before adding features I built a way to measure it.
- Effect-based evals. Each scenario runs a model against a real MCP server and a local Postgres database, then checks the resulting inventory directly: exact final state, no forbidden writes, stable identities. A separate judge grades whether the final answer is grounded in what actually changed.
- Cut 12 tools to 4. The overlapping tools gave the model more to choose between without helping the workflow. Four composable tools keep the read/add/edit/remove boundaries users think in, and push batching and retries into the service. The final combined regression accepted 26 of 26 cases.
- Checked in the real host. A fresh multi-turn ChatGPT conversation covered adding, restocking, correcting quantities, removing finished items, and renaming equipment, with each answer verified against the database.
Reliability and Safety
- Retries don’t double-count. Every write carries a durable request identity, so a retried “I bought two cans” replays instead of adding four.
- Atomic batches. A grocery receipt of new items and restocks lands in one request, or not at all.
- Two layers of user isolation. Queries are scoped per user, and the app connects through a restricted database role without row-level-security bypass. Cross-user write attempts are covered by tests.
- Observable. OpenTelemetry traces correlate tool calls, HTTP outcomes, and latency in production.
Highlights
- Remote MCP server with OAuth, built on the MCP TypeScript SDK v2
- Tool surface reduced from 12 to 4 based on measured evals
- Idempotent, atomic writes with server-side quantity arithmetic
- Next.js 16, Supabase Postgres and Auth, deployed on Vercel