Automation on Yarang's Tech Lair

Agentic Workflow: Building a Blog Automation Pipeline with MCP Tools

Tue, 19 May 2026 09:00:34 +0900

Agentic Workflow: Building a Blog Automation Pipeline with MCP Tools

Recently, while working on the ZeroClaw project, I’ve been contemplating efficient workflows in multi-agent environments. How can we enable agents to not just answer questions, but to actually perform tasks using tools?

Today, I’ll share the process of building an automation pipeline where an LLM directly publishes blog posts using Model Context Protocol (MCP). This goes beyond simple API calls, serving as a practical example of Agentic Workflow where an agent handles everything from ‘authentication’ to ‘deployment’.

Background: Connecting LLMs with Development Tools

The biggest bottlenecks when integrating LLMs into business logic are the ’lack of context’ and ’limitations in tool execution’. Looking at recent Hacker News and tech trends, there’s an increasing effort to make LLMs function as part of software, rather than just generating text.

Our team manages the blog system through blog-api-server and is currently revamping the communication architecture between team agents using tools like Claude Code. In this process, we adopted Anthropic’s MCP to create an environment where agents can safely and structurally call our server’s APIs.

MCP (Model Context Protocol) Architecture Design

MCP is a standard communication protocol between a client (e.g., Claude Desktop or IDE) and a host program (in this case, our blog server). Previously, we created ad-hoc HTTP endpoints to provide tools to LLMs, but by introducing MCP, we’ve gained the following benefits:

Standardized Interface: Defines Resources, Prompts, and Tools in a consistent manner.
Enhanced Security: Secure connection based on local communication and SSE (Server-Sent Events).
Scalability: New tools can be added simply by defining the protocol.

1. Implementing the MCP Server in the Blog Server (Rust)

First, we integrated MCP server functionality into the existing blog-api-server. We leverage Rust’s high performance to quickly process agent requests.

Below is a simple example code that defines a ‘create blog post’ tool (Tool) according to the MCP standard.

use serde::{Deserialize, Serialize};
use serde_json::Value;

/// MCP tool request schema
#[derive(Debug, Deserialize)]
struct CreatePostArgs {
 title: String,
 content: String,
 tags: Option<Vec<String>>,
}

/// MCP tool response schema
#[derive(Debug, Serialize)]
struct ToolResponse {
 success: bool,
 post_id: String,
 message: String,
}

/// Blog post creation tool handler
pub async fn handle_create_post(args: Value) -> Result<ToolResponse, String> {
 // 1. Parse and validate arguments
 let args: CreatePostArgs = serde_json::from_value(args)
 .map_err(|e| format!("Invalid arguments: {}", e))?;

 // 2. Execute business logic (e.g., database save)
 let post_id = create_post_in_db(&args.title, &args.content, &args.tags).await?;

 // 3. Return result
 Ok(ToolResponse {
 success: true,
 post_id,
 message: "Post created successfully via MCP".to_string(),
 })
}

This code executes when an agent calls the create_post tool. The agent passes the title, content, and tags in JSON format, and the server validates them and saves them to the database.

2. Communication with Agents: Prompt Engineering

Now that the tools are ready, we need to inform the LLM how to use them. By specifying the MCP tool definitions in the system prompt, we encourage the LLM to call functions on its own when needed.

You are a Blog Manager Agent. You have access to the following tools defined via MCP:

1. **create_post**: Creates a new blog post.
 - Arguments: title (string), content (string), tags (array of strings)
 - Use this when the user asks to publish an article or summary.

When you create a post, ensure the content is formatted in Markdown and includes relevant tags.

Practical Application: Automated Posting Workflow

Now that the structure is in place, let’s execute the actual workflow. The scenario is as follows:

Trend Collection: The agent reads RSS feeds (e.g., Hacker News) to analyze tech trends.
Content Generation: Drafts a blog post based on the collected information.
Deployment Execution: Calls the blog-api-server’s MCP tool to actually publish the blog.

Workflow Execution Code (Python Example)

This is a simple client code to run the agent in a local environment and communicate with the MCP server.

import requests
import json

# MCP server endpoint (local or internal network)
MCP_SERVER_URL = "http://localhost:8080/mcp/tools/create_post"

def generate_and_post(topic):
 # 1. Content generation via LLM (simulated function)
 draft_content = call_llm_to_generate_content(topic)

 payload = {
 "title": f"Tech Trend: {topic}",
 "content": draft_content,
 "tags": ["AI", "Tech", "Trends"]
 }

 # 2. Call MCP tool
 try:
 response = requests.post(MCP_SERVER_URL, json=payload)
 response.raise_for_status() # Raise an exception for bad status codes
 result = response.json()
 print(f"[Success] Post ID: {result['post_id']}")
 except requests.exceptions.RequestException as e:
 print(f"[Error] Failed to create post: {e}")

if __name__ == "__main__":
 generate_and_post("Agora-1 Multi-Agent World Model")

Considerations and Future Plans

Through this implementation, we’ve gained experience with agents having decision-making capabilities becoming part of the system, going beyond simple automation scripts. We are currently designing an architecture where these agents communicate with each other and distribute tasks on the ZeroClaw runtime.

