DEV Community: zishuowang696

I gave my blog an agent: auto topic ideas every week

zishuowang696 — Sun, 11 Oct 2026 12:30:03 +0000

The annoying part of running a blog isn't writing — it's picking topics. What do I write today? It's guesswork, and it eats time.

So I gave it an agent: every Monday it reads my published posts (to avoid repeats) and proposes 5 new topics. It runs on GitHub Actions — free, scheduled, no server.

And the essence never changes: an agent is a loop — call the API to ask the model → run the tool → feed the result back.

What it actually does

One loop, one tool:

TOOLS = [{
    "type": "function",
    "function": {
        "name": "list_existing_titles",
        "description": "read existing post titles to avoid duplicates",
        "parameters": {"type": "object", "properties": {}},
    },
}]

def run_tool(name, args):
    if name == "list_existing_titles":
        xml = urlopen(FEED).read().decode("utf-8", "ignore")   # read the site RSS
        titles = re.findall(r"<title>(.*?)</title>", xml, re.S)
        return "\n".join(titles[1:])

Model is DeepSeek (OpenAI-compatible). The loop:

def agent(user_input):
    messages = [{"role": "user", "content": user_input}]
    while True:
        msg = client.chat.completions.create(model=MODEL, messages=messages, tools=TOOLS).choices[0].message
        messages.append(msg)
        if not msg.tool_calls:
            return msg.content                     # no more tools -> answer
        for call in msg.tool_calls:                # run the tool -> feed it back
            args = json.loads(call.function.arguments or "{}")
            messages.append({"role": "tool", "tool_call_id": call.id,
                             "content": run_tool(call.function.name, args)})

Output goes to weekly/<date>.md. That's it — no framework, just a loop.

Why GitHub Actions

To me this is the neat part:

Free: public repo, unlimited minutes;
Scheduled: on: schedule: cron, runs weekly;
No server: nothing to host;
Internet access: runners are in the US, reaching DeepSeek / Google APIs directly;
Repo access: it can commit the result back.

on:
  schedule: [{ cron: '0 1 * * 1' }]
  workflow_dispatch: {}
permissions: { contents: write }
# ... pip install -> python agent/topics.py -> git commit weekly/

Secrets go in Secrets (DEEPSEEK_API_KEY); site config in Variables (SITE_FEED/SITE_BRIEF) — never in code.

It actually delivered

On its first run it read 17 published posts and replied (excerpt):

The existing content is mostly low-level build / framework internals, but "running an agent on an edge device" is almost a blank spot. The 5 topics below all land in that gap…

Then it gave 5 topics plus a scheduling plan (lead-gen → conversion → moat). Honestly, better than my gut.

My principle: the agent does the dirty work, the human judges

That's also why I kept it small and open-sourced only the framework:

Agent does the dirty / half-done work: topics, drafts, retros, distribution copy;
Human judges and publishes: which one, how to write, whether to ship;
Open architecture, private data: the framework is open; but data, keys, keyword lists, business strategy stay private.

For instance, my real prompt, keyword list, and GSC data live in a private repo — what's public is only how it's built.

Add a tool to read a GSC export (topics with impressions but no clicks first);
Add a "draft agent" (first-pass drafts);
But publishing always stays with the human.

📦 Reusable template (private bits removed): github.com/zishuowang696/weekly-topics-agent

Questions or feedback? Open an issue on the repo above.

MCP in 30 lines: it's just standardized function calling

zishuowang696 — Sun, 11 Oct 2026 12:27:08 +0000

In Building an AI agent from scratch, our cat tool was hardcoded inside the agent:

# the tool lives inside your program
TOOLS = [{"function": {"name": "cat", "...": "..."}}]

def run_tool(name, args):
    ...

The problem is obvious: switch apps and you rewrite it all. A tool you wrote is only usable by you.

MCP (Model Context Protocol) fixes exactly that — it turns a tool into a standalone process, exposed over one standard protocol that any LLM app can connect to.

In one line: MCP = standardized function calling. It doesn't change the loop from the last post; it just standardizes where tools come from and how they're called.

The three roles

Host: the LLM app you use — Claude Desktop, Cursor, or your own agent.
Client: a small piece inside the host that talks to the server (usually the host builds it for you).
Server: the part you write — a process exposing Tools, Resources and Prompts.

The most common transport is stdio: the client launches the server process and they exchange one JSON per line (JSON-RPC) over stdin/stdout.

Some call it "USB-C for AI" — one port, any device.

A 30-line MCP server

Turn last post's cat into an MCP server (server.py):

import json, subprocess, sys

TOOLS = [{
    "name": "cat",
    "description": "Read the full contents of a file",
    "inputSchema": {
        "type": "object",
        "properties": {"path": {"type": "string", "description": "file path"}},
        "required": ["path"],
    },
}]

def handle(msg):
    m = msg["method"]
    if m == "initialize":
        return {"protocolVersion": msg["params"]["protocolVersion"],
                "capabilities": {"tools": {}},
                "serverInfo": {"name": "cat-mcp", "version": "0.1"}}
    if m == "tools/list":
        return {"tools": TOOLS}
    if m == "tools/call":
        path = msg["params"]["arguments"]["path"]
        out = subprocess.run(["cat", path], capture_output=True, text=True)
        return {"content": [{"type": "text", "text": out.stdout or out.stderr}]}
    return {}

for line in sys.stdin:
    req = json.loads(line)
    if "id" not in req:      # a notification — no reply needed
        continue
    res = handle(req)
    sys.stdout.write(json.dumps({"jsonrpc": "2.0", "id": req["id"], "result": res}) + "\n")
    sys.stdout.flush()

That's it. An MCP server is just "read a JSON line → dispatch by method → write a JSON line".

A 30-line client

A client does three things: handshake → list tools → call (client.py):

import json, subprocess, sys

proc = subprocess.Popen([sys.executable, "server.py"],
                        stdin=subprocess.PIPE, stdout=subprocess.PIPE, text=True)
_id = 0

def rpc(method, params=None, notify=False):
    global _id
    msg = {"jsonrpc": "2.0", "method": method}
    if params is not None:
        msg["params"] = params
    if not notify:
        _id += 1
        msg["id"] = _id
    proc.stdin.write(json.dumps(msg) + "\n")
    proc.stdin.flush()
    return None if notify else json.loads(proc.stdout.readline())

rpc("initialize", {"protocolVersion": "2024-11-05", "capabilities": {},
                   "clientInfo": {"name": "demo", "version": "0.1"}})
rpc("notifications/initialized", notify=True)          # handshake done

print("tools:", rpc("tools/list"))
print("call:", rpc("tools/call", {"name": "cat", "arguments": {"path": "/etc/hostname"}}))

Run it:

python client.py
# tools: {'tools': [{'name': 'cat', ...}]}
# call: {'content': [{'type': 'text', 'text': 'your-hostname'}]}

vs. the last post

	Last post (hardcoded)	This post (MCP)
Tool definition	lives in the agent code	standalone process, declared via `tools/list`
Tool invocation	a direct function call	`tools/call` JSON-RPC
Who can use it	only you	any MCP-capable host

Nothing essential changed: still the loop "ask the model → run the tool → feed the result back." MCP just standardizes the tool, so what you write is reusable by any LLM app — swap the model, plug in tools, keep the loop.

📦 Complete runnable code: github.com/zishuowang696/mcp-demo