Forem: Ed G

not-claw: A Personal AI Agent That Lives in Telegram and Thinks in Notion

Ed G — Sun, 29 Mar 2026 17:32:32 +0000

This is a submission for the Notion MCP Challenge

What I Built

not-claw is a self-hosted AI agent that talks to you on Telegram and uses Notion as its entire brain, memory, skills, tasks, and identity, accessed through the Notion MCP server.

Inspired by OpenClaw, the open-source personal agent framework that stores state as Markdown files on disk, not-claw replaces that flat-file layer with Notion. The agent reads a Soul page to know who it is. It reads a Memory page to remember what it's learned. It queries a Skills database for instructions on how to do things. It manages a Tasks database as its work queue. Every 30 minutes, a heartbeat wakes it up to work through pending tasks without being asked.

The entire agent state is visible and editable in Notion. You can open the Skills database on your phone, write a new instruction, and the next time the agent runs it'll use it. You can see exactly what happened on every heartbeat in the log. Nothing is locked in a proprietary format, it's just Notion pages.

The agent also knows your timezone (configured via TIMEZONE in .env), so every prompt includes the exact local time.

The stack: Anthropic SDK for reasoning (Sonnet for interactive chat, Haiku for heartbeats — both configurable via MODEL_INTERACTIVE and MODEL_HEARTBEAT in .env), @notionhq/notion-mcp-server for Notion access via MCP, @modelcontextprotocol/sdk for the MCP client, and grammy for the Telegram bot.

Video Demo

Watch a brief demo on YouTube

Show us the code

grzetich / not-claw

not-claw

A personal AI agent that lives in Telegram and thinks in Notion.

Inspired by OpenClaw — but instead of Markdown files on disk, the agent's entire brain is a Notion workspace accessed through the Notion MCP server. Soul, memory, skills, tasks, and heartbeat logs are all Notion pages and databases that both you and the agent read and write to.

How it works

You (Telegram)
      |
      v
 +-----------+     MCP (stdio)     +---------------------+
 |  Gateway   | ----------------->  |  Notion MCP Server  |
 | gateway.js |     Agent loop      | @notionhq/          |
 +-----------+  <-  agent.js  ->    |  notion-mcp-server   |
      ^                             +---------+-----------+
      |                                       |
 +-----------+                                v
 | Heartbeat |  <- node-cron         Notion Workspace
 |heartbeat.js|   (every 30 min)     - Soul page
 +-----------+                       - Memory page
                                     - Skills DB
                                     - Tasks DB
                                     - Heartbeat log

You message the bot on Telegram
The gateway passes your message to the agent loop (agent.js)
Claude reads…

View on GitHub

Core files:

File	What it does
`mcp-client.js`	Spawns the Notion MCP server as a stdio subprocess, discovers 22 tools at startup, bridges tool calls between Claude and Notion
`agent.js`	Agentic loop — sends messages to Claude with MCP tools, executes tool calls, feeds results back, repeats until done
`gateway.js`	Telegram bot (grammy) — relays messages between you and the agent, owner-only auth
`heartbeat.js`	Cron job that wakes the agent every 30 minutes to work the task queue
`index.js`	Entry point — boots gateway, heartbeat, and reminders together

How I Used Notion MCP

Notion MCP is the foundation of the entire system. The agent has zero hardcoded Notion API calls. Every read, write, search, and update goes through MCP tool calls that Claude discovers and invokes on its own.

Connecting to Notion MCP

At startup, mcp-client.js spawns the official @notionhq/notion-mcp-server as a stdio subprocess:

import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";

const transport = new StdioClientTransport({
  command: "npx",
  args: ["-y", "@notionhq/notion-mcp-server"],
  env: {
    ...process.env,
    OPENAPI_MCP_HEADERS: JSON.stringify({
      Authorization: `Bearer ${process.env.NOTION_API_KEY}`,
      "Notion-Version": "2022-06-28",
    }),
  },
});

const client = new Client({ name: "not-claw", version: "1.0.0" });
await client.connect(transport);
const { tools } = await client.listTools();
// → 22 tools: API-post-search, API-get-block-children,
//   API-patch-page, API-query-data-source, etc.

These 22 tools are converted to Anthropic tool-use format and passed to Claude. Claude decides which tools to call, in what order, with what arguments. The MCP client executes them and returns results. The agent code is just the loop — Notion MCP does the heavy lifting.

What Notion MCP unlocks

Notion as the agent's operating system. OpenClaw uses a directory of Markdown files (SOUL.md, MEMORY.md, skills/*.md). not-claw replaces all of it with Notion pages and databases:

OpenClaw	not-claw (via Notion MCP)
`SOUL.md`	Soul page — agent identity, personality, owner context
`MEMORY.md`	Memory page — long-term facts, appended each session
`skills/` directory	Skills database — each page = one skill with instructions
Task queue	Tasks database — status, priority, notes, timestamps
Heartbeat log	Heartbeat database — record of every proactive run

Self-improving agent. Because Notion MCP gives full read/write access, the agent can write new skill pages back to the Skills database. Tell it "figure out how to summarize a webpage and save it as a skill" — it writes the instructions to Notion, and every future session can use that skill. This is the OpenClaw self-improvement loop, rebuilt on Notion.

Proactive work via heartbeat. Every 30 minutes, a cron job fires. Before calling Claude, it does a pre-check: queries the Tasks database directly via MCP (no Claude call, $0 cost). If nothing is pending, it skips entirely. If there are tasks, it runs the agent using Haiku (~60x cheaper than Sonnet) to pick up the highest-priority task, do the work, update the task status, log the run to the Heartbeat database, and message you the result on Telegram. Interactive messages still use Sonnet for quality. You didn't ask it to do anything — it just checked Notion and got to work.

Two-way collaboration, not just a chatbot. Because the brain is in Notion, you and the agent are equal participants in the same workspace. Tell the bot to add a task via Telegram, then open Notion later to add details, reprioritize, or mark it done yourself. Write a skill page directly in Notion and the agent uses it next session. Edit the Memory page to correct something the agent got wrong. Add tasks straight to the database and the heartbeat finds them. The data isn't locked behind the bot — Notion is the shared workspace, and both you and the agent read and write to it.

The agentic loop

The loop in agent.js is simple because MCP handles the complexity:

Connect to Notion MCP, discover tools
Send user message + tools to Claude
If Claude calls tools → execute via MCP client, feed results back, repeat
If Claude returns text → send to user via Telegram