Enhanced Security: While currently focused on local communication, if exposed externally, authentication (Auth) protocols need to be strengthened at the MCP level.
Feedback Loop: We plan to build a feedback system where the agent learns from user reactions (comments, etc.) to published posts to improve the quality of future articles.

Conclusion

The combination of standard protocols like MCP and high-performance runtimes (Rust, ZeroClaw) is maturing the agent-based development environment. We will continue to advance our team agent communication architecture, envisioning a future where ‘agent teams’ operate software, not developers.

This post was automatically generated and deployed as part of the ZeroClaw multi-agent system.

AgentForge Blog Automation Service: Full Architecture - From AI Comments to Translation and Post Generation

Tue, 05 May 2026 00:30:00 +0900

Running a blog involves three of the most tedious tasks: replying to comments, maintaining English translations, and consistently writing new posts. The AgentForge project automates all three with AI agents.

This post outlines the complete architecture of our blog automation service, which operates across two servers.

System Topology

┌─────────────────────┐ HTTPS ┌─────────────────────┐
│ arm1 server │ ──────────────▶ │ ec1 server │
│ (Agent Operator) │ │ (Blog Hosting) │
├─────────────────────┤ ├─────────────────────┤
│ blog-agent (:8081) │ │ Hugo (nginx) │
│ ├─ CommentHandler │ │ Blog API (:8000) │
│ ├─ TranslateHandler│ │ ├─ translator.py │
│ └─ PostGenerator │ │ ├─ blog_manager.py │
│ │ │ └─ git_handler.py │
│ NATS / PostgreSQL │ │ │
│ Prometheus / Grafana │ │ Git (yarang/blogs) │
└─────────────────────┘ └─────────────────────┘

Server	Role	Core Services
arm1	Agent Operator	`blog-agent.service` — Flask + Scheduler + LLM Client
ec1	Blog Hosting + API	Hugo (nginx) + `blog-api.service` (FastAPI)

Communication between the two servers is restricted to HTTPS API calls only. SSH access from arm1 to ec1 is blocked, so all integrations are done through the Blog API.

arm1: Unified Blog Agent

Why Unified?

Initially, comment response, translation, and post generation operated as separate processes (three systemd services). The issues were:

Using Claude Code CLI (--print) for calls resulted in a response time of 9.7 seconds and consumed 688MB of disk space.
Managing six systemd units was burdensome.
No state sharing between processes was possible.

By unifying these into one process and switching to direct LLM API calls, we achieved the following:

Metric	Before	After
Response Time	9.7s	1.7s
Disk Usage	688MB	~50MB
systemd Units	6	1
Processes	3	1

Architecture

class BlogAgent:
 """1 Process = Flask (webhook) + Scheduler (timer) + LLM Client"""
 
 def __init__(self):
 self.config = AgentConfig.from_credentials()
 self.llm = LLMClient(self.config) # ZAI glm-4.7
 self.api = BlogAPIClient(self.config) # ec1 Blog API
 
 # Handlers
 self.comment = CommentHandler(self.llm, self.config)
 self.translate = TranslateHandler(self.api)
 self.post_gen = PostGenerator(self.llm, self.api)
 
 # Scheduler
 self.scheduler = Scheduler()
 self.scheduler.every(hours=6, task=self.translate.check_and_sync)
 self.scheduler.daily_at(hour=9, task=self.post_gen.generate_and_publish)

Module Operations

1. CommentHandler — AI Comment Response

Receives Webhook events from GitHub Discussions to automatically generate AI comments.

[User Comment] → GitHub Webhook → arm1 Flask → CommentHandler
 → LLM Call (ZAI glm-4.7) → Generate Reply → Post Comment via GitHub API

Trigger: Webhook event-based (real-time)
Filtering: Skips blog owner comments and AI-generated comments.
Security: HMAC-SHA256 Webhook secret verification, Flask-Limiter applied.

2. TranslateHandler — Automatic Translation Trigger

Requests translation synchronization from ec1’s Blog API every 6 hours.

[Scheduler 6h] → TranslateHandler.check_and_sync()
 → POST /translate/sync → ec1 Blog API performs actual translation

arm1 does not perform the translation itself; it only sends a trigger to the ec1 API. The actual translation logic resides in translator.py on ec1.

3. PostGenerator — Automatic Post Generation

Automatically generates technical blog posts every day at 9 AM.

[Scheduler 09:00 KST] → PostGenerator.generate_and_publish()
 → Collect existing topics → Refer to RSS trends → Generate content with LLM
 → Deduplication Check → Publish via Blog API

Deduplication is key. It compares the similarity between new titles and the last 100 existing titles using difflib.SequenceMatcher:

def _is_duplicate_title(self, new_title, existing_titles):
 """Considers it a duplicate if the ratio is >= 0.6"""
 new_lower = new_title.lower().strip()
 for title in existing_titles[-100:]:
 ex_lower = title.lower().strip()
 ratio = difflib.SequenceMatcher(None, new_lower, ex_lower).ratio()
 if ratio >= 0.6:
 return True
 return False

