DEV Community: Cristina Rodriguez

Your MCP server works fine. Then you run a second copy, and the next call lands somewhere that has never heard of the first one. I wrote up what breaks, what MCP 2026-07-28 actually changed, and the bug I found in my own code while writing it.

Cristina Rodriguez — Fri, 31 Jul 2026 16:41:09 +0000

Cristina Rodriguez

Jul 31

What Breaks When One MCP Server Becomes Two

#mcp #ai #python #beginners

13 min read

What Breaks When One MCP Server Becomes Two

Cristina Rodriguez — Fri, 31 Jul 2026 16:39:01 +0000

I didn't start this because MCP is trendy. I started it because I could see the problem coming.

Anzuelo, a lead-finding agent I built, scrapes Reddit, Hacker News, Bluesky, Mastodon, YouTube, LinkedIn, and Threads looking for people talking about the things I care about, then scores what it finds using the Claude API. Right now it runs as a scheduled job, once a day, one process, no concurrency to worry about. But the moment I, or anyone, wants to expose that kind of search-and-page workflow as something other tools can call on demand, "the server remembers where you left off" stops being a safe assumption. Run two instances behind a load balancer and the second call can land on a machine that's never heard of the first one.

That's not an MCP problem specifically. It's a distributed systems problem, and it's the direction MCP's July 28 spec is pushing: stop relying on one instance's memory to connect one call to the next. The state can still live somewhere. What changes is that the client carries something explicit to point at it, instead of the server assuming the next call comes back to the same process.

Who's talking to who

Quick setup, because the rest of this doesn't land without it.

There's a model, meaning the assistant someone is chatting with. There's an MCP server, which is a small program you write that offers up a few functions the model is allowed to call. Those functions are called tools. And there's a client sitting in the middle, carrying messages between the two.

When the model wants to search your mentions, it never runs your code. It sends a message saying "call start_search, keyword is mcp." The client hands that to your server. Your server runs the function and sends text back. The model reads that text the same way it reads anything else in the conversation.

The part that matters for this post: each of those is a separate round trip. Ask, answer, done. Nothing in that arrangement promises the next question arrives at the same running copy of your server.

Before we go further, one thing I should be straight about. Anzuelo is why I care about this problem, and Anzuelo is also not what I'm showing you. It doesn't speak MCP yet. No server, no tools, nobody calling in. So I built a tiny MCP server that does nothing except search a list and page through it, because I wanted to watch this failure happen somewhere small before I built it on top of data I'd actually have to care about. What follows is the old way, where the server remembers your search for you, and the new way, where every call carries what it needs. I'm writing it in the order things actually happened, including the three places I turned out to be wrong.

Here's what that gap actually looks like for a system like Anzuelo, running today versus what it would need before other people's clients could call it:

If you want the longer version of that, I wrote a plain-language intro a while back covering what problem it solves and how tool calls actually work. This post picks up from there and goes straight into the part that's changing. (Anzuelo's searcher-per-platform architecture is where I first ran into this kind of state-management question, even without MCP in the mix.)

If you're a career-changer aiming for an entry-level developer role, this is worth your time for a reason that has nothing to do with chasing a trend. Reasoning about state and designing a clean contract between two systems is what interviewers have always tested, and MCP is a well-documented place to practice it right now.

The failure that shows up when one process becomes two

One more word before the story. When a server gets busy, you run several copies of it at once and spread traffic across them. Kubernetes people call each copy a pod, and I'll use that word because it's short. Read it as "one running copy of my server, sitting on some machine."

Picture two identical copies of the same MCP server running behind a load balancer: call them pod A and pod B. A client sends start_search, the request lands on pod A, and pod A stores the search progress in its own memory. The client's next call, get_next_page, has a coin-flip chance of landing on pod B instead. Pod B has never heard of this search. It doesn't crash. It politely tells the client there's no active search, which is a dead end dressed up as a successful response.

This isn't a hypothetical. It was the most common failure story people wrote about in the run-up to July 28. And it was fixable before the spec even shipped, because the fix isn't really about MCP. It's about not trusting a specific process to remember something a specific client needs.

What 2026-07-28 actually changed

Before this release, an MCP conversation started with a hello. The client and the server traded a message called initialize, agreed on which version they were both speaking and what each one could do, and from then on the server kept a thread running underneath every later call. That thread was called the session.

7-28 removes the hello and the thread. Every request now shows up carrying its own version, its own information about who is calling, and its own list of what the client can do. Nothing gets agreed once and remembered.

That is more baggage on every single call. What you get for it is that no request depends on reaching the same copy of your server as the last one did. The load balancer can send traffic wherever it likes. Your server can also run in places that never keep a connection open, which is most of the cheap places to run things.

Three other changes came with it:

Signing in got more standard. Auth now matches the way OAuth is normally set up, so a server can plug into whatever identity system a company already uses instead of inventing something.
New features can ship as add-ons now, without changing the protocol itself. Two arrived with this release. MCP Apps lets a server send back a small interactive interface instead of plain text. Tasks covers work that takes a while to finish.
Every feature got a promise. Once something is marked deprecated, it stays in the spec for at least twelve more months before it can be removed.

Tasks is the one worth a look here. When a job takes a while, the server answers with a task handle, and the client uses that handle to come back and ask how it's going. That's the same move I make below with search_id and a cursor. The client holds onto something small and hands it back on the next call.

And if you already have a server running, it didn't break on July 28. New clients that speak 7-28 fall back to the old hello when they reach an older server.

One thing I want to be careful about, because I got it wrong in my first draft. The spec removed the session the protocol was keeping for you. It did not remove the dictionary I was keeping in my own server. No spec can do that. That one was always mine to fix. What 7-28 does is take away the crutch.

The full release notes are on the MCP blog, and AAIF published a migration guide that goes deeper than I do here.

Old way: state lives in the server's memory

Here's a tiny mention-tracker server, written the naive way, with the cross-call state parked in one process. This isn't what the 2025-11-25 spec told you to build. It's what's easy to reach for when you're on your laptop, one process, one client, and nothing has ever gone wrong. It searches a list of mock mentions for a keyword and lets you page through results.

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("mention-tracker")