Claude typically makes 3-8 tool calls per interaction: read Soul, read Memory, search Skills, then do whatever the user asked (create a task, query the database, update a page, etc.).

git clone https://github.com/grzetich/not-claw
cd not-claw
npm install
# See NOTION_SETUP.md for workspace configuration
# Set TIMEZONE in .env to your IANA timezone (e.g. America/New_York)
npm start

How I Built a Contamination-Free API to Test AI Doc Formats

Ed G — Tue, 03 Mar 2026 17:13:19 +0000

If you test how well AI tools use Stripe's API docs, how do you know what you're measuring? The AI might be reading your docs, or it might be drawing on patterns it already learned. You can't tell. That's the contamination problem, and it almost killed this research before it started.

The problem with popular APIs

When I set out to test whether documentation format affects AI code generation, the obvious approach was to use a well-known API. Stripe, Twilio, GitHub. Pick one, document it in different formats, generate code, compare the results.

Then I thought about it for five minutes and realized the whole thing was flawed.

Every popular API is everywhere. GitHub repos, Stack Overflow answers, blog tutorials, coding bootcamp projects, YouTube walkthroughs. All of that is in the training data for every major AI model. When you ask Claude or GPT-4o to generate Stripe integration code, some unknown percentage of its output comes from memorized patterns, not from reading the documentation you gave it.

That means you can't isolate the variable. You're not measuring "how well does the AI read this documentation format." You're measuring some unknowable mix of documentation comprehension and training data recall. The results would be meaningless.

The solution: build something that doesn't exist

The fix was straightforward in concept: build APIs that have never existed on the public internet. No GitHub repos. No Stack Overflow questions. No tutorials. No training data exposure of any kind.

I built two of them.

The first is BookClub, a book club management API with 6 endpoints. Members, books, meetings, notes. Simple enough that even a small model should be able to generate working integration code, but with enough structure to test real patterns like nested resources and input validation.

The second is EventForge, an event management API with 10 endpoints. This one is intentionally more complex: HMAC webhook verification, cursor-based pagination, PATCH operations for partial updates. The kind of patterns that stress-test whether a model truly understands the documentation or is just pattern-matching.

Two APIs at different complexity levels let me ask a question that one API alone can't answer: does the relationship between format and code generation change as the API gets harder?

Why two complexity levels matter

If I'd only built BookClub, I might have concluded that documentation format doesn't matter much. The simple API is forgiving. Most models, most formats, most of the time, it works.

EventForge tells a different story. When you push the complexity up, the cracks in certain formats become visible. Patterns that were fine for a 6-endpoint API fall apart on a 10-endpoint API with authentication, pagination, and partial updates. The interaction between format and complexity is where the most important findings live.

Same information, four formats

With the APIs built, I documented each one in four formats: YAML, OpenAPI 3.0, a novel format I created called DON (Documentation-Optimized Notation), and Markdown. Every format describes the exact same endpoints with the exact same parameters and the exact same constraints. The only thing that changes is how the information is structured.

This is critical. If the formats contained different information, you couldn't attribute differences in code generation to format. The four docs are informationally identical. They differ only in structure, verbosity, and notation.

The test harness

For each combination of API, format, and model, I ran integration tests. Give the model a documentation spec and a task ("write a function that adds a book to the club"), capture the generated code, and test whether it actually works against the live API.

Temperature set to 0.0 across all runs to minimize randomness. Multiple runs per combination to check for consistency. Over 21,000 total test executions across four AI models, from local models you can run on a laptop to frontier cloud APIs.

The result is a dataset where every variable is controlled except the one I'm testing. When the generated code differs between formats, I know the format caused it.

What contamination-free data lets you see

With clean data, patterns emerge that would be invisible in a contaminated test. You can see exactly how a model responds to the documentation in front of it, without the noise of prior training on the same API.

Some of those patterns were surprising. Some confirmed what I expected. All of them required contamination-free data to be credible.

The full findings are in the book. But the methodology point stands on its own: if you're testing how AI tools interact with documentation, you need to control for training data contamination. Otherwise you're measuring the model's memory, not its comprehension.

The full results, including what those patterns actually are, are coming in Tokens Not Jokin', out this month.

Try the free Docs Cost Calculator →

Get the book on Leanpub →

The Problem Nobody's Measuring

Ed G — Wed, 25 Feb 2026 15:48:37 +0000

Your company tracks API latency, uptime, error rates, and developer satisfaction scores. But nobody's tracking what it costs AI tools to read your API documentation.

Open your observability dashboard. You can probably see API response times broken down by endpoint. Error rates by status code. Maybe even developer satisfaction from your last survey. If you're sophisticated, you're tracking time-to-first-hello-world for new integrations.

Now tell me: how many tokens does it cost an AI coding tool to read your API docs?

You don't know. Nobody does. There's no dashboard for this. No metric.

The invisible transaction

Every time a developer points Cursor, Copilot, or Claude at your API documentation, a transaction happens. The AI tool reads your docs, converts them into tokens, and uses those tokens to generate integration code. The format of your documentation determines how many tokens that costs.

This isn't theoretical. If your docs are in a verbose format, the AI tool consumes more of its context window just reading the spec. That leaves less room for reasoning, for the developer's project context, and for generating quality code. In the worst case, the documentation fills so much of the context window that the model can't produce working code at all.

And it compounds. Every endpoint. Every developer accessing your docs. Every day.

Why nobody's noticed

Documentation has traditionally been measured by human metrics: readability, completeness, accuracy, time-to-find-information. Those metrics still matter. But they're designed for a world where humans are the primary (or only) consumers of your docs.

That world is shifting. AI coding tools are increasingly the first reader of your API documentation. The developer asks the tool to integrate with your API, and the tool goes and reads your docs before generating code. The developer may never visit your docs site at all.

When the primary consumer changes, the metrics need to change too. But the tech writing community hasn't caught up. We're still optimizing for human readability while AI tools are silently consuming our docs in a completely different way, and paying a cost that nobody sees.

The format question

Here's what makes this interesting: the same API information, documented in different formats, produces different token costs. Sometimes dramatically different. Two docs describing the exact same endpoints, the exact same parameters, the exact same constraints, but one could cost significantly more tokens than the other.

That raises an obvious question: does the format also affect the quality of the code the AI generates? Or just the cost?

