u/zanni098

Demo above is the real app, not a mockup.

The idea: every tracker I tried wanted me to search a database, guess a portion, and log each ingredient. NutriSnap takes one photo, identifies each item separately with its own calorie/macro estimate, and shows totals, a health score and a confidence rating — then lets me correct servings before anything is committed. The model proposes, I decide.

The part I actually enjoyed building is the Wellness Agent. It treats the app's own features as callable tools and runs a Reason → Act → Observe loop over your eating history: it can plan, approve, warn, or outright block a meal, and generates a grocery list for the gaps it finds. Reproducible from the demo suite — burger against a declining week → BLOCK, salad → APPROVE, non-food image → BLOCK via guardrail.

Stack: Next.js, Gemini vision, on-device storage (works offline). The agent ships twice on purpose — a reference Python implementation and a TypeScript port so the deployed app runs it client-side with no backend.

Try it: https://nutrisnap-mocha-psi.vercel.app — mobile-first, no signup and no API key, tap a sample meal to see the full analysis.
Agent: https://nutrisnap-mocha-psi.vercel.app/agent
Code: https://github.com/zanni098/nutrisnap

Honest caveat: portion estimation from a single photo is inherently approximate — that's why confidence is shown and servings are editable. Happy to hear where it gets things wrong.

https://reddit.com/link/1vhxy5v/video/q3m82a3wvghh1/player

Demo above is the real app, not a mockup.

The idea: every tracker I tried wanted me to search a database, guess a portion, and log each ingredient. NutriSnap takes one photo, identifies each item separately with its own calorie/macro estimate, and shows totals, a health score and a confidence rating — then lets me correct servings before anything is committed. The model proposes, I decide.

The part I actually enjoyed building is the Wellness Agent. It treats the app's own features as callable tools and runs a Reason → Act → Observe loop over your eating history: it can plan, approve, warn, or outright block a meal, and generates a grocery list for the gaps it finds. Reproducible from the demo suite — burger against a declining week → BLOCK, salad → APPROVE, non-food image → BLOCK via guardrail.

Stack: Next.js, Gemini vision, on-device storage (works offline). The agent ships twice on purpose — a reference Python implementation and a TypeScript port so the deployed app runs it client-side with no backend.

Try it: https://nutrisnap-mocha-psi.vercel.app — mobile-first, no signup and no API key, tap a sample meal to see the full analysis.
Agent: https://nutrisnap-mocha-psi.vercel.app/agent
Code: https://github.com/zanni098/nutrisnap

Honest caveat: portion estimation from a single photo is inherently approximate — that's why confidence is shown and servings are editable. Happy to hear where it gets things wrong.

https://reddit.com/link/1vhxxs6/video/q3m82a3wvghh1/player

TL;DR: BirdEye is a local-first daemon + MCP gateway that every agent harness registers with once. After that, any agent in any harness shares the same memory, task queue, and encrypted secret vault. MIT, no cloud, no telemetry, binds 127.0.0.1 only. Looking for contributors — adapters are ~100 lines.

https://github.com/zanni098/BirdEye

The itch

I use Claude Code, Codex, and opencode depending on the task, and the same three problems kept biting:

• Memory doesn't travel. What one harness learned yesterday, the next one re-asks today.
• MCP servers get configured N times. github MCP was in four separate configs on my machine, each with its own token.
• Zero visibility. No way to answer "which harness can touch what, and how many tokens has each burned?"

The MCP part

The core of it is a stdio MCP server that exposes six tools:

You register it per-harness with one command (birdeye register claude-code), which writes a single entry into that harness's MCP config after backing up the original. From then on the agent inside any harness can read what an agent in another harness wrote — the interop lives in the MCP layer instead of in nine different config files.

The rest is around that: read-only adapters that scan 9 harnesses' on-disk state into one model, and a dashboard (memory graph, session timeline, an MCP/skills matrix that shows you the same server configured four times, a credential-key matrix, usage per harness).

Security model, since it touches your configs

• Daemon binds 127.0.0.1 only. No telemetry, no outbound calls.
• Adapters are read-only; scanning never writes to harness files.
• Credential values are never read — key names only. vault_get flows only over local stdio MCP.
• The only three writers (register, sync-env, memory sync-back) are explicit commands that make timestamped backups, and for context files only ever touch the <!-- BIRDEYE:START/END --> marker block.

Honest limits

• Usage stats depend on what each harness logs locally — rich for Claude Code and Codex, honest unknown elsewhere. It never invents numbers.
• Cursor/Continue keep chat data in app-internal storage, so those adapters are shallower.
• Dispatch needs the harness CLI on your PATH.
• Cross-harness collaboration is shared memory + shared queue. Automatic result-chaining (A's output feeds B's next task) is roadmap, not done.

Try it in 30 seconds

Needs Node ≥ 23.6 — the daemon runs TypeScript natively, no build step.

git clone https://github.com/zanni098/BirdEye.git
cd BirdEye && npm install && npm run build
npm run demo    # http://127.0.0.1:4477 with demo data — touches nothing of yours

Writing an MCP server by hand for every API got old, so I built a generator that does it from the spec:

pip install ducktap
ducktap press https://petstore3.swagger.io/api/v3/openapi.yaml --name petstore

Out comes an MCP server you can drop into Claude Desktop or Cursor, plus a CLI and an agent skill. The part I actually care about is that it's deterministic — it parses the spec and emits code, so there's no model deciding what your tools look like, no API key, and it runs in CI. Same spec, same server, every time.

It ships with 30 recipes (Stripe, GitHub, Linear, Notion, Slack, Twilio...) so ducktap press stripe just works.

Two things I'd like help with:

1. Break it. Point it at an API whose spec is weird and tell me what happened. That's the most useful thing anyone can do right now — most of my bug fixes have come from specs I'd never have thought to try.
2. The catalog. Adding an API is one YAML file. Airtable, Resend, Cloudflare, Render and Pinecone are each an open good first issue if you want an easy first PR.

Alpha and solo, so expect rough edges — but 150+ tests pass and it's on PyPI.

https://github.com/zanni098/DuckTap

If you maintain an MCP server for a public API, I'd genuinely like to know whether generated output gets close to what you hand-wrote, or whether it misses something structural.