DEV Community: Daniel Ainoko

I Taught a Security Camera to Say "I Don't Know" — and It Got More Useful, Not Less

Daniel Ainoko — Mon, 20 Jul 2026 20:05:37 +0000

Somewhere around day four of building a doorbell-camera AI for a hackathon,
I caught my own system lying to me. Not maliciously — it was just guessing,
the way all of us do when we don't want to say "I don't know" out loud. The
fix for that turned out to be more interesting than anything else in the
build, so this post is mostly about that, with some genuinely funny/painful
bug stories along the way.

The problem nobody built a camera to solve

Every doorbell camera on the market answers one question: was there
motion? That's the wrong question. The right question — the one a human
actually wants answered at 11pm when their phone buzzes — is should I
care about this? Cameras don't answer that, so people train themselves to
swipe the notification away without looking. The alert becomes noise. The
one time it isn't noise, you've already stopped paying attention.

So the project — I called it Kenbunshoku (見聞色, roughly "the art of
perceiving," a term from certain martial traditions for reading a
situation before it becomes obvious) — tries to add one missing layer:
context. Not "something moved." Something closer to "a person in a
delivery uniform is standing at your door with a package," or "someone is
lingering by the entrance at an unusual hour without a clear reason to be
there."

The architecture, in one breath: a local YOLOv8n detector watches a camera
stream and only forwards frames that actually contain a person. Those
frames go to a cloud backend that calls Qwen-VL (Alibaba Cloud's
vision-language model) to reason about what's actually happening in the
image. A lightweight memory layer checks whether this is a recurring
pattern. A push notification goes to the homeowner's phone with the
reasoning attached, in plain language. That's the whole system. No part of
it ever acts on your behalf — no locks, no alarms, no calls to anyone. It
tells you things. You decide.

That last sentence is doing more work than it looks like, and I'll come
back to it.

Here it is actually running, filmed on my phone with zero production
values whatsoever — a real detection, a real Qwen-VL classification, a
real push notification landing on a real device:

https://youtu.be/6j4ZZhUeahY

(Judge the system, not the cinematography.)

The lie I caught it telling

Early on, the classification prompt just asked Qwen-VL to look at a frame
and decide: is this person "familiar," "delivery-like," or "anomalous"? I
tested it against a deliberately ugly, blurry, low-detail image — barely a
silhouette — expecting either a refusal or an honest "unclear." Instead I
got:

"familiar" — "...suggesting they are a known individual."

Read that again. The model had no reference photo of anyone who lives at
this house. It had never seen this "known individual" before in its
existence. It could not possibly know that. And yet it produced a
confident, specific, entirely fabricated claim of recognition — because I
had asked it a question shaped like an identity question, and it answered
in kind, filling the gap with plausible-sounding language instead of
admitting the gap existed.

This is, if you squint, the exact same failure mode as a person who
doesn't want to look uninformed in a meeting. The information isn't
there, but the shape of a confident answer is easy to produce, and
confident-shaped answers get rewarded more often than "I don't know"
ones — right up until the moment they're wrong in a way that matters.

The fix wasn't a bigger model or a longer prompt lecture. It was
redefining what "familiar" was even allowed to mean:

"familiar" means the visit presents as expected and low-concern —
calm demeanor, ordinary daytime approach, no unusual items — not that
you recognize the person's identity. You have no reference photos.

And one more line that did almost all of the actual work:

If the visual evidence doesn't clearly support "familiar" or
"delivery-like," choose "anomalous" rather than guessing.

Same blurry test image, same model, new prompt:

"anomalous" — "The image is too blurry to determine any clear
behavior, carried items, or context, making it impossible to classify
as familiar or delivery-like."

That's not a worse answer. It's a categorically more honest one. The
model went from confabulating a memory it didn't have to correctly
reporting the limits of what it could see. For a home security system,
"I'm not sure, so I'm erring cautious" is strictly better than a
confident wrong guess in either direction — and it only took giving the
model permission to say so.

Refusing to build the "creepier, more expensive" version

The natural next question, if you're chasing "familiar" as identity
recognition, is: why not just do real face matching? Store embeddings,
compare against known visitors, get an actual identity-confidence score
back.

I sat with that question for a while and landed on: no, deliberately,
permanently, not out of laziness but out of principle.