And a harder question: if you tried to test this with a popular API like Stripe's, how would you know whether the AI is reading your docs or just drawing on patterns it already learned from training data? Every popular API is all over GitHub, Stack Overflow, and tutorial sites. You can't isolate the variable.

What I'm doing about it

I've been researching this for the past year. I built two control APIs from scratch, APIs with no public footprint and no prior exposure in any training dataset. I documented each one in four different formats and ran over 21,000 integration tests across four AI models, from local models you can run on a laptop to frontier cloud APIs.

Clean data. No contamination question.

The results are coming in a book called Tokens Not Jokin', out in March. But you don't have to wait for the book to start understanding the problem.

See what your docs cost. I built a free calculator that shows the token cost of your API documentation in real time. Paste your spec, see the numbers. It runs entirely in your browser.

Try the Docs Cost Calculator →

Pre-order the book on Leanpub →

Building a WebMCP Kanban Board: Browser-Native AI Integration With Zero Backend

Ed G — Mon, 23 Feb 2026 02:10:19 +0000

A complete implementation of a kanban board with 8 AI-callable tools, connected to Claude through Chrome DevTools MCP. No backend. No database. No API server.

What is WebMCP?

WebMCP is a W3C draft browser API that lets websites register tools AI agents can discover and call -- directly through the browser. The API surface is navigator.modelContext: a standard interface where web applications declare structured tools, and any conforming AI agent can invoke them without proprietary bridges, plugins, or server-side orchestration.

The spec is still a draft, but the @mcp-b/global polyfill makes it usable today. A website registers its tools at page load, an agent discovers them via navigator.modelContext.tools, and calls them with structured input. The return value is plain JSON.

This post walks through a complete implementation: a kanban board built as a pure client-side React app with 8 AI-callable tools, connected to Claude through Chrome DevTools MCP. No backend. No database. No API server.

Why a Kanban Board?

Three properties make a kanban board unusually effective for demonstrating WebMCP.

Visible state changes. When an AI agent creates a card or moves it between columns, the result is immediately visible. The agent writes to React state, React re-renders, and the card appears on screen in the same frame. You watch the agent work in real time.

Rich, composable tools. A kanban board supports more than simple CRUD. The 8 tools compose into multi-step workflows: read the board, create cards, add labels, move cards between columns, summarize a column, reprioritize by urgency. This demonstrates that WebMCP can support genuine agent autonomy over non-trivial application state.

Zero backend. All state lives in React Context and persists to localStorage. You run npm run dev and the entire system is live. This is not a limitation -- it is the point. WebMCP's strength is that the agent interacts with application state directly in the browser.

Architecture

The entire system has four layers. The React app and WebMCP tools run in a single browser tab. The Chrome DevTools MCP server is the bridge that lets Claude reach them.

graph LR
    subgraph "AI Client"
        Claude["Claude Code / Desktop"]
    end

    subgraph "Bridge"
        Server["Chrome DevTools<br/>MCP Server"]
    end

    subgraph "Browser Tab"
        Polyfill["@mcp-b/global<br/>(navigator.modelContext)"]
        Tools["WebMCPTools.jsx<br/>(8 tools via useWebMCP)"]
        Store["React State<br/>(Context + useReducer)"]
        Board["Board / Column / Card<br/>(UI Components)"]
        LS["localStorage"]

        Polyfill --- Tools
        Tools -->|"reads via stateRef"| Store
        Tools -->|"dispatches actions"| Store
        Board -->|"reads"| Store
        Board -->|"dispatches"| Store
        Store <--> LS
    end

    Claude <-->|"stdio<br/>(JSON-RPC)"| Server
    Server <-->|"CDP<br/>(DevTools Protocol)"| Polyfill

The key insight: WebMCPTools.jsx and the Board component tree are peers. They share the same store. The board renders state for humans; the tools expose state for AI agents. Both read from the same context and dispatch the same reducer actions.

The 8 Tools

Tool	Description
`get_board`	Returns the full board state: all columns, all cards, their positions, and labels.
`create_card`	Creates a new card in a specified column with a title and optional description.
`move_card`	Moves an existing card to a different column by card ID and target column.
`update_card`	Updates a card's title, description, or other mutable properties.
`delete_card`	Removes a card from the board entirely.
`add_label`	Attaches a label (e.g., "bug", "feature", "urgent") to an existing card.
`get_column_summary`	Returns an AI-friendly summary of all cards in a given column.
`prioritize_column`	Reorders cards within a column based on priority ranking.

Implementation

State Management

The store uses React's built-in useReducer wrapped in a Context provider. No Redux, no Zustand, no external state library.

const initialState = {
  columns: ["backlog", "todo", "in-progress", "done"],
  columnMeta: {
    backlog:       { title: "Backlog",     color: "gray"   },
    todo:          { title: "To Do",       color: "blue"   },
    "in-progress": { title: "In Progress", color: "yellow" },
    done:          { title: "Done",        color: "green"  },
  },
  cards: [
    {
      id: "card-1",
      title: "Set up project scaffolding",
      description: "Initialize Vite + React + Tailwind",
      column: "done",
      priority: "high",
      labels: ["setup"],
    },
    // ... 7 more seed cards
  ],
}

Cards carry their column as a string field rather than being nested inside column arrays. This makes moves trivial -- update one field instead of splicing between two arrays.

The reducer handles seven action types:

Action	Purpose
`LOAD_BOARD`	Replace entire state (used on hydration from localStorage)
`ADD_CARD`	Push a new card into the cards array
`MOVE_CARD`	Change a card's `column` field
`UPDATE_CARD`	Merge partial updates into an existing card
`DELETE_CARD`	Filter a card out of the array by ID
`ADD_LABEL`	Append a label string to a card's labels array
`REORDER_COLUMN`	Replace the ordering of cards within a column

Every state change persists automatically:

function BoardProvider({ children }) {
  const [state, dispatch] = useReducer(boardReducer, initialState)

  useEffect(() => {
    localStorage.setItem("kanban-board", JSON.stringify(state))
  }, [state])

  useEffect(() => {
    const saved = localStorage.getItem("kanban-board")
    if (saved) {
      dispatch({ type: "LOAD_BOARD", payload: JSON.parse(saved) })
    }
  }, [])

  return (
    <BoardContext.Provider value={{ state, dispatch }}>
      {children}
    </BoardContext.Provider>
  )
}

The stateRef Pattern