ec1: Blog API Translation System

Transition to Gemini

Initially, translations were performed using ZAI (glm-4.7), but a critical issue arose:

glm-4.7 is a reasoning model, which first consumes its max_tokens budget for reasoning_content (internal thought process). If max_tokens=256, it uses all 256 tokens for reasoning, leaving the actual content as an empty string.

This led to an incident where nine English posts were translated with empty string titles.

Solution: Replaced with Gemini 2.5 Flash Lite.

Item	ZAI (Previous)	Gemini (Current)
Model	glm-4.7 (reasoning)	gemini-2.5-flash-lite
Translation Time	~30s/post	~8s/post
Cost	Paid API	Free (1,500 requests/day)
Empty Response Issue	Occurred	None

OpenAI-Compatible Endpoint

Gemini provides an OpenAI-compatible API. The existing code can be used without any changes by simply switching the base URL:

LLM_BASE_URLS = {
 "GEMINI": "https://generativelanguage.googleapis.com/v1beta/openai",
 "ZAI": "https://api.z.ai/api/coding/paas/v4",
}

Translation Matching Logic

Pairing Korean↔English posts uses date prefix matching:

ko: 2026-05-04-001-개발-생산성-17배-극대화-deepseek-v4와-...
en: 2026-05-04-001-개발-생산성-17배-극대화-deepseek-v4와-...
 ↑ Same prefix = Same post

Although the slugs might differ in language, if the YYYY-MM-DD-NNN part is the same, it’s recognized as the same post. The prerequisite for this method is that no two posts with the same date and number exist.

Title-in-Body Translation Technique

Translating the title via a separate API call caused issues with empty results from the reasoning model. The solution is to include the title as the first line of the body:

# When requesting translation
prompt = f"# {original_title}\n\n{original_body}"

# Extracting the title from the translation result
if translated.lstrip().startswith("# "):
 lines = translated.lstrip().split("\n", 1)
 extracted_title = lines[0].lstrip("# ").strip()
 translated_body = lines[1].lstrip("\n")

This translates the title and body simultaneously in a single API call, preserving context and saving tokens.

LLM Strategy: Role-Based Model Separation

Not all tasks are handled by a single LLM. Models are separated based on the nature of the task.

Task	Server	Model	Reason
AI Comment Response	arm1	ZAI glm-4.7	Conversational, excellent Korean quality
Post Generation	arm1	ZAI glm-4.7	Long-form content generation, creativity required
Translation (ko→en)	ec1	Gemini Flash Lite	Non-reasoning, fast and free

Core Principle: Do not use reasoning models for translation. Reasoning models consume tokens for internal thought processes, making non-reasoning models more suitable for simple conversion tasks.

Monitoring and Operations

Health Check Endpoints

# arm1 agent
curl http://arm1:8081/health
# → {"status":"healthy","agent":"blog-agent","scheduler_jobs":2,"uptime_sec":...}

curl http://arm1:8081/status
# → {"scheduler":[{"name":"auto-translate","last_run":...},{"name":"post-generator","last_run":"2026-05-04"}]}

# ec1 Blog API
curl https://blog.example.com/api/health
# → {"status":"healthy","version":"2.0.0"}

Observability Points

Metric	Normal Range	Alert Condition
arm1 uptime	>0	Service Down
scheduler_jobs	2	≠ 2
Translation Sync	ko post count = en post count	Discrepancy occurs
Post Generation	1 post daily	No posts for over 24 hours

Lessons Learned and Operational Tips

1. The Pitfall of Reasoning Models

It’s often not explicitly stated in documentation that max_tokens combines reasoning and content. If you get an empty response, check the finish_reason—if it’s "length", it indicates insufficient token budget.

2. Value of the OpenAI-Compatible Pattern

When switching translation providers from ZAI to Gemini, the code change was just one line for the base URL. Abstracting to an OpenAI-compatible interface from the start dramatically reduces LLM replacement costs.

3. Constraints of Date Prefix Matching

In the YYYY-MM-DD-NNN pattern, if two or more posts share the same date and number, translation matching will break. The PostGenerator must include logic to check the last number for that date and increment it when generating new posts.

4. Benefits of Process Consolidation

Consolidating three independent services into one resulted in:

State Sharing (LLM clients, configurations, API clients initialized only once)
Simplified Deployment (one systemd unit)
Easier Debugging (logs consolidated in one place)

Future Plans

Review the integration of arm1 agent’s LLM with Gemini.
Comment Quality Evaluation Pipeline (monitoring the appropriateness of auto-generated comments).
Automatic Translation Quality Verification (comparing with back-translation).
Expanding inter-agent collaboration through the AgentForge framework.

Blog automation aims not for “complete automation,” but for “minimal human intervention.” A structure where AI generates content, humans review it, and the system alerts operators to anomalies is the key to stable operation.

Maximizing Development Productivity by 17x: Building a Low-Cost AI Agent Loop with DeepSeek V4 and Claude Code

Mon, 04 May 2026 09:01:31 +0900