Here's the reasoning. A system that stores biometric-adjacent data about
everyone who walks up to your door is a fundamentally different kind of
object than one that doesn't — different risk if it leaks, different
ethical weight, different relationship to the people it observes (some of
whom never consented to being in anyone's facial recognition database,
let alone a hackathon project's). And critically: it wasn't necessary. The
actual product need — "don't wake me up for the same delivery guy every
Tuesday" — is fully satisfied by a much cheaper, much more honest
mechanism: pattern-matching on visits, not identity.

The memory layer just asks: has this camera seen a similar classification,
on the same day of week, at a similar time, repeatedly, in the last two
weeks? If yes, that's a "recognized pattern" — still logged, but the push
notification gets quietly suppressed instead of buzzing your phone for the
fifth Tuesday in a row. If a genuinely unrecognized, anomalous visit
happens even in a pattern-matched slot, it still gets through — the system
never goes quiet on "anomalous," patterned or not.

This costs nothing extra. No embeddings, no vector database, no additional
model calls, no image storage beyond what's needed for the one live
classification. It's just a SQLite table and a modest SQL query. And it
never claims to know something it doesn't. "This time slot has a routine"
is a true, verifiable, honest claim. "I recognize this specific human
being" is not a claim this system is entitled to make, so I made sure it
never could.

Cheap and honest turned out to be the same design decision twice.

Restraint as the actual feature

The system never takes autonomous action. Not "rarely" — never, as a hard
rule I refused to relax even when it would have been a more impressive
demo. No auto-locking doors on "anomalous," no auto-calls to anyone, no
control signal of any kind, ever. Just a notification with reasoning
attached, to a human, who decides.

It would be easy to read that as a limitation — "the AI could do more but
we held it back." I'd argue the opposite: the restraint is the design.
A system that watches your front door and occasionally gets it wrong (all
of them do) is tolerable precisely because the cost of being wrong is "a
slightly annoying notification," not "the system did something to a real
door because a vision model was 73% confident." Keeping a human in the
loop isn't a feature you bolt on later. It's the thing that makes
everything upstream of it — including the confident-sounding mistakes —
survivable.

The bugs that only existed once I stopped trusting the diff

Every single one of these passed a code review. All of them looked fine on
the page. None of them were fine.

An em dash crashed a push notification. The alert title used a plain em dash for style. HTTP header values have to be ASCII/latin-1. The request didn't fail loudly in a way that pointed at the cause — it just threw a UnicodeEncodeError deep inside a networking library, the first time a real alert actually tried to fire. Nothing about the code looked wrong.
A mobile OS silently ate all outbound network traffic. The notification client connected to nothing, showed no error, gave no signal that anything was wrong — because macOS's App Sandbox was quietly blocking every request at the entitlement level, before it ever reached a socket. Android had the mirror-image problem: no INTERNET permission declared, same silent nothing. Static analysis had nothing to say about either one. Only running the actual app on actual hardware surfaced them.
The camera loop got stuck reprocessing the past. Point the camera at your hand, then a pen, then your face — and the system kept reporting the pen. Not broken, exactly: cv2.VideoCapture buffers incoming frames faster than a multi-second classification round-trip can drain them, so the loop was dutifully working through a growing backlog of old frames while the live scene moved on without it. The fix was a background thread that keeps only the newest frame and lets everything older get silently, deliberately discarded — the standard answer to this exact class of problem, but only obvious once you've watched it happen with your own hand in front of your own camera.
The system got slower the more careful it became. A single request was quietly doing two sequential network calls before responding — one to the vision model, one to the push service — with no timeout set on either. Most of the time it was fine. Occasionally, both hops had a slow moment at once, blew past the timeout budget, and the system fell back to a generic "cloud unreachable" alert instead of the real classification it had actually computed a few seconds too late.

None of these are exotic. Every one of them is a well-known category of
bug with a well-known fix. What they have in common is that reading the
code gave no signal anything was wrong. The only way to find any of them
was to run the actual thing, on actual hardware, against an actual
network, and watch it fail in front of me.

The recursive part

I built this with an AI pair programmer doing most of the typing. There's
an irony there I didn't fully appreciate until I was three days in:
I spent this entire project teaching one AI system to stop confidently
guessing and start admitting uncertainty — while collaborating, in real
time, with a different AI system whose suggestions also needed
constant grounding against reality rather than being trusted on the
strength of how plausible they sounded. Code that compiles is not code
that works. A plan that reads well is not a plan that survives contact
with a real phone, a real Alibaba Cloud console, a real curl command
against a real server.

The throughline for the whole build, human-authored parts and
AI-authored parts alike, ended up being the same single sentence: verify
against reality, not against your own confidence. That sentence is the
entire fix for the "familiar" hallucination. It's the entire fix for
every bug in the list above. It's also, probably, decent advice for
anyone shipping anything, with or without a vision model attached.

Kenbunshoku was built for the Global AI Hackathon Series with Qwen
Cloud, running on Alibaba Cloud ECS with Qwen-VL for visitor reasoning.
Camera-agnostic by design, human-in-the-loop by principle, and — as of
this week — a little more honest about what it doesn't know.

Gemma-San — A Teacher in Every Pocket.

Daniel Ainoko — Tue, 19 May 2026 19:33:57 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

Gemma-San is an offline AI tutor for children aged 5–12, built for Nigerian kids first but speaking whatever language the child speaks. It runs Google's Gemma 4 E2B model fully on-device on a sub-$200 Android phone — no cloud, no data plan after the one-time setup.

A child taps the mic, talks (English, Pidgin, Yoruba, Hausa, Igbo — even Japanese), and Gemma-San responds with voice, illustrations, and patience. It knows when to ask a Socratic question and when to just explain. It remembers the child across sessions. It quizzes them on past lessons. It draws simple SVG diagrams when the topic isn't already in its illustration library.

Built with Flutter + flutter_gemma 0.15.1 + Whisper.cpp + sqflite. Targets 4–6 GB RAM Android phones like the Tecno Spark 10 and Infinix Hot 30 — the phones African kids actually share with their families.

The problem it solves: millions of kids in low-bandwidth regions have brilliant questions and no one to ask. Cloud tutors fail when the network does. Gemma-San lives inside the phone.

Core features:

Voice in (Whisper tiny on-device) → Gemma 4 → voice out (Android TTS)
Six native function-calling tools: socratic_teach, direct_teach, encourage, remember, try_drawing, show_illustration
22 hand-built SVG illustrations + an on-the-fly SVG drawing fallback
Five-question quizzes and phonics practice with a spaced-repetition scheduler
A three-tier memory system (working window + cross-session compaction + long-term facts) so the tutor knows the child
Multilingual mirroring — the model replies in whatever language the child used, never imposes one

Demo

Code

TheCodeDaniel / gemma_san

Gemma-San

Offline AI tutor for Nigerian children, powered by Gemma 4 on-device.

Hackathon submission — deadline May 18, 2026.

What It Is

Gemma-San is a native Android app that acts as a patient, voice-first tutor for Nigerian children aged 5–12. It runs Google's Gemma 4 E2B model entirely on-device using flutter_gemma, so it works in classrooms with no internet after the initial model download. The tutor speaks in Nigerian Pidgin or English, uses the phone camera to annotate physical objects, and adapts to each child via a local memory system.

Why

Millions of Nigerian children lack access to quality, personalized tutoring. Gemma-San brings Socratic and direct-teach pedagogy to a $100 Android phone, offline, in the child's own language.

Architecture

┌─────────────────────────────────────────────┐
│                Flutter UI                   │
│  (Riverpod state, feature-first widgets)    │
└────────────────────┬────────────────────────┘
                     │
        ┌────────────▼────────────┐
        │     Domain / Use Cases  │
        └────────────┬────────────┘
                     │
   ┌─────────────────┼──────────────────┐
   │                 │                  │
┌──▼──┐         ┌────▼────┐       ┌────▼────┐
│sqflite│       │flutter_

…

View on GitHub

How I Used Gemma 4

Model: Gemma 4 E2B (litert-community/gemma-4-E2B-it.litertlm).

Why E2B and not E4B or 31B Dense: E4B added roughly 1.5 GB to disk and tripped the OOM killer on my 8 GB target device once Whisper.cpp loaded alongside it. 31B Dense was never an option — these are phones, not workstations. E2B's 2-billion effective parameters fits in about 2.4 GB on disk, runs at ~25–35 tok/s on the GPU backend via LiteRT-LM, and leaves headroom for STT/TTS/UI. The quality-vs-fit tradeoff was the entire bet.

Native function calling — six tools, no plain text

Every model reply is a function call. There is no free-text path. The system prompt has a Khanmigo-style decision tree the model walks top-down on every turn (visual request → illustration if exact match else SVG → direct fact → Socratic ladder → escalate after 2 IDKs). Side effect: the UI gets a structured TutorResponse with a mode field, so I render a different colored mode pill for each teaching style.

Selective thinking mode (the biggest discovery)

Gemma 4 supports thinking traces via enableThinking: true. I assumed "more thinking = better answers" and switched it on everywhere. That backfired.

Where thinking helps: routing across 6 tools. Without it (and with default topK=1), once Gemma's first JSON token commits, it can't recover.

Where thinking hurts: structured-output composition. My lesson-summary path enabled thinking and the model started spending its whole token budget on <|channel>thought|> traces, never reaching the actual lesson_summary function call. Raw thinking JSON leaked into the cached summary and rendered to kids as {"role":"assistant","channels":{"thought":"Thinking"}}.... Beautiful.

I now apply thinking per-path:

Path	Thinking	Reason
`generate()` chat	ON	6-tool routing benefits from reasoning
`generateWithImage()`	ON	Vision + routing
`generateLessonSummary()`	OFF	Single tool, pure composition

And I always pass explicit sampling — the defaults are a trap for small models:

final session = await model.createSession(
  tools: tools,
  systemInstruction: sysPrompt,
  enableThinking: true,
  temperature: 0.4, // not 0.8 default — too noisy for tool selection
  topK: 40,         // not 1 default — pure greedy locks in wrong tools
  topP: 0.9,
  randomSeed: 1,
);

Compressing the prompt for a 2B model

My first system prompt was 1,450 tokens — a beautifully written teaching ladder. Gemma E2B's attention horizon couldn't hold it together with 6 tool schemas and conversation history. It misrouted, hallucinated tool names, and sometimes emitted plain text.

Rewriting it as a flat ~440-token decision tree with two worked examples (one Socratic, one direct-teach with the child speaking Pidgin and the model mirroring it back) took tool-call accuracy from "frustrating" to "actually usable."

Multilingual mirroring

Hard rule in the prompt: whatever language the child uses, the model uses back. English in, English out. Pidgin in, Pidgin out. Yoruba, Hausa, Igbo, Japanese — match it. The language_code BCP-47 field on every tool call propagates to Android TTS so the voice matches too (Google TTS preferred when installed; en-NG > en-GB > en-US fallback).

Recovery loop, never an error

When parsing fails (rare, but real on a 2B model), Gemma-San retries once with a nudge appended — "Respond by calling exactly ONE function. No plain text." — and falls back to a graceful direct_teach if the retry also fails. The child never sees an error message.

Lessons Learned

Thinking mode is a knife, not a hammer. ON for routing. OFF for composition. Mixing them in the same session causes JSON leaks and budget exhaustion.
topK=1 + thinking is the worst sampling combo on a small model. Pure greedy decoding can't recover from a bad first token even when the thinking trace has already considered alternatives. Bump topK to ~40 and temperature to ~0.4 for tool calling.
Compress your prompt brutally. A 2B model with 6 tool schemas + working memory + a 1,400-token system prompt has nothing left for attention. A flat Khanmigo-style decision tree with one or two worked examples beats verbose pedagogy every time.
Validate, don't reject. My SVG validator auto-fixes the model's malformed viewBox, injects missing fill attributes, and only rejects what truly can't render. Treat the model as a fragile partner, not a black box.
Mirror, don't impose. Telling the model "respond in Pidgin" forced bad output when kids spoke English. Telling it "mirror the child's language" produced fluent code-switching across five Nigerian languages out of the box.

Built for the Gemma 4 Challenge. Feedback welcome — especially from anyone shipping on-device LLMs for low-resource contexts.

From Notion Page to Figma Screens in Seconds

Daniel Ainoko — Sat, 28 Mar 2026 19:29:38 +0000

I Turned Notion Into a UI Design Tool — Claude Reads Your Page and Draws the Screens in Figma

This is a submission for the Notion MCP Challenge

What I Built

NotionCanvas MCP — a Model Context Protocol server that creates a live pipeline from your Notion workspace directly into Figma.

You write your app idea, feature spec, or product requirements in Notion — the way you normally would. Then you tell Claude:

"Read my Notion page and generate a mobile UI design in Figma"

And it does. Fully. Screens appear in Figma.

No Figma experience required. No prompt engineering. No copy-pasting. No manually describing your idea to an AI. Your Notion page is the brief — and NotionCanvas turns it into a real, editable UI in seconds.

The Problem It Solves

Every product builder knows this moment: you have a clear idea written up in Notion — user flows, feature descriptions, screen names, content — and then you spend the next hour either:

Trying to describe that same idea to an AI image generator with mixed results
Opening Figma and building frames manually from scratch
Hiring a designer and waiting days for a first draft

The idea is already written. Why describe it again?

NotionCanvas closes that gap entirely. Your Notion page is the single source of truth — and Claude bridges it to Figma automatically.

How It Works

The system has three parts working together:

Your Notion Page
      │
      ▼
  notioncanvas-mcp  (Node.js MCP Server)
      │
      ├── Notion API  →  reads your page content
      ├── Claude API  →  interprets it, generates a Design IR (structured JSON)
      └── WebSocket   →  sends commands to the Figma Bridge Plugin
                                  │
                           Figma Desktop
                      (NotionCanvas Bridge Plugin)
                          draws frames on canvas

Step 1 — Notion Reader: Reads your page recursively — headings, paragraphs, lists, callouts, properties — and builds a clean structured content object.

Step 2 — Claude Interpreter: Claude receives the Notion content + your design preferences (mobile/web, theme, color, design system) and outputs a Design Intermediate Representation (DIR) — a validated JSON schema describing every screen, every component, every coordinate, every color.

Step 3 — DIR Validator: Zod validates every component before anything touches Figma. Malformed AI output never reaches the canvas. Claude gets up to 2 automatic retries with targeted error feedback.

Step 4 — Figma Writer: The MCP server sends each screen to the Figma Bridge Plugin over a local WebSocket. The plugin executes Figma Plugin API calls — createFrame(), createText(), createRectangle() — and your screens appear live on the canvas.

What It Can Generate

From a single Notion page, NotionCanvas produces:

Full mobile screens (390×844) or web layouts (1440×900)
Text components with font weight, size, alignment
Input fields with placeholder text
Buttons with variants (primary, secondary, ghost, destructive)
Frames with Auto Layout support (vertical/horizontal, padding, spacing)
Rectangles with stroke, fill, corner radius
Every component positioned absolutely with proper coordinates
Background colors derived from your brand description

All components land in Figma as native, editable nodes — not images, not embeds. You can grab any element and keep designing from there.

The 6 MCP Tools

Tool	What it does
`generate_ui_design`	Full pipeline: reads your Notion page → Claude → Figma screens
`generate_screen`	Single screen from a plain-text description (no Notion needed)
`notion_read_page`	Read and return structured content of any Notion page
`notion_read_db`	Query a Notion database and return all entries
`list_figma_frames`	List all existing frames in a Figma file
`get_design_status`	Check if the Figma Bridge Plugin is connected and ready

Real Example

I wrote this in Notion:

"I want a simple ride hailing application. Main color theme is red. Use Inter font."

That's it. Two sentences.

NotionCanvas read that page, sent it to Claude, generated a full DesignIR with an onboarding screen, a home screen with a map layout, a booking screen with input fields and a confirm button — and sent all of it to Figma as native frames.

The whole pipeline ran in under 90 seconds.

Video Demo

Watch on YouTube

Show us the code

GitHub: github.com/TheCodeDaniel/notion_canvas

Project structure

notioncanvas-mcp/
├── src/
│   ├── index.ts                    ← MCP server entry point (stdio transport)
│   ├── clients/
│   │   ├── notion.ts               ← Notion API + p-queue rate limiter (2.8 req/s)
│   │   ├── claude.ts               ← Claude API + JSON retry logic (3 attempts)
│   │   ├── figma-ws.ts             ← WebSocket bridge server (localhost:9223)
│   │   └── figma-rest.ts           ← Figma REST API (read-only frame listing)
│   ├── interpreter/
│   │   ├── schema.ts               ← Zod DesignIR schema (5 component types)
│   │   └── prompt.ts               ← Claude system/user prompt builders
│   ├── tools/                      ← 6 MCP tools
│   ├── types/                      ← TypeScript interfaces
│   └── utils/                      ← logger, retry, PAT expiry checker
└── plugin/
    ├── manifest.json               ← Figma plugin manifest
    ├── plugin.js                   ← Figma Plugin API (main thread)
    └── ui.html                     ← WebSocket iframe (relay bridge)

Setup is one command after filling your `.env`

npm install
npm run build
npm run setup   # auto-detects Claude Desktop config path, merges entry, resolves absolute paths

The setup command handles everything:

Reads credentials from your .env
Detects claude_desktop_config.json path for macOS or Windows
Creates the file if it doesn't exist
Merges the notioncanvas entry without touching your other MCP servers
Auto-resolves the absolute path to dist/index.js — nothing to edit manually

Stack

TypeScript / Node.js — ESM, strict mode
@modelcontextprotocol/sdk — MCP server with stdio transport
@notionhq/client — Notion API with p-queue rate limiting
@anthropic-ai/sdk — Claude API (claude-sonnet-4-6)
ws — WebSocket server for the Figma bridge
zod — DesignIR schema validation before any Figma writes
Figma Plugin API — native canvas writes via the bridge plugin

How I Used Notion MCP

Notion MCP is the foundation that makes this whole idea possible — and not in a trivial way.

Why Notion as the input source is actually powerful

Most AI design tools start with a blank text box. You describe your idea to the AI. The AI designs something. But that description lives nowhere — it's not connected to your roadmap, your feature specs, your user stories. It's a one-off prompt.

Notion changes that. Your product thinking already lives there. Feature specs, screen flows, content requirements, user personas — structured, searchable, shareable with your team. With Notion MCP as the reader, that existing knowledge becomes the direct input to the design pipeline.

You're not describing your idea to an AI. You're pointing an AI at your idea. That's a fundamentally different workflow.

The specific integration

I used the Notion internal integration token (via @notionhq/client) to:

Read pages recursively — the client traverses the full block tree, handling pagination (100 blocks per request), nested toggles, callouts, lists, and all block types. Pages with hundreds of blocks are handled cleanly.
Query databases — the notion_read_db tool lets you pull structured data from Notion databases and feed it into screen generation. Imagine a database of app screens with properties like "screen type", "primary action", "user role" — and generating each one automatically.
Handle the page-sharing security model correctly — Notion's integration tokens only work on pages explicitly shared with the integration. The server returns a helpful, specific error message when a 404 is returned, rather than a generic failure.

What Notion MCP unlocks that nothing else does

The pipeline means your Notion page becomes a living design brief. Update the page — run the tool again — get updated screens. It's not a one-time export. It's a repeatable process driven by the content you're already maintaining.

For solo founders, indie developers, and small product teams who live in Notion: this means going from written idea to visual screen without leaving your workflow or learning Figma from scratch.

That's the unlock. Notion stops being a notes app and starts being a design input system.

Built with Claude Code, @modelcontextprotocol/sdk, @notionhq/client, and the Figma Plugin API.
Stack: TypeScript · Node.js · WebSockets · Zod · claude-sonnet-4-6

I Built an MCP That Publishes Your Blog to Every Platform With One Sentence to Claude

Daniel Ainoko — Sat, 28 Mar 2026 00:27:55 +0000

This is a submission for the Notion MCP Challenge

What I Built

Every developer I know has the same problem. They write a solid post, spend 20 minutes formatting it for Dev.to, copy-paste to Hashnode, re-upload the images that broke because Notion's CDN URLs expire, then give up on Medium entirely. The writing was the easy part. The publishing killed the momentum.

BlogCast MCP fixes that.

It's an open-source MCP server + dashboard that turns Notion into a publishing hub. Write once — in Notion or in the built-in rich text editor — then tell Claude to publish it everywhere.

"Publish my TypeScript post to Dev.to and Hashnode"

That's it. One sentence. Done.

What it actually does:

Publishes to Dev.to, Hashnode, and Medium simultaneously
Handles Notion's expiring image URLs automatically (downloads → caches → re-uploads to each platform's CDN)
Adapts content per platform — Medium gets clean HTML, Dev.to/Hashnode get optimized Markdown
Syncs analytics back into Notion (views, reactions, comments — all in one place)
Schedules posts via Claude: "Schedule my React post for tomorrow at 9am UTC"
AI pre-publish checks — catches missing excerpts, vague titles, broken formatting before you hit send
Auto-configures Claude Desktop — no JSON editing required