This is the most important pattern in the codebase. useWebMCP registers tool handlers as closures. React closures capture variables from the render in which they were created. If a handler references state directly, it captures whatever state was when the hook last ran -- not the current state at the moment the AI agent calls the tool.

// BROKEN: state is captured once and never updates
useWebMCP("get_board", {
  schema: z.object({}),
  handler: () => {
    return state // stale! frozen at registration time
  },
})

The fix is a useRef that always points to the latest state:

const stateRef = useRef(state)
useEffect(() => { stateRef.current = state }, [state])

// CORRECT: stateRef.current is always fresh
useWebMCP("get_board", {
  schema: z.object({}),
  handler: () => {
    return stateRef.current
  },
})

Three lines. The ref object is stable across renders. The effect updates .current after every state change. Tool handlers always get the latest state regardless of when the closure was created.

This pattern applies any time you pass callbacks to a registration-style API from within React: WebMCP tools, WebSocket handlers, event bus subscriptions -- anywhere the callback outlives the render that created it.

Tool Registration

Each tool maps to either a read operation or exactly one reducer action.

graph LR
    subgraph Tools["WebMCP Tools"]
        T1["get_board"]
        T2["create_card"]
        T3["move_card"]
        T4["update_card"]
        T5["delete_card"]
        T6["add_label"]
        T7["get_column_summary"]
        T8["prioritize_column"]
    end

    subgraph Actions["Reducer Actions"]
        A1["(read only)"]
        A2["ADD_CARD"]
        A3["MOVE_CARD"]
        A4["UPDATE_CARD"]
        A5["DELETE_CARD"]
        A6["ADD_LABEL"]
        A7["(read only)"]
        A8["REORDER_COLUMN"]
    end

    T1 --> A1
    T2 --> A2
    T3 --> A3
    T4 --> A4
    T5 --> A5
    T6 --> A6
    T7 --> A7
    T8 --> A8

Here is create_card in full:

useWebMCP("create_card", {
  description: "Create a new card on the kanban board",
  schema: z.object({
    title: z
      .string()
      .describe("The title of the card"),
    description: z
      .string()
      .optional()
      .default("")
      .describe("A longer description of the card's content"),
    column: z
      .enum(["backlog", "todo", "in-progress", "done"])
      .optional()
      .default("backlog")
      .describe("Which column to place the card in"),
    priority: z
      .enum(["low", "medium", "high", "critical"])
      .optional()
      .default("medium")
      .describe("Priority level of the card"),
    labels: z
      .array(z.string())
      .optional()
      .default([])
      .describe("Tags or labels to attach to the card"),
  }),
  handler: ({ title, description, column, priority, labels }) => {
    const id = `card-${Date.now()}`
    dispatch({
      type: "ADD_CARD",
      payload: { id, title, description, column, priority, labels },
    })
    return { success: true, id, message: `Card "${title}" created in ${column}` }
  },
})

Zod .describe() annotations are the AI's documentation -- those strings are what Claude reads to understand each parameter. .optional().default() provides safe defaults so the agent can call create_card({ title: "Fix login bug" }) without specifying every field.

And prioritize_column, which reads state, performs logic, then dispatches:

useWebMCP("prioritize_column", {
  description:
    "Sort all cards in a column by priority (critical > high > medium > low)",
  schema: z.object({
    column: z
      .enum(["backlog", "todo", "in-progress", "done"])
      .describe("The column to sort by priority"),
  }),
  handler: ({ column }) => {
    const current = stateRef.current
    const columnCards = current.cards.filter((c) => c.column === column)

    const priorityOrder = { critical: 0, high: 1, medium: 2, low: 3 }
    const sorted = [...columnCards].sort(
      (a, b) => priorityOrder[a.priority] - priorityOrder[b.priority]
    )

    dispatch({
      type: "REORDER_COLUMN",
      payload: {
        column,
        cardIds: sorted.map((c) => c.id),
      },
    })

    return {
      success: true,
      message: `Sorted ${columnCards.length} cards in "${column}" by priority`,
      order: sorted.map((c) => ({ id: c.id, title: c.title, priority: c.priority })),
    }
  },
})

This is where the stateRef pattern pays off. The handler reads live state, filters to the target column, sorts by priority, and dispatches REORDER_COLUMN. If it read state directly, it would sort based on stale data.

Drag-and-Drop Without Libraries

The board supports manual drag-and-drop using native HTML5 DnD APIs. No external libraries. The Card component is the drag source:

function Card({ card }) {
  const { dispatch } = useBoard()

  const handleDragStart = (e) => {
    e.dataTransfer.setData("text/plain", card.id)
    e.dataTransfer.effectAllowed = "move"
    e.currentTarget.style.opacity = "0.5"
  }

  const handleDragEnd = (e) => {
    e.currentTarget.style.opacity = "1"
  }

  return (
    <div
      draggable="true"
      onDragStart={handleDragStart}
      onDragEnd={handleDragEnd}
      className="bg-white rounded-lg shadow p-3 cursor-grab active:cursor-grabbing"
    >
      <h3 className="font-medium text-sm">{card.title}</h3>
    </div>
  )
}

The Column component is the drop target:

function Column({ columnId }) {
  const { state, dispatch } = useBoard()
  const [isDragOver, setIsDragOver] = useState(false)

  const handleDragOver = (e) => {
    e.preventDefault() // Required! Without this, drop is not allowed.
    setIsDragOver(true)
  }

  const handleDragLeave = (e) => {
    if (!e.currentTarget.contains(e.relatedTarget)) {
      setIsDragOver(false)
    }
  }

  const handleDrop = (e) => {
    e.preventDefault()
    setIsDragOver(false)

    const cardId = e.dataTransfer.getData("text/plain")
    if (cardId) {
      dispatch({
        type: "MOVE_CARD",
        payload: { cardId, targetColumn: columnId },
      })
    }
  }

  // ...
}

The onDrop handler dispatches the exact same MOVE_CARD action that the WebMCP move_card tool dispatches. Human drag-and-drop and AI tool calls go through the same code path.

Connecting Claude via Chrome DevTools MCP

The @mcp-b/chrome-devtools-mcp package is a fork of Google's Chrome DevTools MCP server that adds WebMCP tool discovery. It connects any MCP-compatible client to the tools registered on your page through Chrome's DevTools Protocol.

Setup

Claude Code:

claude mcp add chrome-devtools npx @mcp-b/chrome-devtools-mcp@latest