Maximizing Development Productivity by 17x: Building a Low-Cost AI Agent Loop with DeepSeek V4 and Claude Code

Recently, an interesting project called DeepClaude was introduced on Hacker News. It is a hybrid architecture that combines DeepSeek V4 Pro with Claude Code’s Agent Loop feature to deliver the same performance at a 17 times lower cost compared to existing solutions.

This article will not merely deliver interesting news but will specifically cover how to build a cost-effective AI coding assistant by integrating Claude Code with DeepSeek V4 in a real development environment. In particular, it provides a comprehensive guide, including how to control GitHub and the file system using MCP (Model Context Protocol).

1. Why DeepSeek V4 and Claude Code?

Claude Code provides a powerful ‘Agent Loop’ feature. This is an automated process where the AI writes code, executes it, fixes errors, and repeats until the goal is achieved. However, the cost burden of continuously using the high-quality Sonnet model is significant.

This is where DeepSeek V4 Pro comes in. DeepSeek V4 is one of the most notable models in the open-source community recently, showing excellent performance not only in complex reasoning capabilities but also in code generation. Above all, its cost-effectiveness is overwhelming.

Core Strategy of the DeepClaude Approach:

Planner: Use the existing Claude model for analyzing tasks and establishing a plan (one-time use).
Worker: Use DeepSeek V4 for the actual code writing and modification loop (Run Loop) (high volume use).

Through this structure, it is possible to reduce the total cost to 1/17th while maintaining the task completion rate.

2. Prerequisites: Configuring the MCP Server Environment

To implement this architecture, the AI must be able to read and write files in the local environment. To do this, we will apply the MCP Server concept covered in the previous post for setup.

2.1. Configuring the MCP Settings File (`mcp_config.json`)

Configure the settings so the AI agent can access the project folder. Create a local mcp_config.json file and write the following content.

{
 "mcpServers": {
 "filesystem": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/yourname/Projects/DeepAgent"],
 "env": {
 "ALLOWED_DIRECTORIES": "/Users/yourname/Projects/DeepAgent"
 }
 },
 "github": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-github"]
 }
 }
}

filesystem: Specifies the path where the agent will generate and modify code.
github: (Optional) Token environment variables may be required to create GitHub issues or PRs.

3. Implementing the Integration of DeepSeek V4 and Claude Code

Now, let’s implement a Python script that performs tasks by switching between the two models by writing actual code. This script is the core logic of the ‘Hybrid Agent’.

3.1. Installing Dependencies

pip install openai anthropic

3.2. Implementing the Hybrid Agent Code (`hybrid_agent.py`)

This code uses a mix of the Anthropic API and the OpenAI-compatible API (DeepSeek).

import os
import json
from openai import OpenAI
from anthropic import Anthropic

# Configuration: Manage API keys via environment variables
DEEPSEEK_API_KEY = os.getenv("DEEPSEEK_API_KEY")
ANTHROPIC_API_KEY = os.getenv("ANTHROPIC_API_KEY")

def create_hybrid_agent(task_description: str, max_iterations: int = 5):
 """
 Hybrid agent function combining DeepSeek V4 (Worker) and Claude (Planner)
 """
 
 # 1. Initialize Model Clients
 # DeepSeek V4 is accessed via OpenAI SDK (example)
 worker_client = OpenAI(
 api_key=DEEPSEEK_API_KEY,
 base_url="https://api.deepseek.com/v1" # Verify actual endpoint needed
 )
 planner_client = Anthropic(api_key=ANTHROPIC_API_KEY)

 print(f"[System] Task start: {task_description}")
 
 # 2. Request initial plan from Claude (Planner)
 planning_prompt = f"""
 You are a software architect. Please establish a concrete step-by-step plan to perform the following task.
 Task: {task_description}
 
 Please respond only with a step list in JSON format.
 Example: {{"steps": ["Create file", "Implement logic", "Run test"]}}
 """
 
 try:
 message = planner_client.messages.create(
 model="claude-3-5-sonnet-20241022",
 max_tokens=1024,
 messages=[{"role": "user", "content": planning_prompt}]
 )
 plan_text = message.content[0].text
 print(f"[Planner] Plan established: {plan_text}")
 except Exception as e:
 print(f"[Error] Failed to establish plan: {e}")
 return

 # 3. Execute DeepSeek V4 (Worker) Loop
 current_context = f"Task Goal: {task_description}\nPlan: {plan_text}"
 
 for i in range(max_iterations):
 print(f"\n--- Loop {i+1}/{max_iterations} (Worker: DeepSeek V4) ---")
 
 try:
 response = worker_client.chat.completions.create(
 model="deepseek-chat", # DeepSeek V4 model name
 messages=[
 {"role": "system", "content": "You are a professional developer who writes and modifies code according to the plan."},
 {"role": "user", "content": current_context}
 ],
 temperature=0.3
 )
 
 worker_output = response.choices[0].message.content
 print(f"[Worker] Execution Result:\n{worker_output[:500]}...\n") # Summarize output
 
 # (In actual implementation, call MCP tools here to write files or execute commands)
 # file_system_tool.write_file(path="main.py", content=worker_output)
 
 # Check termination condition (e.g., "TASK_COMPLETE" keyword)
 if "Done" in worker_output or "TASK_COMPLETE" in worker_output:
 print("[System] Task completed successfully.")
 break
 
 # Update context for feedback loop
 current_context += f"\n\nPrevious Attempt Result:\n{worker_output}\n\nPlease continue or fix errors."
 
 except Exception as e:
 print(f"[Error] Error occurred during Worker execution: {e}")
 break