MOCK_MENTIONS = [
    {"platform": "reddit", "text": "anyone using agentgateway in prod?"},
    {"platform": "hn", "text": "MCP stateless core is a good call"},
    {"platform": "bluesky", "text": "just shipped an MCP server, no auth yet"},
    {"platform": "mastodon", "text": "agentic tools are eating my weekend"},
    {"platform": "youtube", "text": "tutorial: build an MCP client in 10 min"},
]

# One shared slot for this whole process. Not scoped to a session or a caller.
# Whoever calls last wins, and a second caller mid-search clobbers the first.
_search_state: dict[str, dict] = {}

@mcp.tool()
def start_search(keyword: str) -> str:
    """Start a mention search. Progress is remembered server-side."""
    matches = [m for m in MOCK_MENTIONS if keyword.lower() in m["text"].lower()]
    _search_state["current"] = {"matches": matches, "cursor": 0}
    return f"Search started for '{keyword}'. Found {len(matches)} mention{'s' if len(matches) != 1 else ''}. Call get_next_page() to page through results."

@mcp.tool()
def get_next_page() -> str:
    """Return the next mention. Trusts the server to remember where we left off."""
    state = _search_state.get("current")
    if state is None:
        return "No active search. Call start_search first."
    cursor = state["cursor"]
    matches = state["matches"]
    if cursor >= len(matches):
        return "No more mentions."
    mention = matches[cursor]
    state["cursor"] += 1
    return f"[{mention['platform']}] {mention['text']}"

if __name__ == "__main__":
    mcp.run()

Notice get_next_page() takes zero arguments. It only works because this exact process remembers the last cursor. A cursor is a bookmark, a number saying how far through the results you've already read. The state here is worse than session state, and I'll come back to why once you've seen the wire calls. Here's the actual JSON-RPC exchange this demo sends, captured over stdio. JSON-RPC is just the message format MCP uses: a function name, some arguments, a reply. And stdio means the client and the server are talking through the terminal, one process to one process, which is how you run this on a laptop. So this is one client talking to a single process, and it isn't reproducing the pod A and pod B routing. What it shows is the thing that makes that routing dangerous:

start_search {"keyword": "mcp"} ->
{
  "meta": null,
  "content": [
    {
      "type": "text",
      "text": "Search started for 'mcp'. Found 3 mentions. Call get_next_page() to page through results.",
      "annotations": null,
      "meta": null
    }
  ],
  "structuredContent": {
    "result": "Search started for 'mcp'. Found 3 mentions. Call get_next_page() to page through results."
  },
  "isError": false
}

get_next_page {} ->
{
  "meta": null,
  "content": [
    {
      "type": "text",
      "text": "[hn] MCP stateless core is a good call",
      "annotations": null,
      "meta": null
    }
  ],
  "structuredContent": {
    "result": "[hn] MCP stateless core is a good call"
  },
  "isError": false
}

Look at that second call: "arguments": {}. Nothing in it identifies the search. The only reason it can answer is that this process still holds the cursor from the first call. Point it at a process that didn't serve start_search and there is nothing to page through.

Surprise one: it was worse than session state

I noticed this while I was writing the old server, and it bothered me more than the load balancer story did. _search_state["current"] isn't scoped to a session or a caller. It's one slot for the entire process, keyed on the literal string "current". Session-pinning means the load balancer keeps sending the same client back to the same copy. That at least guarantees that your requests keep landing on the pod that knows about your search. This doesn't even give you that: two clients hitting the same process share the slot, so whoever calls start_search last wins and the other one's cursor silently jumps into someone else's result set. The load balancer story is the failure you notice. This one you don't.

New way: state travels with the call

So I rebuilt the server, and the first thing I had to settle was what the client would carry between calls.

Surprise two: I had to decide what a handle even is

Here's the same server, rebuilt so the continuation state travels in the arguments instead of living in the process. Writing it, I hit a question I hadn't planned for: what is the handle actually made of? Somebody has to decide, and that somebody was me. I picked the keyword. search_id is just the string the caller searched for, and the server recomputes matches from a static list on every call. That's a demo answer and I wasn't comfortable with it. A real one would mint an opaque ID, keep the result set somewhere every instance can read, and validate the ID before touching it. I left the simple version in anyway, because what I want to show is where the continuity lives, and that part is the same in both. I didn't wait for the spec release to write this, and you don't need to either. It works in any current MCP SDK.

from typing import TypedDict

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("mention-tracker")

MOCK_MENTIONS = [
    {"platform": "reddit", "text": "anyone using agentgateway in prod?"},
    {"platform": "hn", "text": "MCP stateless core is a good call"},
    {"platform": "bluesky", "text": "just shipped an MCP server, no auth yet"},
    {"platform": "mastodon", "text": "agentic tools are eating my weekend"},
    {"platform": "youtube", "text": "tutorial: build an MCP client in 10 min"},
]


class SearchHandle(TypedDict):
    search_id: str
    cursor: int
    match_count: int
    message: str


class MentionPage(TypedDict):
    platform: str | None
    text: str | None
    cursor: int
    done: bool


@mcp.tool()
def start_search(keyword: str) -> SearchHandle:
    """Start a mention search. Returns a handle the CLIENT carries forward."""
    matches = [m for m in MOCK_MENTIONS if keyword.lower() in m["text"].lower()]
    return {"search_id": keyword, "cursor": 0, "match_count": len(matches),
            "message": f"Search started for '{keyword}'. Found {len(matches)} mention{'s' if len(matches) != 1 else ''}."}


@mcp.tool()
def get_next_page(search_id: str, cursor: int) -> MentionPage:
    """Return the next mention. search_id and cursor are explicit arguments,
    so this call is self-contained. Any instance can answer it."""
    cursor = max(cursor, 0)
    matches = [m for m in MOCK_MENTIONS if search_id.lower() in m["text"].lower()]
    if cursor >= len(matches):
        return {"platform": None, "text": None, "cursor": cursor, "done": True}
    mention = matches[cursor]
    return {"platform": mention["platform"], "text": mention["text"],
            "cursor": cursor + 1, "done": False}


if __name__ == "__main__":
    mcp.run()