Claude Desktop -- add to claude_desktop_config.json:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "@mcp-b/chrome-devtools-mcp@latest", "--channel", "stable"]
    }
  }
}

The --channel stable flag tells the MCP server to use your regular Chrome installation. Without it, the server defaults to Chrome Dev channel, which most people don't have. Use canary or beta if that's what you have installed. Restart Claude Desktop after editing the config.

The MCP Server Controls Its Own Chrome Window

This is easy to miss and causes confusion: the Chrome DevTools MCP server launches and controls its own Chrome instance. When you ask Claude to navigate to the kanban board, the board opens in the MCP server's Chrome window -- not in your existing browser.

This means you need to watch the MCP-controlled Chrome window to see cards appear and move in real time. If you're looking at a different Chrome window, you'll see Claude report success but nothing will change on your screen.

The workflow is:

Start the kanban board (npm run dev or use the deployed URL)
Open Claude Desktop (or Claude Code) and tell it to navigate to the board URL
Watch the Chrome window that the MCP server opened -- that's where the action happens

The first message to Claude should be explicit:

"Navigate to http://localhost:5174 and list the WebMCP tools"

Claude calls list_webmcp_tools, discovers all 8 kanban tools, and you're ready to go.

How Discovery Works

The Chrome DevTools MCP server doesn't know about kanban boards. It discovers tools dynamically by querying the page.

list_webmcp_tools runs in the browser via CDP:

const tools = navigator.modelContext.tools
return tools.map(t => ({
  name: t.name,
  description: t.description,
  inputSchema: t.inputSchema,
}))

call_webmcp_tool invokes a tool by name:

const result = await navigator.modelContext.callTool(name, args)
return result

The handler registered by useWebMCP runs in the page context with full access to React state and dispatch. The return value is serialized back through CDP to the MCP server, then to Claude.

Agent Session Walkthrough

sequenceDiagram
    participant User
    participant Claude
    participant Bridge as Chrome DevTools MCP
    participant Board as Kanban Board (browser)

    User->>Claude: "Read the board, create 3 bug<br/>cards in To Do, then prioritize<br/>the column."

    Claude->>Bridge: list_webmcp_tools()
    Bridge->>Board: navigator.modelContext.tools
    Board-->>Bridge: 8 tools with schemas
    Bridge-->>Claude: Tool list

    Claude->>Bridge: call_webmcp_tool("get_board", {})
    Bridge->>Board: navigator.modelContext.callTool(...)
    Board-->>Bridge: { columns: [...], totalCards: 8 }
    Bridge-->>Claude: Board state

    Claude->>Bridge: call_webmcp_tool("create_card",<br/>{ title: "Login timeout", column: "todo",<br/>priority: "high", labels: ["bug"] })
    Bridge->>Board: dispatch(ADD_CARD)
    Note over Board: Card appears instantly
    Board-->>Bridge: { success: true, card: {...} }
    Bridge-->>Claude: Created

    Note over Claude: ...repeats for 2 more cards...

    Claude->>Bridge: call_webmcp_tool("prioritize_column",<br/>{ column: "todo" })
    Bridge->>Board: dispatch(REORDER_COLUMN)
    Note over Board: Cards reorder by priority
    Board-->>Bridge: { success: true, newOrder: [...] }
    Bridge-->>Claude: Prioritized

    Claude->>User: "Done. Created 3 bug cards in To Do<br/>and sorted by priority (high first)."

The user watches the cards appear and reorder on screen as Claude works. There is no delay between the tool call completing and the UI updating -- they are the same event.

WebMCP Tools vs. Screenshot-Based Automation

The Chrome DevTools MCP server also includes ~28 browser automation tools: click, navigate_page, take_screenshot, fill, and more. WebMCP tools bypass all of that.

Aspect	Screenshot-based	WebMCP tools
Input	Pixel coordinates, CSS selectors	Structured JSON with typed parameters
Output	Screenshot image (~2,000 tokens)	JSON result (~50-200 tokens)
Reliability	Fragile (layout changes break selectors)	Stable (tool API is the contract)
Speed	Screenshot → vision parse → action → screenshot	Tool call → result (single round trip)
Precision	"Click the blue button at (342, 187)"	`create_card({ title: "...", column: "todo" })`

WebMCP vs. Traditional MCP

What would it take to build the same kanban board using a traditional MCP server with stdio transport?

graph TB
    subgraph Traditional["Traditional MCP Approach"]
        CLAUDE["Claude Desktop"]
        MCP["MCP Server<br/>(Node.js, stdio)"]
        API["Express.js API"]
        DB["SQLite Database"]
        FE["React Frontend"]

        CLAUDE <-->|"stdio<br/>(JSON-RPC)"| MCP
        MCP -->|HTTP| API
        FE -->|HTTP| API
        API --> DB
    end

    subgraph WebMCP["WebMCP Approach"]
        AGENT["Any AI Agent"]
        BROWSER["React App + WebMCP Tools"]
        LS["localStorage"]

        AGENT <-->|"WebMCP<br/>(browser-mediated)"| BROWSER
        BROWSER <--> LS
    end

    style Traditional fill:#fff5f5
    style WebMCP fill:#f0fff4

The traditional approach requires an MCP server (~200 lines of protocol adapter code), a backend API (~300 lines of Express routes, validation, and database queries), a database schema with migrations, CORS configuration, and -- critically -- a sync mechanism to keep the frontend updated when the agent changes data.

The Sync Problem

Without a sync mechanism, the agent and the user are looking at different data.

Traditional MCP -- the agent moves a card, the backend updates the database, but the React frontend still shows the card in its old column. You need polling (up to N seconds of stale UI) or WebSockets (connection management, reconnection logic, message protocol).

WebMCP -- the tool handler dispatches an action, React re-renders, and the card moves on screen in the same frame. There is no gap between "the data changed" and "the user sees the change."

sequenceDiagram
    participant Agent as AI Agent
    participant WMCP as WebMCP (browser)
    participant State as React State
    participant UI as Kanban UI

    Agent->>WMCP: move_card
    WMCP->>State: dispatch(MOVE_CARD)
    State-->>UI: Re-render (instant)
    Note over UI: Card moves immediately
    WMCP-->>Agent: { success: true }

Side-by-Side Comparison