The whole thing runs locally. No third-party servers, no SaaS fees, no data leaving your machine. Your API keys are stored encrypted on your device.

Video Demo

Show us the code

GitHub: github.com/TheCodeDaniel/blogcast_mcp

Built as a proper monorepo — three packages that work together:

Package	What it does
`mcp/`	MCP server — the Claude integration layer
`server/`	Express backend — publishing, image caching, AI, scheduling
`client/`	React dashboard — write, publish, manage everything visually

Stack: TypeScript, Node.js, Express, React, Vite, TipTap editor, Anthropic SDK, Notion API.

How I Used Notion MCP

Notion sits at the center of this whole thing — not as a passive database, but as the living CMS.

The MCP server talks to Notion directly via @notionhq/client. When Claude calls publish_post, the server reads the Notion page blocks, converts them to Markdown using notion-to-md, handles all the images, pushes to each platform, then writes the results back into Notion — a linked Analytics database that tracks views, reactions, and comments per platform.

The Notion integration does five specific things:

Posts database — every draft, scheduled post, and published article lives here. Status, tags, platforms, canonical URL — all tracked as Notion properties.
Analytics database — a relational table linked to Posts. Every publish result is logged: URL, status (Success/Failed), and synced stats from each platform's API.
Auto-migration — on first run, BlogCast patches both databases automatically. New user? You don't set up a single column manually. Just share your databases with the integration and BlogCast does the rest.
Two-way sync — sync_analytics pulls the latest numbers from Dev.to and Hashnode back into Notion. Your post performance dashboard lives where you already work.
Scheduling — set Scheduled At in Notion (or via Claude: "schedule this for Friday 9am"), and the backend polls every N minutes to auto-publish when the time comes.