Same tool names. The model calls them the same way it called the old ones, though the contract underneath has changed: get_next_page now requires two arguments it used to pull from memory.

Surprise three: the handle came back as a string

The old server annotated start_search as -> str. Its reply carried a populated structuredContent:

"structuredContent": {
  "result": "Search started for 'mcp'. Found 3 mentions. Call get_next_page() to page through results."
}

The rebuilt server annotated the same tool as -> dict:

@mcp.tool()
def start_search(keyword: str) -> dict:

Its reply carried this instead:

"structuredContent": null,

So the version I was presenting as the improvement produced the worse-shaped output. The handle existed only as text inside content, and a client would have to parse that string before it could read a single field.

The cause is the annotation. A bare dict declares no key names and no types, so FastMCP has no schema to build from and falls back to dumping the return value as text.

The fix is declaring the shape. With SearchHandle and MentionPage as TypedDicts, on SDK 1.29.0, the same call returns:

"structuredContent": {
  "search_id": "mcp",
  "cursor": 0,
  "match_count": 3,
  "message": "Search started for 'mcp'. Found 3 mentions."
}

One difference worth flagging: the old server wraps its value under a result key, while the TypedDict version returns the fields as a bare object.

The part worth noticing is what -> dict allowed. That annotation let get_next_page return two different shapes depending on the branch: the finished branch returned two keys, done and cursor, and the normal branch returned four. Declaring MentionPage forced one consistent shape, with platform and text null when the search is done.

Here's the wire exchange from the finished version, with both shapes declared:

start_search {"keyword": "mcp"} ->
{
  "meta": null,
  "content": [
    {
      "type": "text",
      "text": "{\n  \"search_id\": \"mcp\",\n  \"cursor\": 0,\n  \"match_count\": 3,\n  \"message\": \"Search started for 'mcp'. Found 3 mentions.\"\n}",
      "annotations": null,
      "meta": null
    }
  ],
  "structuredContent": {
    "search_id": "mcp",
    "cursor": 0,
    "match_count": 3,
    "message": "Search started for 'mcp'. Found 3 mentions."
  },
  "isError": false
}

get_next_page {"search_id": "mcp", "cursor": 0} ->
{
  "meta": null,
  "content": [
    {
      "type": "text",
      "text": "{\n  \"platform\": \"hn\",\n  \"text\": \"MCP stateless core is a good call\",\n  \"cursor\": 1,\n  \"done\": false\n}",
      "annotations": null,
      "meta": null
    }
  ],
  "structuredContent": {
    "platform": "hn",
    "text": "MCP stateless core is a good call",
    "cursor": 1,
    "done": false
  },
  "isError": false
}

Nothing is stored in this process. Pod A or pod B, it doesn't matter, search_id and cursor are right there in the arguments. The model carries the handle forward the same way it would carry any other tool result. A production server would still have state behind that handle, sitting in Postgres or Redis where every instance can reach it. What moved is the assumption. The server stops betting that the next call comes back to the same memory. That's the core of the migration.

What this doesn't fix (yet), and what still works

This toy server sidesteps things a real production server would need. There's more to handle around routing and auth, and the spec covers it. Roots, Sampling, and Logging are deprecated in this release, so if you're running them, nothing broke on July 28 and you have the twelve-month window to move.

Try it yourself

The full code for both versions is in this repo. One install note. Both servers were built and tested on mcp 1.29.0. Version 2.x renames FastMCP to MCPServer. The decorator API survives the rename, but the import path does not, so an unpinned install will fail before it gets that far. Clone it and run the old version in two terminal windows. Two terminals means two processes with separate memory, which is the same thing a load balancer does to you by accident. Call start_search in one and get_next_page in the other, and watch it come back with "No active search. Call start_search first." That's a dead end, not a crash, but useless to the client that expected its next mention. Then run the new version and watch it not care which "pod" answers.

On a real server with real data I'd do three things differently. The handle would be an opaque ID, not the keyword, so it doesn't leak what was searched and can't be guessed. The result set behind it would live somewhere every copy of the server can read. And get_next_page would validate the ID before it touched anything, instead of trusting whatever arrived in the arguments.

If you're new to backend development and wondering whether any of this applies to you: it's the same lesson every distributed system eventually teaches, MCP is just handing it to you early, with good docs and a spec you can go read.

The next one is the real thing. Anzuelo is getting an MCP server, with actual mentions in Supabase and actual people paging through them, and I'll write up what breaks when the data stops being five hardcoded strings.

So, you know how to connect to an API endpoint? Great. Now they're asking you to build an MCP, and you're freaking out. Don't sweat it, it's simpler than it sounds. The real difference isn't the code; it's who decides what happens next. New post 👇

Cristina Rodriguez — Wed, 01 Jul 2026 14:09:18 +0000

Cristina Rodriguez

Jul 1

Okay, But What IS MCP? (No, Really)

6 min read

Okay, But What IS MCP? (No, Really)

Cristina Rodriguez — Wed, 01 Jul 2026 14:05:54 +0000

A couple of weeks ago, I sat down to add an MCP server to one of my workflows. Before I started building, I pulled up our team channel and asked a simple question: "quick check, what does everyone think MCP actually does?"

Five people responded. Three of them said some version of "it gives the AI more context." One said "it's like an API for AI." One just sent a thumbs-up emoji.

Nobody was wrong, exactly. But nobody could tell me the one thing that actually matters: who decides what happens next, the developer or the model? That's the whole concept, and somehow we'd all been nodding along in meetings for months without anyone saying it out loud.

So here's the explanation I wish someone had given my team. The one that would have saved us a very confusing thirty minutes.

When you call an API, you decide.

In a normal integration, the developer writes the logic: "first call this endpoint, then check this condition, then call that endpoint." The code is the decision-maker. The AI model, if there's one involved at all, just processes whatever text gets handed to it. It doesn't get a say in what happens next.

MCP flips that. The model decides.

An MCP server is a small program you write that exposes a list of "tools," functions with a name, a description, and defined inputs. The model connects to that server, asks "what can you do?", gets back the list, and then decides for itself which tool to call, when, and with what arguments, based on what it's trying to accomplish.

That's the real distinction:

API call = developer-decided, fixed sequence
MCP tool = model-decided, dynamic choice

And here's the part that surprises people: an MCP server isn't some heavy new framework. Most of the time, it's just a Python file with a few functions, each marked with a decorator that says "this is a tool now."

That's it. No new language, no special infrastructure. If you can write a Python function, you can write an MCP tool.

A concrete example

I run a small n8n workflow that screens job postings for me. It's part of a self-paced course I built, Teamed Job Hunter, if you want to see the full automated job-hunting setup. Today, the workflow is a fixed pipeline: trigger, then AI prompt, then scoring logic, then notification. The AI step doesn't get to look anything up, it just processes whatever text the workflow handed it.

If I wrap that logic as an MCP server instead, I'd expose tools like:

check_company_blocklist(company_name): checks if a company is on my no-go list
get_cv_match_score(job_description, cv_track): scores a posting against my CV

The agent, mid-conversation, decides: "let me check the blocklist first, then score it," calling tools as needed. I never hardcoded that order. It reasoned its way there on its own.

Why this matters for developers

You write the tool once. Any MCP-compatible agent (Claude, an n8n agent node, whatever comes next) can discover and use it, without you writing new glue code for each integration.

That's MCP. A standard way for an agent to discover and choose tools on its own.

Three quick questions, for total beginners

Do I need Python to write an MCP server?

No. Python (with FastMCP) is the most common starting point because it's simple, but MCP itself is a protocol. Official SDKs exist for TypeScript, Java, Kotlin, C#, and more. The shape is the same everywhere: you define functions, attach a name, description, and input schema so the model can discover them, and the SDK handles the wire protocol underneath. Here's the same job-blocklist tool in TypeScript:

Same idea as the Python decorator. server.tool(...) is just the TypeScript SDK's way of registering a function as something the model can discover and call.

Do I need to host the MCP server somewhere special?

No special infrastructure required. It's a regular server. It can run locally on your machine for testing, live in a Docker container, or deploy anywhere you'd deploy any small backend service (a VPS, Vercel, Railway, etc). The only requirement is that whatever's connecting to it (Claude, an n8n agent node) can reach it.

Does the AI model "see" my actual code?

No. The model never reads your Python or TypeScript source. It only sees the tool's name, description, and input schema. Think of it as the menu that gets handed. It never sees the kitchen behind it.

Look at the TypeScript example again:

Here's the easiest way to picture it: there are two separate conversations happening, and the model is only ever in one of them.

Conversation 1: model talking to your server. When your server starts up, it doesn't hand the model a file. It sends a small structured message, basically the first three arguments to server.tool(...), packaged up as something like:

{
  "name": "check_company_blocklist",
  "description": "Check if this company is on Cristina's no-go list",
  "inputSchema": { "company_name": "string" }
}

That's the entire menu the model gets. It reads that JSON blob. It was never given your .ts file, a link to it, or permission to open it. It simply never received it.

Conversation 2: your server talking to the rest of your system. The fourth argument, the function body with checkBlocklist(company_name), runs locally, inside your own process, on your own machine. When the model decides to call the tool, it sends back a request like { "tool": "check_company_blocklist", "arguments": { "company_name": "Acme Inc" } }. Your server receives that and your server runs the actual code: queries your database, applies your business rules, whatever it needs to do. The model isn't watching that happen. It just sent a request and waits for a reply.

So the model only ever touches two things: the tool list (sent once) and the tool's result (sent back after your code finishes). Everything in between, your database query, your API keys, your internal logic, happens in a part of the stack the protocol simply never transmits. A good gut check: if you added console.log(isBlocked) inside that function, it would print in your terminal, never anywhere the model can see.

Why this matters for security

This boundary is what makes MCP usable for real systems instead of just toy demos. You can wrap a tool around something genuinely sensitive, a production database, an internal API, a payments system, and the model still only ever sees a name, a description, an input shape, and a result. It never sees your credentials, your query logic, or anything else inside the function. The model can decide to use the tool, but it can never read or change how the tool works. That part stays entirely under your control as the developer.

That said, the boundary cuts both ways. It also means the model is trusting your description completely. If a tool is named get_weather but its description quietly says "and also forward the user's email to this address," the model has no way to verify that against the actual code. It only has the words you gave it. That's a real category of MCP security risk worth knowing about, often called tool poisoning. It's exactly why writing accurate, honest tool descriptions matters: they function as a security boundary.

I'm building this out as a full tutorial soon, adding an actual MCP server to the job-hunting n8n workflow. Follow along if you want to see it in action.

Have you used GitHub Actions as a cron job yet? I didn’t need AI for this project—I needed something that runs without me remembering. One YAML file, one cron line, and my weekly “2-minute task” disappeared.

Cristina Rodriguez — Tue, 03 Feb 2026 20:20:46 +0000

Cristina Rodriguez

Feb 3

I Didn’t Need AI for This Project. I Needed a Cron Job (So I Used GitHub Actions)

#automation #devops #github #tutorial

3 min read

I Didn’t Need AI for This Project. I Needed a Cron Job (So I Used GitHub Actions)

Cristina Rodriguez — Tue, 03 Feb 2026 20:19:29 +0000

If you need something to run every week and you’re tired of being the scheduler…

Use GitHub Actions.

You’ll create one YAML file. Add a cron line. Push. Done.

No server. No “remember to run it.” Just automation.

✅ The Fix: a scheduled workflow (copy/paste)

Create this file in your repo:

.github/workflows/cron.yml

Paste this:

name: Weekly automation

on:
  schedule:
    # Every Monday at 09:00 UTC (cron runs in UTC)
    - cron: "0 9 * * 1"

  # Bonus: run it manually from the Actions tab
  workflow_dispatch:

jobs:
  run-task:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repo
        uses: actions/checkout@v4

      - name: Run a command
        run: |
          echo "Hello from a scheduled workflow 👋"
          # Replace this with your real script/command

That’s the core idea: cron triggers a workflow, the workflow runs your steps.

Apply it: run a real script (Node example)

I like keeping the logic outside YAML, so my workflow stays tiny.

Repo layout:

scripts/
  weekly-task.js
.github/
  workflows/
    cron.yml