Aspect	Traditional MCP	WebMCP
Running processes	3 (frontend, backend, MCP server)	1 (Vite dev server)
Lines of integration code	~500+	~200
Database	SQLite or PostgreSQL	localStorage
Config files	2+ (server config, claude_desktop_config)	0
Real-time sync	Requires WebSocket/polling	Automatic (shared React state)
Agent compatibility	Claude Desktop only (stdio)	Any WebMCP agent
Setup time	15-30 minutes	`npm install && npm run dev`

When Traditional MCP Is Still Better

Multiple users on different machines need to share the same board. WebMCP tools operate on browser-local state. If two people need to see the same board, you need a server-side database and a sync protocol.

Data must persist beyond a single browser. localStorage is tied to a browser profile on a single machine. A database survives browser resets, machine changes, and OS reinstalls.

The AI agent needs to run headlessly without a browser open. WebMCP requires a browser tab. If the agent runs in CI, a cron job, or any environment without a display, traditional MCP's stdio transport works anywhere Node.js runs.

The web UI does not exist. If the application is a pure API service with no frontend, there is no browser for WebMCP to run in.

MCP as Adapter vs. MCP-Native Apps vs. WebMCP

Beyond where the MCP server runs, there is a second question: what role does MCP play in the architecture?

MCP as an Adapter Layer

You have a backend with an API, a frontend with a UI, and the MCP server is a thin translation layer that converts tool calls into API requests. The backend does not know or care whether a request came from a user clicking a button or an LLM invoking a tool.

User clicks "Add Card"  -->  Frontend  -->  POST /api/cards  -->  Backend
LLM calls create_card   -->  MCP Server -->  POST /api/cards  -->  Backend

The MCP server contains no business logic. It is a protocol adapter: JSON-RPC in, HTTP out. The backend owns validation, persistence, and business rules. The app works without MCP.

For a concrete example, the ai-developer-tools-mcp project demonstrates this pattern: a ~200-line MCP server wraps an existing REST API for AI developer tool analytics. The API handles authentication, rate limiting, and data queries. The MCP server just translates tool calls into fetch() requests and formats the JSON responses for Claude. The API has no idea it is being called by an LLM -- and that is the point.

The structural parallel to this kanban board is exact:

	ai-developer-tools-mcp	webmcp-kanban
App	REST API (data platform)	React app (kanban board)
Bridge	MCP server (~200 lines)	WebMCPTools.jsx + Chrome DevTools MCP
Bridge's job	Tool calls → HTTP requests	Tool calls → `dispatch()` to React state
App changes needed	None	None

Same pattern, different transport. One goes over HTTP to a backend. The other goes directly into browser state.

MCP-Native Apps

In an MCP-native app, the MCP server is the application. There is no separate REST API -- the tools, resources, and prompts defined in MCP are the primary interface. Any UI built on top calls through MCP, not around it.

This pattern makes sense for tools designed primarily for LLM consumption: code analysis tools, data pipelines, documentation generators, dev tooling. The LLM is the intended user, and a traditional web UI is secondary or nonexistent.

Comparison

	MCP as Adapter	MCP-Native App	WebMCP
Existing app?	Drop-in, no refactor needed	Built from scratch for MCP	Drop-in for React apps
Primary UI	Web interface for humans	LLM is the primary consumer	Web interface, shared with LLM
Without an LLM	Fully functional	Limited or unusable	Fully functional
Architecture	Two layers (API + MCP)	Single layer (MCP is the API)	Single layer (browser is the runtime)
Complexity	More moving parts, but decoupled	Simpler, but coupled to MCP	Simplest for browser-based apps

A Retrofit Path for Existing React Apps

Everything described in this post was built alongside the kanban board. But it didn't have to be.

The kanban board's WebMCP integration lives in a single file: WebMCPTools.jsx. That file reads state through useBoardState() and writes state through dispatch() -- the same hooks the UI components use. It does not modify the board's reducer, its components, or its persistence logic. If you deleted WebMCPTools.jsx, the kanban board would still work exactly as before. If you added it back, the board would become AI-accessible again. The app itself never changes.

This pattern generalizes to any React application that manages state through hooks.

If your app uses Context + useReducer, you write tool handlers that call dispatch() with the same action types your components already use. The reducer doesn't know or care that the action came from an AI agent instead of a button click.

If your app uses Redux, the tool handlers call store.dispatch(). The reducers, middleware, and selectors all work unchanged.

If your app uses Zustand, Jotai, or any hook-based store, the tool handlers call the same setter functions your components call.

The integration is always the same shape: a new file that imports the existing store, registers tools against navigator.modelContext, and maps each tool to a read or write operation the app already supports. No refactoring. No new API layer. No changes to existing components.

graph TD
    subgraph "Existing React App (unchanged)"
        Store["State Management<br/>(Context, Redux, Zustand, etc.)"]
        UI["UI Components"]
        UI <-->|"existing hooks"| Store
    end

    subgraph "New File"
        Tools["WebMCPTools.jsx"]
    end

    Tools -->|"same hooks"| Store
    Agent["AI Agent"] <-->|"navigator.modelContext"| Tools

For teams with large, established React applications, this is the key takeaway: WebMCP is not a rewrite. It is one file that gives an LLM the same access your components already have.

Conclusion

The kanban board is a small, familiar application -- but it exercises every property that makes WebMCP interesting: shared context, instant feedback, composable tools, and zero-infrastructure agent integration.

The entire app is roughly 500 lines of code across five files. Each WebMCP tool either reads state or dispatches exactly one reducer action. The AI agent composes them into sequences -- "get the board, create three cards, move the bug to in-progress, prioritize the todo column" -- and each call is an atomic operation against the reducer.

For a single-user tool where the agent and user share the same context, WebMCP eliminates an enormous amount of accidental complexity. The traditional approach turns a 200-line integration into a 500+ line multi-process system with a sync problem to solve. None of those components are difficult to build. But all of them are unnecessary when the browser is the runtime.

How Much Do Your Docs Cost to Read?

Ed G — Thu, 12 Feb 2026 03:14:11 +0000

I’ve been spending a lot of time thinking about how AI tools consume documentation. Not how developers read docs, but how Copilot, Cursor, and AI agents ingest them as tokens.

One thing that keeps coming to mind: nobody talks about what that actually costs.

The tool

docs-cost-calculator lets you paste any structured documentation and see how many tokens it takes to represent it across different formats, like JSON, YAML, JSON Compact, Plain Text, side by side, with cost estimates at scale.