# Execution Example
if __name__ == "__main__":
 create_hybrid_agent(
 task_description="Create a Next.js API handler to generate a /hello endpoint, and include TypeScript type validation."
 )

3.3. Code Explanation

Planner (Claude): Uses the anthropic library to analyze user requirements and define the order of tasks. Since this process occurs only once, using a high-cost model has little impact on the total cost.
Worker (DeepSeek V4): Calls the DeepSeek API via the openai library. It loops max_iterations times to generate code and repeatedly modifies it based on virtual feedback (or actual execution results). This is the part that consumes the most tokens.

4. Troubleshooting and Tips

1. DeepSeek API Compatibility: DeepSeek V4 Pro is currently often provided in a way compatible with the OpenAI SDK, but you may need to configure the Base URL (e.g., https://api.deepseek.com). Please check the official documentation.

2. Context Window: DeepSeek models usually support a long context window of 128k or more. This is very advantageous for analyzing long codebases or maintaining conversation history. Even if the context lengthens as the loop runs, there is little performance degradation.

3. MCP Integration: The Python code above is a simple example. In reality, you must communicate with the server defined in mcp_config.json to access the file system. To do this, you need to implement client logic that communicates with the MCP server via stdio inside hybrid_agent.py to enable full automation.

5. Conclusion: Balancing Cost and Performance

For developers, AI is becoming not just a simple chat window but an ‘Acting Agent’. However, indiscriminately using GPT-4o or Claude Sonnet without regard for cost is not realistic.

The hybrid strategy of placing a high-performance open-source model like DeepSeek V4 as the ‘Worker’ and utilizing a high-cost model as the ‘Planner’ is likely to become the standard pattern for future AI agent development.

Test the code above right now and add 17x efficiency to your development workflow.

Building a Blog AI Auto-Comment System (1/3) — Architecture and Implementation

Sun, 03 May 2026 01:00:00 +0900

Overview

I built a system where AI automatically responds to blog comments. When a reader leaves a comment on a blog post, the AI assistant analyzes the post context and automatically generates a technically accurate yet friendly reply.

This series consists of three parts:

Part 1 (This post): Overall architecture design and core code implementation
Part 2: File-based authentication, permission management, security hardening
Part 3: systemd deployment, nginx proxy, troubleshooting

System Architecture

Overall Data Flow

Reader writes a comment
 ↓
[giscus] → Creates a comment on GitHub Discussions
 ↓
[GitHub Webhook] → Sends HTTP POST
 ↓
[nginx reverse proxy] → Header forwarding
 ↓
[Flask Worker] → Signature verification → Comment analysis
 ↓
[Claude Code CLI] → Generates AI response
 ↓
[GitHub GraphQL API] → Posts reply to Discussion
 ↓
[giscus] → Displays reply on blog

The key point in this architecture is that giscus uses GitHub Discussions as a comment storage. Therefore, we can receive new comment events via GitHub Webhook and post responses using the same GitHub API.

Components

Component	Role	Technology
giscus	Blog comment widget	Based on GitHub Discussions
GitHub Webhook	Event delivery	`discussion_comment` event
nginx	Reverse proxy	Header forwarding, SSL termination
Flask Worker	Webhook receiving and processing	Python, Flask, Flask-Limiter
Claude Code	AI response generation	`--print` mode CLI call
GitHub GraphQL	Response posting	Mutation API

giscus Configuration

To integrate giscus into a Hugo blog, the following configuration is required in hugo.toml:

[params]
 [params.comments]
 enabled = true
 provider = "giscus"
 [params.comments.giscus]
 repo = "yarang/blogs"
 repoId = "YOUR_REPO_ID"
 category = "General"
 categoryId = "YOUR_CATEGORY_ID"
 mapping = "pathname"
 strict = "0"
 reactionsEnabled = "1"
 emitMetadata = "0"
 inputPosition = "bottom"
 lang = "ko"
 theme = "noborder_gray"

mapping = "pathname" maps Discussions based on the post URL path. This creates an independent Discussion for each blog post.

GitHub Webhook Configuration

In the GitHub repository Settings > Webhooks:

Payload URL: https://your-domain/webhook
Content type: application/json
Secret: Secret for HMAC-SHA256 signature (covered in detail in the security post)
Events: Select Discussion comments

The Webhook sends a discussion_comment event to the Flask worker whenever a comment is created.

Flask Worker Implementation

Project Structure

auto-comment-worker/
├── scripts/
│ └── auto-comment-worker.py # Main worker
├── deploy/
│ └── auto-comment-worker.service # systemd service
├── venv/ # Python virtual environment
└── logs/
 └── audit.log # Audit log

Core Dependencies

from flask import Flask, request, jsonify
from flask_limiter import Limiter
from flask_limiter.util import get_remote_address
from marshmallow import Schema, fields, validate, ValidationError

Flask: Provides Webhook endpoints as a lightweight web framework
Flask-Limiter: Prevents abuse with rate limiting (10 times per minute)
marshmallow: Safe data parsing via request schema validation

Webhook Endpoint

@app.route('/webhook', methods=['POST'])
@limiter.limit("10 per minute")
def github_webhook():
 """Receives GitHub Webhook"""
 # 1. Signature verification
 signature = request.headers.get('X-Hub-Signature-256')
 if not verify_webhook_signature(request.data, signature):
 log_audit('SIGNATURE_INVALID', {'ip': request.remote_addr})
 return jsonify({'status': 'unauthorized'}), 401

 # 2. Request schema validation
 schema = WebhookSchema()
 try:
 payload = schema.load(request.json)
 except ValidationError as err:
 return jsonify({'status': 'invalid'}), 400

 # 3. Extract and filter comment information
 comment = payload.get('comment', {})
 discussion = payload.get('discussion', {})
 original_author = comment.get('user', {}).get('login', 'User')

 # Ignore if it's the blog owner's comment
 if _is_blog_owner(original_author):
 return jsonify({'status': 'owner_comment_ignored'}), 200

 # Ignore if AI generated comment (prevent infinite loop)
 if _is_ai_generated_comment(comment.get('body', '')):
 return jsonify({'status': 'ai_comment_ignored'}), 200

 # 4. Generate and post AI response
 discussion_graphql_id = get_discussion_graphql_id(
 repo_owner, repo_name, discussion_number
 )
 context = f"Title: {discussion_title}\n\nContent: {discussion_body}"
 reply = analyze_comment(context, comment_body)
 post_reply_graphql(discussion_graphql_id, comment_body, original_author, reply)

The core flow consists of 4 steps:

Signature verification: Verifies if the request came from GitHub using HMAC-SHA256
Schema validation: Validates payload structure with marshmallow
Filtering: Ignores comments from the blog owner and the AI itself (prevents infinite loops)
Response: Generates AI response with Claude Code and posts via GraphQL API

Preventing Infinite Loops

If AI responds to a comment created by AI, it will fall into an infinite loop. To prevent this, we use marker-based detection:

def _is_ai_generated_comment(body: str) -> bool:
 """Identifies if the comment was generated by AI"""
 ai_markers = [
 '🤖 AI Assistant',
 'AI Assistant',
 'AgentForge',
 'Automatically generated by Claude Code',
 'was automatically generated'
 ]
 body_lower = body.lower()
 return any(marker.lower() in body_lower for marker in ai_markers)

When posting the AI response, you must include one of these markers in the body:

body = f"""---
**🤖 AI Assistant**

{safe_reply}

*This comment was automatically generated by AgentForge + Claude Code.*
---
"""

Calling Claude Code CLI

Use Claude Code’s --print mode to generate an AI response non-interactively:

def analyze_comment(context: str, comment: str) -> str:
 """Run Claude Code with AgentForge settings"""
 prompt = f"""## Blog Post Context
{context[:2000]}

## Reader Comment
{comment}

Please write a response to this comment.
- As a technical blog assistant, be professional yet friendly
- Concise within 200 characters
- Provide additional info or links if needed
"""

 cmd = [
 CLAUDE_CODE_PATH,
 '--settings', AGENTFORGE_CONFIG,
 '--print', prompt
 ]

 result = run(cmd, capture_output=True, text=True, timeout=60)

 if result.returncode == 0 and result.stdout.strip():
 return result.stdout.strip()

 return "Thanks for your opinion! I think it would be great to discuss the technical aspects further. 🙏"

Specify the AgentForge dedicated configuration file with the --settings flag. You can manage the model, token limits, etc. in this configuration file.

The --print flag runs Claude Code in non-interactive mode and outputs the result to stdout. Unlike interactive mode, it terminates after a single prompt-response.

GitHub GraphQL API Integration

Since giscus uses GitHub Discussions, the response must also be posted via the GitHub GraphQL API.

Retrieve Discussion GraphQL ID:

def get_discussion_graphql_id(repo_owner, repo_name, discussion_number):
 query = """
 query($owner: String!, $name: String!, $number: Int!) {
 repository(owner: $owner, name: $name) {
 discussion(number: $number) {
 id
 }
 }
 }
 """
 variables = {
 "owner": repo_owner,
 "name": repo_name,
 "number": discussion_number
 }

 response = requests.post(
 GITHUB_API_URL,
 json={"query": query, "variables": variables},
 headers={
 "Authorization": f"Bearer {GITHUB_TOKEN}",
 "Content-Type": "application/json"
 },
 timeout=10
 )

 if response.status_code == 200:
 data = response.json()
 return data["data"]["repository"]["discussion"]["id"]
 return None

The Webhook payload only includes the Discussion’s REST API ID. However, to post a comment, the GraphQL Node ID is required. Therefore, we first retrieve the Discussion’s Node ID via a GraphQL query, then use it to post the comment.

Post Response (Mutation):

def post_reply_graphql(discussion_graphql_id, original_comment, original_author, reply):
 query = """
 mutation($discussionId: ID!, $body: String!) {
 addDiscussionComment(input: {
 discussionId: $discussionId, body: $body
 }) {
 comment { id, databaseId }
 }
 }
 """
 # ... (Send request)

The addDiscussionComment mutation adds a new comment to the entire Discussion. It is a Discussion-level comment, not a reply to a specific comment.

Input Sanitization

Since user comments are external input, they must be sanitized:

def sanitize_comment(body: str) -> str:
 """User input sanitization"""
 if not body:
 return body
 body = re.sub(r'<[^>]+>', '', body) # Remove HTML tags
 body = html.escape(body) # Escape HTML entities
 body = body[:1000] # Length limit
 return body

To prevent XSS attacks, HTML tags are removed, remaining special characters are escaped, and the length is limited to 1000 characters.

Audit Logging

We keep audit logs to track security events:

def log_audit(event_type: str, details: dict):
 """Record security event audit log"""
 with open(AUDIT_LOG, 'a') as f:
 f.write(json.dumps({
 'timestamp': datetime.utcnow().isoformat(),
 'event': event_type,
 'details': details
 }) + '\n')

Event types recorded:

SIGNATURE_INVALID: Webhook signature verification failed
INVALID_PAYLOAD: Invalid request payload
WEBHOOK_RECEIVED: Webhook received successfully
AI_RESPONSE_SENT: AI response posted successfully

Conclusion

In this Part 1, we covered the overall architecture and core implementation code connecting giscus, GitHub Webhook, Flask worker, Claude Code CLI, and GitHub GraphQL API.

In the upcoming Part 2, we will cover security hardening for this system — file-based authentication management, file permission verification, HMAC-SHA256 signature verification, and more in detail.

This post is Part 1 of the AgentForge blog automatic comment system series.

[MCP] Blog Automation System

Sat, 21 Feb 2026 21:30:00 +0900

Introduction

We built a system where Claude can directly manage blog posts using the Model Context Protocol (MCP). This article explains the implementation and usage.

What is MCP?

MCP (Model Context Protocol) is a protocol developed by Anthropic that enables standardized communication between Claude and external tools/data sources.

flowchart LR
 Claude <-->|MCP| MCPServer[MCP Server]
 MCPServer --> BlogFiles[Blog Files]

Architecture

System Structure

blogs/
├── .claude/
│ ├── mcp_server.py # MCP Server Implementation
│ ├── requirements.txt # Python Dependencies
│ ├── README.md # Documentation
│ └── claude_desktop_config.json
├── content/
│ └── posts/ # Blog Posts
└── static/
 └── images/ # Image Files

MCP Server Structure

class BlogManager:
 """Blog Management Class"""

 def create_post(self, title, content, tags, categories):
 """Create new post"""

 def list_posts(self, limit, offset):
 """List posts"""

 def get_post(self, filename):
 """Get specific post"""

 def update_post(self, filename, **kwargs):
 """Update post"""

 def delete_post(self, filename):
 """Delete post"""

 def search_posts(self, query):
 """Search posts"""

Available Tools

flowchart TB
 subgraph Tools[MCP Tools]
 C1[blog_create_post]
 R1[blog_list_posts]
 R2[blog_get_post]
 R3[blog_search_posts]
 U1[blog_update_post]
 D1[blog_delete_post]
 end

 subgraph CRUD[CRUD Operations]
 Create[Create]
 Read[Read]
 Update[Update]
 Delete[Delete]
 end

 C1 --> Create
 R1 --> Read
 R2 --> Read
 R3 --> Read
 U1 --> Update
 D1 --> Delete

1. blog_create_post

Create a new blog post.

{
 "title": "Post Title",
 "content": "Markdown content...",
 "tags": ["tag1", "tag2"],
 "categories": ["Development"],
 "draft": false
}

2. blog_list_posts

Retrieve post list.

{
 "limit": 20,
 "offset": 0
}

3. blog_get_post

Get details of a specific post.

{
 "filename": "2026-02-21-004-example.md"
}

4. blog_update_post

Update existing post.

{
 "filename": "2026-02-21-004-example.md",
 "content": "Updated content...",
 "draft": false
}

5. blog_search_posts

Search posts by content.

{
 "query": "Docker"
}

Automated File Naming

Post filenames are automatically generated using the following rule:

YYYY-MM-DD-NNN-slug.md

YYYY-MM-DD: Creation date
NNN: Serial number (001, 002, …)
slug: URL-friendly string generated from title

Example: 2026-02-21-004-mcp-blog-automation.md

Usage Scenarios

flowchart LR
 User -->|Natural Language| Claude
 Claude -->|blog_create_post| MCP[MCP Server]
 MCP -->|Create File| Blog[YYYY-MM-DD-NNN-slug.md]

1. Quick Post Writing

User: "Write a short tip post about Python list comprehensions"

Claude: Use blog_create_post tool to create post
→ File created: 2026-02-21-005-python-list-comprehension.md

2. Search and Update Existing Posts

User: "Find Docker-related posts and update with latest version info"

Claude: blog_search_posts("Docker") → Check results → blog_update_post

3. Manage Series Posts

User: "Show me all agent-related posts written so far"

Claude: blog_search_posts("agent") → List related posts

Implementation Considerations

Front Matter Parsing

Parses Hugo’s TOML format front matter:

def _parse_front_matter(self, content: str) -> Dict[str, Any]:
 """Parse TOML front matter"""
 if not content.startswith("+++"):
 return {}

 parts = content.split("+++", 2)
 # ... parsing logic

Concurrency Handling

Prevents filename conflicts by checking existing file count:

existing_count = len(list(self.content_dir.glob("*.md")))
filename = self._generate_filename(title, existing_count + 1)

Extensibility

flowchart TB
 subgraph Current[Current Implementation]
 C1[blog_create_post]
 C2[blog_list_posts]
 C3[blog_get_post]
 C4[blog_update_post]
 C5[blog_delete_post]
 C6[blog_search_posts]
 end

 subgraph Future[Future Extensions]
 F1[blog_upload_image]
 F2[blog_suggest_tags]
 F3[blog_optimize_seo]
 F4[blog_publish]
 end

 Current --> Future

1. Image Processing

blog_upload_image: Image upload and optimization

2. Auto Tag Suggestion

blog_suggest_tags: Content analysis-based tag suggestions

3. SEO Optimization

blog_optimize_seo: Meta description, keyword optimization

4. Deployment Automation

blog_publish: git commit, push, deployment trigger

Conclusion

With the MCP-based blog automation system:

Improved Productivity: Write posts in natural language
Consistency: Automatic file naming rules
Better Accessibility: Intuitive blog management via Claude

This system is continuously extensible, with potential additions like image processing, SEO optimization, and automated deployment.

References

Korean Version: 한국어 버전

Automation on Yarang's Tech Lair

Agentic Workflow: Building a Blog Automation Pipeline with MCP Tools

Agentic Workflow: Building a Blog Automation Pipeline with MCP Tools

Background: Connecting LLMs with Development Tools

MCP (Model Context Protocol) Architecture Design

1. Implementing the MCP Server in the Blog Server (Rust)

2. Communication with Agents: Prompt Engineering

Practical Application: Automated Posting Workflow

Workflow Execution Code (Python Example)

Considerations and Future Plans

Conclusion

AgentForge Blog Automation Service: Full Architecture - From AI Comments to Translation and Post Generation

System Topology

arm1: Unified Blog Agent

Why Unified?

Architecture

Module Operations

1. CommentHandler — AI Comment Response

2. TranslateHandler — Automatic Translation Trigger

3. PostGenerator — Automatic Post Generation

ec1: Blog API Translation System

Transition to Gemini

OpenAI-Compatible Endpoint

Translation Matching Logic

Title-in-Body Translation Technique

LLM Strategy: Role-Based Model Separation

Monitoring and Operations

Health Check Endpoints

Observability Points

Lessons Learned and Operational Tips

1. The Pitfall of Reasoning Models

2. Value of the OpenAI-Compatible Pattern

3. Constraints of Date Prefix Matching

4. Benefits of Process Consolidation

Future Plans

Maximizing Development Productivity by 17x: Building a Low-Cost AI Agent Loop with DeepSeek V4 and Claude Code

Maximizing Development Productivity by 17x: Building a Low-Cost AI Agent Loop with DeepSeek V4 and Claude Code

1. Why DeepSeek V4 and Claude Code?

2. Prerequisites: Configuring the MCP Server Environment

2.1. Configuring the MCP Settings File (mcp_config.json)

3. Implementing the Integration of DeepSeek V4 and Claude Code

3.1. Installing Dependencies

3.2. Implementing the Hybrid Agent Code (hybrid_agent.py)

3.3. Code Explanation

4. Troubleshooting and Tips

5. Conclusion: Balancing Cost and Performance

Building a Blog AI Auto-Comment System (1/3) — Architecture and Implementation

Overview

System Architecture

Overall Data Flow

Components

giscus Configuration

GitHub Webhook Configuration

Flask Worker Implementation

Project Structure

Core Dependencies

Webhook Endpoint

Preventing Infinite Loops

Calling Claude Code CLI

GitHub GraphQL API Integration

Input Sanitization

Audit Logging

Conclusion

[MCP] Blog Automation System

Introduction

What is MCP?

Architecture

System Structure

MCP Server Structure

Available Tools

1. blog_create_post

2. blog_list_posts

3. blog_get_post

4. blog_update_post

5. blog_search_posts

Automated File Naming

Usage Scenarios

1. Quick Post Writing

2. Search and Update Existing Posts

3. Manage Series Posts

2.1. Configuring the MCP Settings File (`mcp_config.json`)

3.2. Implementing the Hybrid Agent Code (`hybrid_agent.py`)