DEV Community: Daniel Ainoko

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

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`