It runs entirely in the browser using cl100k_base tokenization (the encoding used by GPT-4 and Claude). No AI, no API keys needed, and nothing leaves your machine.

Why I built it

I was doing research on documentation formats for a project and got tired of running tokenization scripts manually every time I wanted to compare two versions of the same docs. So I built a quick UI for it.

Once I had it working, the language comparison feature came out of curiosity. Byte Pair Encoding (BPE) tokenizers were trained heavily on English text, so I wondered what happens when you tokenize the same structured content in other languages. The results were interesting enough to include.

Try it

Paste your own OpenAPI specs, config objects, or error references and see what comes back: doc-cost.vercel.app

If you’re working on documentation that gets consumed by AI tools at any kind of scale, the numbers might surprise you.

I’m writing more about this topic. Stay tuned.

Claude Context Analysis: What 500 CLAUDE.md Files Reveal About How Developers Use Claude

Ed G — Sat, 07 Feb 2026 17:20:08 +0000

Every day at 3 AM GMT, a Flask app I built wakes up, scrapes 500 CLAUDE.md files from public GitHub repositories, runs topic modeling on them, and publishes the results. The goal: figure out what developers are actually putting in their CLAUDE.md files and how those patterns change over time.

Check it out: analyze-claude-md.onrender.com

Why this exists

CLAUDE.md files are how developers tell Claude Code how to work with their project. They contain coding standards, build commands, architecture decisions, and behavioral instructions. But there’s no official guidance on what makes a good one. Everyone’s figuring it out independently.

I wanted to answer a simple question: what are the common patterns? If 500 repos all mention “typescript” and “npm” in their CLAUDE.md files, that tells you something about the ecosystem. If “agent” is trending upward over 30 days, that tells you something about where things are headed.

How it works

The pipeline has four stages:

Collection: The GitHub Code Search API finds files named claude.md across public repos. The app downloads up to 500 per run, handling pagination and rate limits.
Preprocessing: NLTK tokenizes the text, removes stopwords, and lemmatizes words down to root forms. “Running” becomes “run,” “configurations” becomes “configuration.”
Topic modeling: NMF (Non-negative Matrix Factorization) discovers 5 topics, each a weighted distribution over words. The model uses TF-IDF (Term Frequency-Inverse Document Frequency) weighting, which downweights common terms and highlights distinctive ones.
Visualization: Results are saved to JSON and rendered as horizontal bar charts on the homepage, with word weights shown proportionally.

The whole thing runs on Render’s free tier with no database. Analysis history is stored as JSON files committed to the repo so data survives redeploys.

Choosing NMF over LDA

The project originally used LDA (Latent Dirichlet Allocation), which is the textbook approach for topic modeling. It was brittle for this use case.

LDA topics shifted significantly between runs, even with a fixed random seed, because the input data changes daily (GitHub returns different repos each time). The topics were often incoherent, mixing unrelated terms. And because LDA uses raw word counts, common words dominated even when they weren’t distinctive.

NMF paired with TF-IDF (Term Frequency-Inverse Document Frequency) solved all three problems. Topics are more coherent (the top words within each topic clearly relate to each other), more stable across runs, and better at surfacing distinctive terms rather than just frequent ones. The swap was nearly drop-in since both models are in scikit-learn with the same API.

BERTopic would produce even better results using transformer embeddings for semantic understanding, but it requires 80-400MB for the sentence-transformers model, which won’t fit on Render’s free tier.

What the data shows

After 30 daily runs, some clear patterns emerge:

“npm” is the most consistently dominant term, appearing with high weight in nearly every run. Frontend tooling dominates CLAUDE.md files.
“typescript,” “react,” and “server” form a stable cluster. The JavaScript/TypeScript ecosystem is where most Claude Code usage lives.
“agent” has been trending upward over the past month, reflecting the growing use of agentic patterns.
“python,” “database,” and “api” are consistently present but with more variance, suggesting they’re concentrated in specific project types rather than being universal.

On the term trends page, you can toggle individual terms on and off, with both absolute weight and normalized (0-100%) views for comparing terms with different baselines.

The label generation problem

One interesting challenge: how do you name a topic? LDA and NMF produce distributions over words, not labels. The current approach is a heuristic function that checks if the top 5 words contain keywords from hardcoded lists:

python if any(word in top_5_words for word in ['npm', 'typescript', 'react']): return "Frontend Development"
This is the weakest part of the system. If “react” happens to be the 6th word instead of top 5, a clearly frontend topic gets a generic fallback label. It’s why the term trends page tracks individual words rather than relying on topic labels. The words are the stable data; the labels are cosmetic.

Technical details

Stack: Flask, scikit-learn, NLTK, Chart.js, Jinja2
Hosting: Render free tier (512MB RAM, cold starts)
Storage: JSON files committed to the repo
Scheduling: Background daemon thread checks hourly, runs analysis at 3 AM GMT
Data: 500 files per run, 30-day rolling history, 15 terms tracked in trends

The app has no database. Historical data is an array of JSON objects appended to a file. Topic evolution tracking uses cosine similarity to match topics across runs despite label changes. The whole codebase is a single app.py file with Jinja2 templates. No user data is stored. All analysis is performed in memory on publicly available content. Temporary files are deleted after processing.

What I learned

NMF is underrated. Most topic modeling tutorials teach LDA first, but for short documents with noisy input, NMF with TF-IDF produces noticeably better results with less tuning.

Track words, not topics. Topic-level tracking across runs is fragile because the groupings shift. Term-level tracking is rock solid and often more useful.

Commit your data. Storing analysis history as committed JSON files instead of relying on ephemeral server storage was a simple decision that saved the project’s 30-day history from being wiped on every deploy.

Check it out: analyze-claude-md.onrender.com

Source code: github.com/grzetich/analyzeclaudemd

Making data conversational: Building MCP Servers as API bridges

Ed G — Mon, 12 Jan 2026 00:34:33 +0000

At the Fort Wayne AI meetup on 09 January, I presented about a pattern I've discovered while building Vibe Data: Making data conversational by using a model context protocol (MCP) server on top of existing REST APIs. Your API provide your data, an MCP server provides access to the API for a desktop LLM client like Claude or ChatGPT, and the LLM client provides conversational access to your data.

This post captures what I learned building this architecture and what I shared with the developer community.

The situation: Two audiences, one backend

When you're building a data platform, you inevitably face a challenge: different users need different interfaces.

Developers want:

Programmatic API access
JSON they can transform
Full control for automation
Integration with their tools

End users want:

Quick answers to questions
No coding required
Natural language queries
Simple, intuitive interfaces

The traditional approach is to build two separate systems: a REST API for developers and dashboards or reports for end users. But this creates maintenance overhead, duplicate business logic, and architectural complexity.

The Solution: MCP as an API bridge

I've found a better pattern: build your REST API first, then add an MCP server as a thin conversational wrapper.

Here's the architecture:

          Data platform
                 │
            REST API
    (Business Logic | Auth | Rate Limiting)
                 │
        ┌────────┴────────┐
        │                 │
   Direct API        MCP Server
    Access            (~200 lines)
        │                 │
   Developers      Users + Claude
   (JSON/Code)     (Conversation)

The REST API remains your single source of truth. All business logic, authentication, rate limiting, and caching live here. The MCP server is just a formatting layer that:

Receives structured tool calls from Claude.
Translates them to API requests.
Formats JSON responses as natural language.
Returns conversational text.

Why this pattern works

1. Separation of concerns

Your API handles the hard stuff:

Database queries
Authentication and authorization
Rate limiting and caching
Business logic and validation

Your MCP server handles presentation:

Formatting JSON as readable text
Adding context and insights
Transforming data into conversation

When your API changes, both interfaces get the update automatically. No duplicate logic to maintain.

2. Opportunity for two products from one source

You can serve both audiences without building twice:

API tier: Developers get JSON, higher rate limits, programmatic access
Conversational tier: End users get Claude access, simpler pricing

Same backend. Different value propositions.

3. Progressive enhancement

You're not choosing between API or MCP. You're adding conversational access to an existing system:

Start with API (proven, understood, lots of tooling)
Add MCP layer when ready (thin wrapper, low risk)
Keep both interfaces running (serve more users)

What I learned building this

MCP works best as a bridge

Don't try to rebuild your entire backend in MCP. Don't put business logic in your MCP tools. Build a solid REST API first. That's your product. The MCP server should be ~200 lines of code that calls your API and formats responses.

async getToolMetrics(toolId) {
    try {
      const response = await fetch(
        ${this.baseURL}/tools/${toolId}/metrics
...
const toolName = data[0].name || toolId;
let output = `📈 ${toolName.toUpperCase()} - ${months} Month History\n\n`;
  output += `**Download Trend:**\n`;
....

Different interfaces for different users

Developers want JSON they can transform however they need. They'll build custom dashboards, automate reports, integrate with other systems. Give them an API.

End users just want answers. They don't want to learn curl commands or read API documentation. They want to ask "What's Cursor's growth trend?" and get an answer. Give them Claude with MCP.

You can serve both without building duplicate systems.

The formatting layer is where MCP adds value

Your API returns data:

{"downloads": 8100000, "growth_pct": 55.8}

Your MCP server transforms it:

Cursor grew 55% over the quarter, reaching 8.1M monthly 
downloads, indicating strong developer adoption.

Same data. One is optimized for machines. One is optimized for humans.

This formatting layer, turning structured data into meaningful insights, is where conversational interfaces shine. It's not just passing through JSON; it's contextualizing and explaining it.

The Demo: Making data conversational

During the presentation, I demonstrated this with Vibe Data's adoption intelligence and Claude desktop:

Query 1: "What's Cursor's adoption trend over the last quarter?"

Claude calls get_tool_history tool
MCP server calls REST API
Returns formatted trend analysis with growth calculations

Query 2: "How does Cursor compare to GitHub Copilot?"

Claude calls compare_tools
Gets metrics for both
Synthesizes side-by-side comparison with key insights

Query 3: "Which AI coding tools are growing fastest right now?"

Claude calls get_trending_tools
Ranks by growth percentage
Presents as ordered list with context

The pattern works because Claude can compose these tools in ways I didn't pre-build. Ask "compare the top 3 trending tools" and Claude chains multiple calls automatically. A report would need that query to be pre-built and a dashboard might require the user to pick the appropriate options from menus.

Being honest about limitations

MCP isn't magic, and I told the audience that. Current challenges:

Discovery: Users don't automatically know what tools are available. They have to ask or explore. The ecosystem needs better tool discovery UIs.

Distribution: When you add new tools, users need to update locally. Cloud-hosted MCP servers would solve this with instant updates.

Anticipation: You still need to build specific tools for specific questions. MCP doesn't eliminate the need to think about what users need.

But even with these limitations, it's better:

Natural language beats clicking through filters.
Claude can compose tools dynamically.
Graceful degradation ("I don't have Reddit data") beats silent missing features or cryptic error codes.
Standardized protocol beats reinventing the wheel.

Understanding both strengths and friction points, not just evangelizing uncritically, helps drive real adoption.

Real-world use cases

This pattern works for any product with data exposed by APIs:

B2B SaaS:

API → Analytics platforms, customer dashboards
MCP → "How's our MRR trending?" "Which customers churned?"

E-commerce:

API → Inventory systems, order management
MCP → "What products are low stock?" "Show me returns this week"

Internal Tools:

API → Automated reports, integrations
MCP → "Find pending invoices" "Compare Q3 vs Q4 sales"

The pattern is universal: build API first, wrap with MCP, serve both technical and non-technical users.

The code: Open source educational implementation

I've open-sourced an educational MCP server that demonstrates this pattern: github.com/grzetich/ai-developer-tools-mcp

It uses sample data to show the architecture without requiring database access. The structure is identical to production:

src/
├── tools/          # MCP tool definitions
├── api/            # API client (THE BRIDGE)
├── data/           # Mock data (simulates database)
└── utils/          # Response formatters

In production, only api/client.js changes - from mock data to real fetch() calls. Everything else stays the same.

What's next

I'm continuing to refine this pattern at Vibe Data, where the MCP server serves production traffic alongside our REST API. The dual-interface approach lets us serve both developers building integrations and investors asking questions.

I'm also exploring how to solve the distribution and discovery challenges, potentially through cloud-hosted MCP servers that auto-update when new tools are deployed like my Pokémon MCP server.

If you're building with MCP or thinking about conversational interfaces for your data, I'd love to hear what patterns you're discovering. Reach out on GitHub or email.

Resources

Educational MCP Server: github.com/grzetich/ai-developer-tools-mcp
Presentation Slides: View on SpeakerDeck
MCP Documentation: modelcontextprotocol.io