The MCP layer is what makes Claude feel like a natural publishing assistant rather than a chatbot bolted onto a dashboard. You're not filling out forms — you're just talking.

"Show me what's in Review" → list_drafts
"Preview my latest draft" → preview_post
"Publish the TypeScript one to all platforms" → publish_post
"What's the view count on my last post?" → sync_analytics + get_publish_status

Everything that used to take 30 minutes of copy-paste and re-uploading now takes one message.

I Got Tired of Cold Outreach. So I Made Claude Do It.

Daniel Ainoko — Thu, 26 Mar 2026 13:49:37 +0000

I Built an MCP That Turns Claude Into a Cold Outreach Machine — and It Actually Works

Submitted for the Notion MCP Challenge 2026

Let me be honest with you.

Cold outreach is broken.

Not because the idea is bad — cold emails work. People get hired, land clients, and build relationships through cold outreach every single day. It's broken because of how long it actually takes to do it right.

Think about it. To send one good cold email, you have to:

Find a company that's actually a fit for your skills
Go to their website and actually read it
Figure out what they're working on, what problems they might have
Find a contact email somewhere on the site
Write something that doesn't sound like everyone else's template
Send it
Log it somewhere so you don't forget who you've reached out to

That's 20–40 minutes. Per company.

If you do 10 companies — which is barely enough to move the needle — you've just burned a full workday on outreach alone.