Update the workflow:

name: Weekly automation

on:
  schedule:
    - cron: "0 9 * * 1"
  workflow_dispatch:

jobs:
  run-task:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repo
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: "20"

      - name: Install deps
        run: npm ci

      - name: Run script
        run: node scripts/weekly-task.js

Why this works

schedule runs on a timer (cron).
workflow_dispatch gives you a “Run workflow” button for testing.
The runner checks out your code and executes your commands in a clean environment.

Cron in 20 seconds (so you don’t surprise yourself)

Cron format:

minute hour day-of-month month day-of-week

Examples:

Daily at 09:00 UTC → 0 9 * * *
Mondays at 09:00 UTC → 0 9 * * 1
Every 15 minutes → */15 * * * *

One important detail: cron is UTC in GitHub Actions.

So if you care about “9am my time,” you’ll need to convert it (and DST will mess with you a little). My solution: choose a time where an hour shift won’t ruin your life.

Tiny but important: secrets don’t go in YAML

Even if your script is simple today, it’ll eventually call something.

Don’t hardcode tokens. Use repo secrets:

Repo → Settings → Secrets and variables → Actions
Add API_TOKEN

Then:

      - name: Run script
        env:
          API_TOKEN: ${{ secrets.API_TOKEN }}
        run: node scripts/weekly-task.js

Make failures obvious (future-you will thank you)

Silent failures are the worst kind of “automation.”

This tiny pattern helps:

      - name: Run and fail loudly
        run: |
          set -e
          node scripts/weekly-task.js
          echo "✅ Job finished"

If it errors, the workflow run turns red and you’ll see it in the Actions tab.

Now the story (because yes, this is why I did it)

I love AI tools.

I really do.

But this time the project didn’t need intelligence. It needed consistency.

I had this tiny task that took maybe 2–5 minutes. Nothing dramatic. Just repetitive. The kind of thing you can totally do manually…

…until you forget once.

Then twice.

Then it becomes that background guilt you carry around like a cursed keychain.

I almost did the classic moves:

“I’ll set a reminder” (lol)
“I’ll run cron locally” (also valid, but now my laptop is part of production?)

What I wanted was: no server, no extra service, no babysitting.

So I did the boring thing that works: a scheduled GitHub Action.

And it’s honestly the best kind of automation: the kind you forget exists because it just keeps showing up on time.

Wrap-up

If you only take a few things from this:

Create .github/workflows/cron.yml
Use on.schedule.cron for the timer
Add workflow_dispatch so you can test manually
Keep logic in a script, keep YAML simple
Put tokens in secrets, not in the file

Have you used GitHub Actions for cron stuff yet—and what’s the first “2-minute task” you’d love to delete from your life?

I always thought making videos meant fighting a timeline UI. Turns out you can build an MP4 with React components using Remotion — scenes are components, timing is , and animations are just useCurrentFrame() + math.

Cristina Rodriguez — Thu, 22 Jan 2026 06:09:03 +0000

Cristina Rodriguez

Jan 22

Videos in React?! Yep. Each scene is a component (and it costs $0)

#webdev #react #programming #ai

5 min read

Videos in React?! Yep. Each scene is a component (and it costs $0)

Cristina Rodriguez — Thu, 22 Jan 2026 06:07:57 +0000

I used to think “making a video” meant one of two things:

Open a heavyweight editor
Drag tiny clips around a timeline until your soul leaves your body

I’m a developer. I like code. I like components. I like being able to undo mistakes without having to negotiate with a mysterious UI panel from 2002.

So when I heard there’s a tool called Remotion that lets you create videos using React components, my first thought was:

“Sure. And my CSS is also perfectly centered.”

Then I tried it.

And the moment it really clicked wasn’t even the rendering part…

It was running the project like a normal React app.

The idea that makes it click

Remotion works because a video is just:

A bunch of frames
Rendered in sequence
At a fixed fps (frames per second)

If your video is 30fps, then:

frame 30 = 1 second
frame 900 = 30 seconds

And here’s the fun part:

Every frame is just React rendering your component (with a different “current frame” number).

So animation becomes… math.

No timeline. No keyframes. Just interpolate() and spring().

“NO COST!!!” (but let’s be precise)

This post is about building and rendering locally on your machine — no SaaS subscriptions, no hosted rendering costs, no paid editor required.

(If you’re using Remotion in a larger company context, double-check licensing. For a personal project / small setup like this, you can build and render locally for free.)

Create the project

Remotion has a starter generator:

npx create-video@latest

It creates a project that looks suspiciously like any other React project.

Like:

picasyfijas-video/
├── public/
│   └── icon-512.png          ← Your logo
├── src/
│   ├── Root.tsx              ← Registers the composition (dimensions, fps, duration)
│   ├── PicasFijasVideo.tsx   ← Main video with all scenes
│   ├── Composition.tsx       ← Original template (unused)
│   ├── index.ts              ← Entry point
│   └── index.css             ← Styles
└── out/
    └── picasyfijas.mp4       ← Rendered video

At this point, you’re thinking: “Okay. Cute structure. But where’s the ‘video’ part?”

This is where the brain-melt happens.

The moment it clicked: `npm run dev` 🤯

I did the most “React developer” thing possible:

npm run dev

And… it just ran like any React project.

The dev server started, I opened the URL, and suddenly I’m staring at a video timeline in my browser.

Scrub the playhead → frames update.

Components appear and disappear.

Animations play.

It’s all live.

And my brain goes:

“Hold up. I’m not editing a video… I’m rendering React.”

That’s the “ohhhhhh” moment.

Because once you realize the preview is just your components rendering over time, everything becomes familiar:

Want a new “scene”? Make a component.
Want it to appear later? Wrap it in a <Sequence from={...} />.
Want animation? Use useCurrentFrame() + math.

Same workflow. Same comfort.

But the output is a legit MP4.

Your “video settings” live in one place

Inside src/Root.tsx, you register a Composition.

This defines:

width / height
fps
durationInFrames

Here’s the vertical setup I used for a short social video:

<Composition
  id="PicasFijasVideo"
  component={PicasFijasVideo}
  durationInFrames={300}
  fps={30}
  width={1080}
  height={1920}