So most people don't do it. Or they send lazy, generic emails that get deleted in two seconds. Both outcomes are bad.

I got tired of it. So I built something.

Demo

What I Built: Cold Outreach MCP

Cold Outreach MCP is a custom MCP server that turns Claude into a fully automated cold email agent. You paste your CV once. Claude does everything else.

Here's the exact flow:

You: "Here is my CV. Find 10 companies that match my background,
      research each one, and show me your recommendations."

Claude: [researches 10 companies]

      1. stripe.com → opportunity_pitch
         "Their checkout onboarding has friction — matches your UX background"

      2. linear.app → role_inquiry
         "Fast-growing team, strong eng culture, no obvious gap spotted"

      ... 8 more

You: "Looks good. Send as recommended."

Claude: [generates 10 tailored emails, sends them, logs everything to Notion]

That's it. What used to take a full day now takes 3 minutes.

The Part That Actually Makes It Different

Most "automation" tools skip the part that matters most — the email itself.

They send templated garbage like:

"Hi [First Name], I came across [Company] and I was really impressed by your work in [Industry]. I think my background in [Skill] could add value to your team..."

Nobody replies to that. Everybody knows it's a template. It goes straight to the bin.

Cold Outreach MCP does something different. Before generating the email, Claude actually reads the company's website, identifies specific things about their product or team, and writes something that references what it found:

"Saw you're building a design system at scale — I've done exactly this at [Company] and ran into the same versioning problems you're probably hitting. Worth a quick chat?"

That's an email someone opens. That's an email someone replies to.

And the tone rules are hard-coded into the prompts:

Under 120 words
No buzzwords ("synergy", "leverage", "circle back" — all banned)
Short sentences. Casual but not sloppy.
One specific observation from their site
One clear ask at the end

It sounds like a person wrote it. Because an extremely good AI was told to write like a person.

Where Notion Fits In

Every outreach — sent, failed, or pending — gets logged to a Notion database automatically.

The schema looks like this:

Company	Website	Email	Type	Status	Date Sent	Notes
Stripe	stripe.com	hello@stripe.com	opportunity_pitch	sent	2026-03-26	full email body
Linear	linear.app	team@linear.app	role_inquiry	sent	2026-03-26	full email body

No manual logging. No "I think I emailed them last week?". No spreadsheet.

And the Notion integration is set up like a proper database migration — you create an empty database on Notion, paste its ID in your config, run setup_notion_db once, and all the columns are provisioned automatically. It's exactly how backend migrations work.

The 10 Tools Under the Hood

Tool	What it does
`setup_notion_db`	Migrates your Notion database — adds all required columns
`parse_profile`	Extracts structured profile from your CV text
`discover_companies`	Finds real companies that match your skills using Claude
`find_company_email`	Scrapes a company site to find a contact email
`research_company`	Analyzes a company — summary, pain points, recommended email type
`generate_email`	Writes a human-sounding outreach email
`send_email`	Sends via SMTP (Gmail, Outlook, anything)
`log_to_notion`	Logs a record to your Notion tracker
`retry_failed`	Re-attempts any failed sends automatically
`bulk_outreach`	Full pipeline for up to 15 companies at once