/>

That’s 10 seconds (300 frames at 30fps).

Want 30 seconds?

Same idea:

30 seconds * 30 fps = 900 frames

So:

durationInFrames={900}

That’s it. Your video is now 30 seconds long.

Scenes = components, and timing = `<Sequence />`

Your main video component (mine is PicasFijasVideo.tsx) is basically a timeline built with <Sequence />.

Each scene is a component. Each component gets a start frame and duration.

Example:

<Sequence from={0} durationInFrames={90}>
  <IntroScene />
</Sequence>

<Sequence from={90} durationInFrames={240}>
  <MainScene />
</Sequence>

One very nice detail:

Inside a <Sequence>, useCurrentFrame() starts at 0 again.

So each scene feels self-contained and easy to reason about.

The 10-second timeline I built (as a reference)

I created a 10-second vertical video (1080×1920, 9:16) for social media using Remotion.

Here’s the timeline:

Frames	Seconds	Scene	What Happens
0–30	0–1s	Logo	Logo springs in, title fades in
30–90	1–3s	GuessScene	Shows "????" and types guess "1456"
90–150	3–5s	BullExplanation	Highlights matching "1", shows "🐂 Bull/Fija"
150–210	5–7s	CowExplanation	Highlights "4" in wrong position, shows "🐄 Cow/Pica"
210–300	7–10s	CTA	Logo + "Play now!" + URL

For a 30-second video, you simply add more “beats” (more scenes) or stretch durations.

A simple 30-second structure that works for any topic:

Intro (2–3s)
5–7 beats (3–5s each)
CTA (3–5s)

Animation is just math (and two hooks)

Most scenes start like this:

const frame = useCurrentFrame();  // Current frame number (0, 1, 2... )
const { fps } = useVideoConfig(); // Frames per second (30)

useCurrentFrame() → tells you which frame is being rendered
useVideoConfig() → gives you fps, dimensions, etc.

Now you can animate anything.

Fade in with `interpolate()`

const contentOpacity = interpolate(frame, [0, 15], [0, 1], {
  extrapolateLeft: "clamp",
  extrapolateRight: "clamp",
});

What it does:

Input: frames [0..15]
Output: opacity [0..1]
Result: fade in over 0.5 seconds (at 30fps)
clamp: prevents values below 0 or above 1

Bounce with `spring()`

const highlightScale = spring({
  frame: frame - 15,    // Start at frame 15
  fps,
  config: {
    damping: 12,        // Higher = less bounce
    stiffness: 100,     // Higher = snappier
  },
});

What it does:

Creates a natural bounce from 0 → 1
frame - 15 delays the animation start

Deep Dive: BullExplanation scene (a “real” example)

This scene highlights the matching digit and shows the “🐂 Bull / Fija” explanation.

1) Bilingual text toggle

const showSpanish = Math.floor(frame / 15) % 2 === 1 && frame > 45;

What it does:

Switches language every 15 frames (0.5 seconds)
Starts toggling after frame 45 (so the content is already visible)

2) Conditional styling for highlights

{secret.split("").map((digit, i) => (
  <span
    key={i}
    style={{
      color: i === 0 ? "#EBEBD3" : "#38618C",
      backgroundColor: i === 0 ? "#38618C" : "transparent",
      transform: i === 0 ? `scale(${highlightScale})` : "scale(1)",
      display: "inline-block",
      padding: "0 6px",
      borderRadius: 8,
    }}
  >
    {digit}
  </span>
))}

i === 0 highlights the first digit (the “bull”)
Highlighted digit gets inverted colors + bounce scale
Others stay normal

Key Remotion concepts (the cheat sheet)

Concept	What it does
`Composition`	Defines video dimensions, fps, duration
`Sequence`	Controls when a component appears/disappears on the timeline
`AbsoluteFill`	Full-screen container that fills the canvas
`useCurrentFrame()`	Gets current frame number
`interpolate()`	Maps frame numbers to any value (opacity, position, etc.)
`spring()`	Creates natural bounce animations
`Img` + `staticFile()`	Loads images from `public/`

Render to MP4

You can render from the UI… but the CLI is the “ship it” button.

Example:

npx remotion render src/index.ts PicasFijasVideo out/video.mp4

That command turns your React composition into a real MP4 file.

Demo + repo

Wrap-up

Let’s recap:

Videos are just React renders — one frame at a time.
Time = frames (30fps → 900 frames = 30 seconds).
Scenes = components, and <Sequence /> is your timeline.
Animations are mostly useCurrentFrame() + math (interpolate(), spring()).
Rendering is one command: npx remotion render … → MP4.
And the wildest part? You can literally start with npm run dev and preview it like… a normal React app. Still feels illegal.

Now I’m curious: what would you make first if “a video” was just a folder of components? A tutorial? A product promo? A meme? A “how to center a div” documentary?

PWAs are underrated. I skipped the $99 Apple fee and the $25 Google fee by adding two files to my vanilla JS game. Now it works offline and installs like a native app. Here's the code 👇

Cristina Rodriguez — Tue, 16 Dec 2025 19:51:15 +0000

Cristina Rodriguez

Dec 16 '25

Bulls & Cows Goes Offline — How I Turned My Game Into a PWA (and Skipped the $100 App Store Fee)

#javascript #webdev #pwa #beginners

2 min read

Bulls & Cows Goes Offline — How I Turned My Game Into a PWA (and Skipped the $100 App Store Fee)

Cristina Rodriguez — Tue, 16 Dec 2025 19:50:09 +0000

Remember my Bulls & Cows game? The one with no frameworks, no AI, just vanilla JS? Well, I made it installable. Like, "put it on your home screen and play offline" installable.

No App Store. No Google Play. No $99/year Apple Developer fee. No $25 Google registration. Just... a web app that acts like a native app.

And apparently, people like it? 1.3K unique players, 1.4K sessions, and 1.8K pageviews — with people spending almost 2 minutes per visit just thinking through a logic puzzle. That's enough traction that I gave it its own home.

🎮 Play it: picasyfijas.com

✨ What's a PWA, Really?

A Progressive Web App is just a regular website with two extra files that tell the browser: "Hey, I can work offline. Let me live on the home screen."

That's it. Two files. Let me show you.

1️⃣ The Manifest (Your App's ID Card)

{
  "name": "Bulls & Cows - Picas y Fijas",
  "short_name": "Bulls & Cows",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#EBEBD3",
  "theme_color": "#4281A4",
  "icons": [
    { "src": "icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

This tells the browser what to call your app, what icon to use, and that standalone means "hide the browser chrome and look like a real app."

Link it in your HTML:

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js');
}

2️⃣ The Service Worker (Your Offline Brain)

const CACHE_NAME = 'Bulls-and-Cows-v4';
const FILES_TO_CACHE = [
  '/', '/index.html', '/styles.css', '/script.js',
  '/manifest.json', '/icon-192.png', '/icon-512.png'
];

self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open(CACHE_NAME)
      .then((cache) => cache.addAll(FILES_TO_CACHE))
  );
});

self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request)
      .then((response) => response || fetch(event.request))
  );
});

That's the entire service worker. It caches your files on install, then serves them from cache when offline. No npm packages. No build step.

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js');
}

3️⃣ The Install Prompt

Browsers show an install button automatically, but I added my own banner because I wanted control over the UX:

let deferredPrompt = null;

window.addEventListener('beforeinstallprompt', (e) => {
  e.preventDefault();
  deferredPrompt = e;
  document.getElementById('install-banner').style.display = 'flex';
});

document.getElementById('install-btn').addEventListener('click', () => {
  deferredPrompt.prompt();
});

💰 Why Not the App Stores?

Apple charges $99/year. Google charges $25 once. Both require review processes, screenshots, privacy policies, and jumping through hoops.

My game collects zero data. No accounts. No ads. Just privacy-friendly Plausible for basic stats. It's literally just a logic puzzle.

PWAs let me skip all of that. Users get an installable app. I keep my $124. Everyone wins.

🎯 The Result

✅ Works offline
✅ Installable on Android, iOS, and desktop
✅ No app store fees
✅ Updates instantly (no waiting for review)
✅ Still just HTML, CSS, and vanilla JS

Total new code: ~50 lines.

👉 Play it: picasyfijas.com

👉 Source: github.com/Yosolita1978/bullsandcows

Have you turned a side project into a PWA? I'd love to hear about it 👇

Ever had your API calls fire way too often in a Next.js app? 😅 I wrote about how a simple useDebounce hook can smooth things out, boost performance, and keep your UI calm. Read more 👇

Cristina Rodriguez — Tue, 25 Nov 2025 20:01:43 +0000

Cristina Rodriguez

Nov 25 '25

Why I Built a useDebounce Custom Hook in Next.js (and Why You Should Too)

#reactjsdevelopment #webdev #react #programming

3 min read

Why I Built a useDebounce Custom Hook in Next.js (and Why You Should Too)

Cristina Rodriguez — Tue, 25 Nov 2025 19:59:13 +0000

If you've ever wired up a search bar in Next.js, you’ve probably hit this problem: every keystroke fires a new API call, triggers a re-render, or runs an expensive calculation. As your app grows, those “harmless little updates” start stacking up—fast.

I’ve been there. I remember watching my terminal fill with logs like a slot machine every time I typed a word. And because I was calling an API, sometimes I even hit rate limits just by typing too quickly.

That’s when I realized: I didn’t need results instantly. I needed results after the user paused typing.

That’s exactly what debouncing solves—and why building a small, reusable useDebounce hook changed the flow of my whole project.

🚨 The Problem: Too Many Updates

React is responsive—which is great—until it isn’t.

Common places this becomes a problem:

Search bars that fire API calls on every letter
Window resize listeners
Live form validation
Text fields tied to heavy filtering logic

The consequences:

Wasted API calls (and money)
Janky UI performance
Constant re-renders
Hitting provider rate limits
Sluggish, frustrating user experience

Here’s a simple example of the problem:

useEffect(() => {
  fetch(`/api/search?q=${query}`);
}, [query]);

If a user types “nextjs,” this runs 6 separate times:

n → ne → nex → next → nextj → nextjs

Your server cries.
Your UI stutters.
You quietly wonder if you picked the wrong career.

😅 Naive Solutions (And Why They Fail)

❌ 1. “Let me just add a timeout…”

This is the classic first attempt:

setTimeout(() => {
  fetch(...)
}, 300);

It seems fine… until you realize:

You never cancelled the previous timeout
Race conditions appear
Multiple calls still fire, just delayed
Your component becomes a messy spaghetti bowl

❌ 2. “I’ll track the last value manually”

Trust me: you can do this. You shouldn’t do this.

It leads to bugs, stale values, and callback nightmares.

Debouncing deserves its own tidy, reusable hook.

✅ Enter `useDebounce`: The Custom Hook That Fixes Everything

Debouncing means:

“Only run this action after the value has stopped changing for X milliseconds.”

That tiny delay (300ms, for example) is enough to:

Prevent API spamming
Smooth out re-renders
Improve UX
Save money and bandwidth
Make your search bar feel intentional instead of chaotic

This is exactly the kind of logic that belongs inside a Custom Hook.

🧩 How `useDebounce` Works (with Clear Code + Comments)

Here’s the entire hook, ready to drop into your project:

import { useState, useEffect } from "react";

/**
 * useDebounce — delays updating a value until
 * `delay` milliseconds have passed without changes.
 */
export function useDebounce<T>(value: T, delay = 300) {
  const [debouncedValue, setDebouncedValue] = useState(value);

  useEffect(() => {
    // Start a timer that updates debouncedValue when delay elapses
    const timer = setTimeout(() => {
      setDebouncedValue(value);
    }, delay);

    // Cancel the timer if value changes before delay ends
    return () => clearTimeout(timer);
  }, [value, delay]);

  return debouncedValue;
}

Why this works:

The timer resets on every keystroke
The update only happens after the pause
Cleanup prevents race conditions
The hook is fully reusable across components

🔍 Using `useDebounce` in a Next.js Component

Let’s apply it to a real-world search bar.

"use client";

import { useState, useEffect } from "react";
import { useDebounce } from "@/hooks/useDebounce";