It's Human-in-the-Loop by Design

This is important. The tool doesn't just fire off emails without asking you.

bulk_outreach runs in two phases:

Phase 1 — Claude researches all companies and returns its recommendations. You see everything before a single email is sent.

Phase 2 — You confirm (or override) each recommendation. Then and only then does Claude generate and send.

You're always in control. The AI is doing the tedious work, not making the decisions for you.

There's also a hard limit of 15 companies per run — enough to be productive, not enough to accidentally spam half the internet if something goes wrong.

Tech Stack

MCP SDK — @modelcontextprotocol/sdk (official Anthropic SDK)
AI — Claude via @anthropic-ai/sdk with adaptive thinking for research and email generation
Scraping — axios + cheerio for website analysis and email extraction
Email — nodemailer with lazy SMTP validation (server doesn't crash if SMTP isn't configured yet)
Notion — raw Notion REST API (fetch directly to https://api.notion.com/v1/...) for reliability
Language — TypeScript, Node.js 18+, ES modules

What the Setup Looks Like

git clone https://github.com/thecodedaniel/cold-outreach-mcp
cd cold-outreach-mcp
npm install && npm run build

Fill in your .env:

ANTHROPIC_API_KEY=sk-ant-...
NOTION_API_KEY=ntn_...
NOTION_DATABASE_ID=your_database_id
SMTP_HOST=smtp.gmail.com
SMTP_PORT=587
SMTP_USER=you@gmail.com
SMTP_PASS=your_app_password
SENDER_EMAIL=you@gmail.com
SENDER_NAME=Your Name

Add to Claude Desktop config. Restart. Done.

The full setup takes about 10 minutes if you already have the API keys.

The One Thing I'm Most Proud Of

It's not the scraping. It's not the Notion integration. It's not even the email generation.

It's the fact that you don't have to know which companies to target.

Every other tool in this space assumes you already know who you want to reach out to. You still have to do the research, compile the list, find the websites.

This one starts from your CV and figures out the rest. You describe what you do. Claude figures out who needs someone like you.

That's the part that changes things.

What's Next

Web search integration for real-time company discovery (Brave Search API)
Follow-up email scheduling ("no response in 7 days → send a nudge")
Notion status tracking — mark a reply directly in Notion, trigger a follow-up draft
LinkedIn integration for finding decision-maker contacts

DEV Community: Daniel Ainoko

I Taught a Security Camera to Say "I Don't Know" — and It Got More Useful, Not Less

The problem nobody built a camera to solve

The lie I caught it telling

Refusing to build the "creepier, more expensive" version

Restraint as the actual feature

The bugs that only existed once I stopped trusting the diff

The recursive part

Gemma-San — A Teacher in Every Pocket.

What I Built

Demo

Code

TheCodeDaniel / gemma_san

Gemma-San

What It Is

Why

Architecture

How I Used Gemma 4

Native function calling — six tools, no plain text

Selective thinking mode (the biggest discovery)

Compressing the prompt for a 2B model

Multilingual mirroring

Recovery loop, never an error

Lessons Learned

From Notion Page to Figma Screens in Seconds

I Turned Notion Into a UI Design Tool — Claude Reads Your Page and Draws the Screens in Figma

What I Built

The Problem It Solves

How It Works

What It Can Generate

The 6 MCP Tools

Real Example

Video Demo

Show us the code

Project structure

Setup is one command after filling your .env

Stack

How I Used Notion MCP

Why Notion as the input source is actually powerful

The specific integration

What Notion MCP unlocks that nothing else does

I Built an MCP That Publishes Your Blog to Every Platform With One Sentence to Claude

What I Built

Video Demo

Show us the code

How I Used Notion MCP

I Got Tired of Cold Outreach. So I Made Claude Do It.

I Built an MCP That Turns Claude Into a Cold Outreach Machine — and It Actually Works

Demo

What I Built: Cold Outreach MCP

The Part That Actually Makes It Different

Where Notion Fits In

The 10 Tools Under the Hood

It's Human-in-the-Loop by Design

Tech Stack

What the Setup Looks Like

The One Thing I'm Most Proud Of

What's Next

Links

Setup is one command after filling your `.env`