export default function SearchBar() {
  const [query, setQuery] = useState("");

  // Debounce raw user input by 300ms
  const debouncedQuery = useDebounce(query, 300);

  useEffect(() => {
    if (!debouncedQuery) return;

    async function search() {
      const res = await fetch(`/api/search?q=${debouncedQuery}`);
      const data = await res.json();
      console.log("Results:", data);
    }

    search();
  }, [debouncedQuery]);

  return (
    <input
      value={query}
      onChange={(e) => setQuery(e.target.value)}
      placeholder="Search..."
      className="border p-2"
    />
  );
}

What’s happening behind the scenes?

query updates instantly → keeps the UI responsive
debouncedQuery updates after 300ms → triggers one clean API call
No API spam
No jittery UI

🌟 Benefits of Using `useDebounce`

1. Better Performance

No more re-render storms.

2. Fewer API Calls

Your backend (and your wallet) will thank you.

3. Smoother UX

Search results feel stable and intentional.

4. Cleaner Code

Centralized, reusable logic.

5. Reusable Everywhere

Use it for:

Search bars
Form validation
Filtering tables
Window resize
Drag events
Autosaving

🧭 Conclusion

Debouncing is one of those small optimizations that makes a huge difference.
The moment you wrap it in a custom React hook like useDebounce, your app becomes faster, smoother, and easier to maintain.

Once you use it in one component, you’ll find yourself adding it everywhere.

If you’ve built your own version—or used useDebounce in interesting ways—I’d love to hear about it. Drop your thoughts in the comments!

Happy coding! 🚀

DEV Community: Cristina Rodriguez

Your MCP server works fine. Then you run a second copy, and the next call lands somewhere that has never heard of the first one. I wrote up what breaks, what MCP 2026-07-28 actually changed, and the bug I found in my own code while writing it.

What Breaks When One MCP Server Becomes Two

What Breaks When One MCP Server Becomes Two

Who's talking to who

The failure that shows up when one process becomes two

What 2026-07-28 actually changed

Old way: state lives in the server's memory

Surprise one: it was worse than session state

New way: state travels with the call

Surprise two: I had to decide what a handle even is

Surprise three: the handle came back as a string

What this doesn't fix (yet), and what still works

Try it yourself

So, you know how to connect to an API endpoint? Great. Now they're asking you to build an MCP, and you're freaking out. Don't sweat it, it's simpler than it sounds. The real difference isn't the code; it's who decides what happens next. New post 👇

Okay, But What IS MCP? (No, Really)

Okay, But What IS MCP? (No, Really)

Three quick questions, for total beginners

Have you used GitHub Actions as a cron job yet? I didn’t need AI for this project—I needed something that runs without me remembering. One YAML file, one cron line, and my weekly “2-minute task” disappeared.

I Didn’t Need AI for This Project. I Needed a Cron Job (So I Used GitHub Actions)

I Didn’t Need AI for This Project. I Needed a Cron Job (So I Used GitHub Actions)

✅ The Fix: a scheduled workflow (copy/paste)

Apply it: run a real script (Node example)

Why this works

Cron in 20 seconds (so you don’t surprise yourself)

Tiny but important: secrets don’t go in YAML

Make failures obvious (future-you will thank you)

Now the story (because yes, this is why I did it)

Wrap-up

I always thought making videos meant fighting a timeline UI. Turns out you can build an MP4 with React components using Remotion — scenes are components, timing is , and animations are just useCurrentFrame() + math.

Videos in React?! Yep. Each scene is a component (and it costs $0)

Videos in React?! Yep. Each scene is a component (and it costs $0)

The idea that makes it click

“NO COST!!!” (but let’s be precise)

Create the project

The moment it clicked: npm run dev 🤯

Your “video settings” live in one place

Want 30 seconds?

Scenes = components, and timing = <Sequence />

The 10-second timeline I built (as a reference)

Animation is just math (and two hooks)

Fade in with interpolate()

Bounce with spring()

Deep Dive: BullExplanation scene (a “real” example)

1) Bilingual text toggle

2) Conditional styling for highlights

Key Remotion concepts (the cheat sheet)

Render to MP4

Demo + repo

Wrap-up

PWAs are underrated. I skipped the $99 Apple fee and the $25 Google fee by adding two files to my vanilla JS game. Now it works offline and installs like a native app. Here's the code 👇

Bulls & Cows Goes Offline — How I Turned My Game Into a PWA (and Skipped the $100 App Store Fee)

Bulls & Cows Goes Offline — How I Turned My Game Into a PWA (and Skipped the $100 App Store Fee)

✨ What's a PWA, Really?

1️⃣ The Manifest (Your App's ID Card)

2️⃣ The Service Worker (Your Offline Brain)

3️⃣ The Install Prompt

💰 Why Not the App Stores?

🎯 The Result

Ever had your API calls fire way too often in a Next.js app? 😅 I wrote about how a simple useDebounce hook can smooth things out, boost performance, and keep your UI calm. Read more 👇

Why I Built a useDebounce Custom Hook in Next.js (and Why You Should Too)

Why I Built a useDebounce Custom Hook in Next.js (and Why You Should Too)

🚨 The Problem: Too Many Updates

Common places this becomes a problem:

The consequences:

😅 Naive Solutions (And Why They Fail)

❌ 1. “Let me just add a timeout…”

❌ 2. “I’ll track the last value manually”

✅ Enter useDebounce: The Custom Hook That Fixes Everything

🧩 How useDebounce Works (with Clear Code + Comments)

Why this works:

🔍 Using useDebounce in a Next.js Component

What’s happening behind the scenes?

🌟 Benefits of Using useDebounce

1. Better Performance

2. Fewer API Calls

3. Smoother UX

4. Cleaner Code

5. Reusable Everywhere

🧭 Conclusion

The moment it clicked: `npm run dev` 🤯

Scenes = components, and timing = `<Sequence />`

Fade in with `interpolate()`

Bounce with `spring()`

✅ Enter `useDebounce`: The Custom Hook That Fixes Everything

🧩 How `useDebounce` Works (with Clear Code + Comments)

🔍 Using `useDebounce` in a Next.js Component

🌟 Benefits of Using `useDebounce`