Claude on Yarang's Tech Lair

MCP Server Metadata Synchronization: Context Management Strategies for Developer Productivity

Mon, 22 Jun 2026 09:01:11 +0900

MCP Server Metadata Synchronization: Context Management Strategies for Developer Productivity

As the integration between AI agents and developer tooling deepens, we are automating our blog system through the Model Context Protocol (MCP). However, one nagging issue remains: the ’token waste’ phenomenon where we have to repeatedly explain the project’s structure and context in every session with the AI.

As mentioned in the latest Hacker News post, Stop wasting tokens and re explaining your project between sessions, maintaining project context consistently goes beyond mere convenience; it directly impacts cost-effectiveness.

In this post, we propose a practical design for how to efficiently share dynamic metadata (context) with agents, moving beyond the static resources (Tools, Resources, Prompts) provided by the MCP server.

Problem Definition: The “My Project Introduction” Repetition

Existing MCP clients understand functionality through the tools list provided by the server. For instance, if there’s a write_post tool, Claude will call it to write a post. However, Claude doesn’t know the context, such as “What is the writing style of this blog?” or “What are the latest trends?”

Ultimately, the user has to provide prompts like this every time:

“Write a blog post. The style should be technical and specific, and it should refer to the latest Hacker News trends.”

This leads to unnecessary token consumption. To solve this, we can consider integrating the project’s ‘architecture design document’ or ‘development guidelines’ as resources within the MCP server.

Solution: Resource-Based Metadata Provision

In the MCP specification, Resources are data snippets provided by the server. We can utilize these not just for simple file lookups, but as a ‘project state machine’.

1. Automating Architecture Documentation

Documents like the previously written [ZeroClaw] Codebase Architecture Analysis or [Multi-Agent] File-Based Architecture Design might exist as static files or be scattered across platforms like Confluence. We can make it so that the MCP server loads these into memory upon startup or generates them dynamically for provision.

2. Rust Implementation Example

Let’s write code to add a architecture_guide resource to an MCP server written in Rust (e.g., blog-api-server).

use jsonrpc_core::{Result, Params};
use std::collections::HashMap;
use serde_json::Value;

// A hypothetical MCP handler struct
pub struct BlogMcpServer {
 // Cached metadata
 cached_context: String,
}

impl BlogMcpServer {
 pub fn new() -> Self {
 // Load core context (architecture, rules) during server initialization
 let context = r#"
 Project: ZeroClaw Multi-Agent Runtime
 Architecture: Asynchronous multi-agent system using a file-based event bus.
 Key Rules:
 1. All agents run in independent threads.
 2. Communication follows the JSON-RPC over MCP protocol.
 3. Logs must be output in structured JSON format.
 "#;
 
 Self { cached_context: context.to_string() }
 }

 // MCP resource read handler (resources/read)
 pub fn handle_read_resource(&self, params: Params) -> Result<Value> {
 let params_obj: HashMap<String, Value> = params.parse()?;
 let uri = params_obj.get("uri").and_then(|v| v.as_str()).unwrap_or("");

 match uri {
 "context://architecture/guide" => {
 // Return cached context when requested by the client
 Ok(json!({
 "contents": [
 {
 "uri": uri,
 "mimeType": "text/plain",
 "text": self.cached_context.clone()
 }
 ]
 }))
 },
 "context://trends/latest" => {
 // Fetch and provide external RSS (Hacker News, etc.) in real-time (dynamic resource)
 let trends = fetch_latest_hn_trends().await.unwrap_or_default();
 Ok(json!({
 "contents": [{
 "uri": uri,
 "mimeType": "application/json",
 "text": trends
 }]
 }))
 },
 _ => Err(Error::invalid_params("Unknown resource URI"))
 }
 }
}

async fn fetch_latest_hn_trends() -> Option<String> {
 // In reality, you would use reqwest etc. to parse RSS
 // Returning a simple JSON string for demonstration
 Some(r#"[{"title": "JSON-LD Explained", "link": "..."}]"#.to_string())
}

This code allows the MCP client to instantly retrieve the predefined project architecture rules by requesting the resource with the URI context://architecture/guide.

3. Automatic Prompt Injection

To prevent clients (like Claude) from requiring complex configurations, we can leverage the MCP server’s Prompts functionality to provide templates that automatically complete system prompts.

The MCP server can expose prompt templates like this:

Prompt Name: generate_blog_post Arguments: topic, tone

{
 "name": "generate_blog_post",
 "description": "Creates a technical blog post based on architecture context and latest trends.",
 "arguments": [
 { "name": "topic", "description": "Main topic", "required": true },
 { "name": "tone", "description": "Writing style", "required": false }
 ]
}

The actual implementation logic (in Rust) would work as follows:

pub fn handle_get_prompt(&self, params: Params) -> Result<Value> {
 let name = params.get("name").and_then(|v| v.as_str()).unwrap_or("");
 let args = params.get("arguments").and_then(|v| v.as_object()).unwrap_or(&json!(null));

 if name == "generate_blog_post" {
 let topic = args.get("topic").unwrap_or(&json!("general"));
 
 // Inject the architecture guide fetched from resources into the prompt
 let system_instruction = format!(
 "You are writing for a blog defined by the following architecture:\n{}\n\nPlease write a post about: {}",
 self.cached_context, // Architecture information loaded earlier
 topic
 );

 Ok(json!({
 "messages": [
 {
 "role": "user",
 "content": {
 "type": "text",
 "text": system_instruction
 }
 }
 ]
 }))
 } else {
 Err(Error::invalid_params("Unknown prompt"))
 }
}

Effects and Expected Outcomes

The core of this approach is ‘duplication’. Similar to the Hacker News article Prefer duplication over the wrong abstraction, we avoid complex abstractions to simplify the essence of the project. Instead, we copy (duplicate) the necessary information (context) to where it’s needed (prompt).

Maintain Consistency: When documents are updated, simply restarting the MCP server or refreshing resources will ensure all sessions reflect the latest information.
Token Savings: Users no longer need to repeatedly explain, “My project is a multi-agent system built with Rust…”
Automation-Friendly: If documents are automatically generated and registered as MCP resources within a CI/CD pipeline, AI can always generate or review code based on the latest documentation.

Conclusion

We must utilize documents like the [ZeroClaw] Multi-Agent Architecture Design not just as ‘reading material,’ but as executable AI brains (context). Adding this metadata synchronization layer to the MCP server is the first step towards building complex LLM applications, and it lays the foundation for developers to focus on essential logic without wasting tokens.

In the next post, we will discuss how this metadata is actually utilized in the communication architecture of team agents like Claude Code.

I Sent the Same Coding Task to 4 AIs Simultaneously

Fri, 08 May 2026 21:55:39 +0900

What happens when the same bug-fixing task is sent to Claude, ZAI (GLM), OpenAI Codex, and Google Gemini simultaneously?

This question sparked the AgentForge project. We built a system that connects multiple LLM CLIs with the NATS JetStream message queue to process the same tasks in parallel, and in the process, we made some unexpected discoveries. This article focuses on the comparative experimental findings during the setup phase.

The system’s design and implementation will be covered in Part 2.

List of AIs Tested

The final configuration of 18 operational workers is as follows:

Family	Model	Notes
Claude Code	claude-sonnet-4-6	Main development worker
Claude Code	claude-sonnet-4-5	Previous generation comparison
Claude Code	claude-haiku-4-5	Lightweight & High-speed
Claude Code	claude-opus-4-6	Top-tier
Claude Code	claude-opus-4-5	Previous generation comparison
ZAI (GLM)	glm-5.1	High-tier
ZAI (GLM)	glm-4.7	Mid-tier
ZAI (GLM)	glm-4.5-air	Lightweight tier
OpenAI Codex	gpt-5.5
Codex	gpt-5.4	1M context
Codex	gpt-5.4-mini	400K context
Codex	gpt-5.3-codex	272K context
Google Gemini	gemini-2.5-flash
Gemini	gemini-2.5-pro	High-tier
Gemini	gemini-2.5-flash-lite	Lightweight

The list was much shorter when we first started. It grew as we experimented with which models were available.

Discovery 1: Claude 3.x Series is Already Inaccessible

Those who have used Claude Code for a long time might recall Claude 3.7 Sonnet, 3.5 Sonnet, and 3.5 Haiku. We attempted to add these models as workers.

claude --model claude-3-7-sonnet-20250219 --print "hello"
# → "may not exist or no access"

All three models returned the same error. The Claude 3 series reached its EOL in early 2026, and access via the Claude Code CLI has been blocked. Currently, only the 4.x series is available with a Claude Code subscription.

Conclusion: Claude workers were configured using only the 4.5/4.6 series.

Discovery 2: Limited Model Selection for ChatGPT Account Codex

The OpenAI Codex CLI authenticates with a ChatGPT Plus/Pro account or a separate API key. If authenticated via a ChatGPT account, the accessible models are limited.

codex --model gpt-5.5-pro "fix the bug"
# → "Model gpt-5.5-pro is not supported with ChatGPT account"

codex --model gpt-5.5 "fix the bug"
# → Works normally

Models available with a ChatGPT account:

Model	Context	Inference Level
gpt-5.5	1M / 1M	High
gpt-5.4	1M / 1M	Medium
gpt-5.4-mini	400K / 400K	Medium
gpt-5.3-codex	272K / 400K	Medium

All other models, including gpt-5.5-pro, returned a “not supported with ChatGPT account” error. More models are available with an API key, but that’s a different approach.

Discovery 3: Gemini CLI Only Supports 2.5 Series

We tested various models with the Gemini CLI (gemini binary).

gemini -p "hello" -m gemini-2.0-flash
# → ModelNotFoundError: models/gemini-2.0-flash is not found

gemini -p "hello" -m gemini-1.5-pro
# → ModelNotFoundError

gemini -p "hello" -m gemini-2.5-flash
# → Works normally

Gemini models accessible with the current account:

gemini-2.5-flash — Default recommended model
gemini-2.5-pro — High-tier
gemini-2.5-flash-lite — Lightweight

Versions of Gemini 2.0 and below return ModelNotFoundError. While this might vary based on account plan or API key type, based on the Gemini CLI, only the 2.5 series worked reliably.

Discovery 4: ZAI Can Be Bypassed with Claude SDK

ZAI is a service that provides an endpoint compatible with the Anthropic API. This allows us to use GLM models with the Claude Code CLI by changing just two environment variables.

ANTHROPIC_BASE_URL=https://<ZAI endpoint> \
ANTHROPIC_AUTH_TOKEN=<ZAI_KEY> \
claude --model glm-5.1 --print "fix the bug"

Since Claude Code internally uses the Anthropic Python SDK, simply overriding ANTHROPIC_BASE_URL allows calling ZAI’s GLM models with the same format. It was interesting that we could reuse the existing claude backend without any separate adapter code.

The three GLM models used were:

glm-5.1 — High-tier
glm-4.7 — Cost-performance balance
glm-4.5-air — Lightweight & High-speed

4-Way Fan-out Comparison Test

We simultaneously issued the same Go bug-fixing task to 4 representative workers out of the 18 (Claude Sonnet, GLM-5.1, Codex gpt-5.5, Gemini 2.5 Flash).

Task: "fix the off-by-one error in the binary search function"

Response times (wall clock):

Worker	Model	Response Time
cc-go-dev-01	claude-sonnet-4-6	~8 seconds
cc-zai-high-dev-01	glm-5.1	~12 seconds
codex-py-dev-01	gpt-5.5	~15 seconds
gemini-py-dev-01	gemini-2.5-flash	~10 seconds

More interesting than the response times were the differences in their approaches. Claude tended to refactor the entire function, while Gemini preferred minimal modifications. Codex often included test code along with the fix.

Of course, this is a single task result and has no statistical significance. It was a verification at the “does it actually work” level, not a benchmark.

Distributed Workers: Adding a Second Host

If all workers are on the same server, the comparative experiment loses some of its meaning. Therefore, we added Claude workers to a second host.

The method for workers to access the NATS broker (on the first host) from the second host is via an autossh tunnel.

[Service]
ExecStart=autossh -N -L 4222:127.0.0.1:4222 broker-host

By forwarding the local port 4222 to the broker, workers can connect to nats://127.0.0.1:4222 from any host without code changes.

Advantage of this method: Workers don’t need to know where the broker is. They can always connect to localhost:4222.

Most Panicked Moment During Operation

The most distressing situation was losing the NATS operator signing key. NATS JetStream uses NKey-based authentication, and the operator/account’s signing key (nsc seed) is required to issue credentials for new workers.

nsc add user --account Services --name new-worker
# → "signing key not found"

There was no backup. Ultimately, we had to perform a large-scale cutover, regenerating the entire NATS operator and replacing all worker credentials with a new permission tree. Service downtime was approximately 60 seconds.

Lesson: Always create an offline backup of the NATS operator seed immediately after generation. If it’s lost, regeneration is the only option.

Summary

Practical conclusions from this experiment:

Claude 3.x is EOL - Inaccessible via Claude Code CLI as of 2026. Use only 4.x.
Codex ChatGPT Account Limited to 4 Models - gpt-5.5, 5.4, 5.4-mini, 5.3-codex. Pro models require a separate API key.
Gemini Only 2.5 Series - Previous versions inaccessible via CLI.
ZAI Integrable via Claude SDK Environment Variable Override - No separate adapter needed.
NATS NKey Must Be Backed Up - Losing the signing key means reissuing everything.

The next installment will cover how these workers are connected, discussing system design and implementation.

Getting Started with MCP Servers: Creating Your First Tool Integrated with Claude Code

Sun, 03 May 2026 10:47:00 +0900


# Getting Started with MCP Servers: Creating Your First Tool Integrated with Claude Code

MCP (Model Context Protocol) is a powerful protocol that can be integrated with Claude Code and other AI tools. This guide will walk you through the process of creating your first MCP server step-by-step.

## What is MCP?

MCP is a standard protocol that allows AI agents to access external tools and resources. Key features:

- **Standardized Interface**: Integrate various tools in a unified manner
- **Resource Sharing**: Safely access resources such as files and databases
- **Extensibility**: Easily add new tools

## Basic MCP Server Structure

```typescript
// mcp-server-template.ts
import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';

const server = new Server(
 {
 name: 'my-mcp-server',
 version: '1.0.0'
 },
 {
 capabilities: {
 tools: {},
 resources: {}
 }
 }
);

// Example of tool registration
server.setRequestHandler(ListToolsRequestSchema, async () => ({
 tools: [
 {
 name: 'my_tool',
 description: 'Description of my tool',
 inputSchema: {
 type: 'object',
 properties: {
 param1: {
 type: 'string',
 description: 'Parameter description'
 }
 },
 required: ['param1']
 }
 }
 ]
}));

// Start server
const transport = new StdioServerTransport();
await server.connect(transport);

Practical Example: Simple Calculator MCP Server

// calculator-mcp-server.ts
import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { CallToolRequestSchema, ListToolsRequestSchema } from '@modelcontextprotocol/sdk/types.js';

const server = new Server(
 { name: 'calculator-server', version: '1.0.0' },
 { capabilities: { tools: {} } }
);

server.setRequestHandler(ListToolsRequestSchema, async () => ({
 tools: [
 {
 name: 'calculate',
 description: 'Perform basic mathematical operations',
 inputSchema: {
 type: 'object',
 properties: {
 expression: {
 type: 'string',
 description: 'Expression to calculate (e.g., "2 + 2")'
 }
 },
 required: ['expression']
 }
 }
 ]
}));

server.setRequestHandler(CallToolRequestSchema, async (request) => {
 if (request.params.name === 'calculate') {
 const expression = request.params.arguments?.expression as string;
 try {
 // Use Function instead of eval for safer calculation
 const result = Function(`"use strict"; return (${expression})`)();
 return {
 content: [{
 type: 'text',
 text: `Result: ${result}`
 }]
 };
 } catch (error) {
 return {
 content: [{
 type: 'text',
 text: `Calculation error: ${error}`
 }],
 isError: true
 };
 }
 }
 return { content: [] };
});

Claude Code Configuration

To register an MCP server with Claude Code, modify ~/.config/claude/settings.json:

{
 "mcpServers": {
 "calculator": {
 "command": "node",
 "args": ["/path/to/calculator-mcp-server.js"]
 }
 }
}

Providing Resources

// Provide resource list
server.setRequestHandler(ListResourcesRequestSchema, async () => ({
 resources: [
 {
 uri: 'calc://history',
 name: 'Calculation History',
 description: 'Recent calculation history',
 mimeType: 'application/json'
 }
 ]
}));

// Provide resource content
server.setRequestHandler(ReadResourceRequestSchema, async (request) => {
 if (request.params.uri === 'calc://history') {
 return {
 contents: [{
 uri: request.params.uri,
 mimeType: 'application/json',
 text: JSON.stringify({ history: [] })
 }]
 };
 }
 throw new Error('Resource not found');
});

Security Considerations

Input Validation: Validate and restrict all user input
Access Control: Apply the principle of least privilege
Error Handling: Ensure sensitive information is not exposed in error messages
Rate Limiting: Implement rate limiting to prevent excessive requests

Deployment and Testing

# Build server
npm run build

# Local test
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | node dist/server.js

# Test after integrating with Claude Code
# Use tool in Claude Code after reloading config file

Next Steps

Add more complex tools and resources
Implement prompt templates
Improve error handling
Add logging and monitoring

Developing MCP servers is a great way to extend Claude Code’s functionality and enhance automation. Start with small projects and gradually expand your features.

References

Multi-Model AI Agent Team Design: Composed Architecture and 5-Team Hierarchy

Mon, 30 Mar 2026 00:33:34 +0900

Overview

For building a blog system, I designed a multi-model agent team consisting of 14 AI specialists, 5 teams, and 4 LLM models. The core innovations are two:

Composed Agent: Separating role definitions from execution profiles for maximum reusability
Hierarchical Bridge Leadership: Dual membership of tech leads between upper and lower teams to resolve communication bottlenecks

This post covers the final structure, model distribution strategy, and the composed architecture design process.

Background: Why Multi-Model?

Using a single LLM for all tasks creates two problems:

Cost: Running 14 specialists on a Claude Opus-level model makes costs uncontrollable
Fit: Design needs fast reasoning, security analysis needs deep logic, implementation needs stable coding

So we distributed models based on task characteristics.

Final Team Structure

5 teams, 14 specialists, 4 models.

graph TD
 subgraph UPPER["Upper — Steering Team · consensus"]
 ORC["Orchestrator
relay:steering-orchestrator"]
 DES["Architect
gemini:gemini-2.5-flash"]
 SEC["Security Reviewer
codex:gpt-4o"]
 STL["Backend Tech Lead
relay:developer-zai"]
 FTL["Frontend Tech Lead
relay:developer-zai"]
 DTL["Desktop Tech Lead
relay:developer-zai"]
 INF["Infra Network
gemini:gemini-2.5-flash"]
 SAD["Server Admin
relay:developer-zai"]
 end

 subgraph LOWER_BE["Backend Team · leader_decides"]
 BTL["Backend Tech Lead"]
 BDEV["Backend Developer"]
 end

 subgraph LOWER_FE["Frontend Team · leader_decides"]
 FTL2["Frontend Tech Lead"]
 FDEV["Frontend Developer"]
 FUX["UX Designer"]
 end

 subgraph LOWER_DT["Desktop Team · leader_decides"]
 DTL2["Desktop Tech Lead"]
 DDEV["Desktop Developer"]
 DUX["UX Designer"]
 end

 subgraph LOWER_INFRA["Infra Team · leader_decides"]
 SAD2["Server Admin (Leader)"]
 INET["Cloud Network"]
 DBA["DB Architect"]
 end

 UPPER -.->|bridge| LOWER_BE
 UPPER -.->|bridge| LOWER_FE
 UPPER -.->|bridge| LOWER_DT
 UPPER -.->|bridge| LOWER_INFRA

 BTL --> BDEV
 FTL2 --> FDEV
 FTL2 --> FUX
 DTL2 --> DDEV
 DTL2 --> DUX
 SAD2 --> INET
 SAD2 --> DBA

Team Details

Team	Type	Decision-Making	Leader	Members
Steering Team	upper	consensus	Orchestrator	8 (including bridges)
Backend Team	lower	leader_decides	Backend Tech Lead	2
Frontend Team	lower	leader_decides	Frontend Tech Lead	3
Desktop Team	lower	leader_decides	Desktop Tech Lead	3
Infra Team	lower	leader_decides	Server Admin	3

The Infra Team Separation Decision

In the initial design, DB Architect and Server Admin were part of the backend team. But we separated them based on workspace.

graph LR
 subgraph BackendTeam["Backend Team"]
 B["API Code Writing
FastAPI, Python
workspace: VS Code / SSH"]
 end

 subgraph InfraTeam["Infra Team"]
 S["Server Management
Docker, Ubuntu, Nginx
workspace: SSH Terminal"]
 N["Cloud Network
Cloudflare Dashboard
workspace: Web Console"]
 D["DB Management
PostgreSQL, Migrations
workspace: psql / SSH"]
 end

 B -.->|API deployment| S
 B -.->|Query optimization| D

When workspaces differ, separation is more natural than keeping them together.

Model Distribution Strategy

pie title Specialists by Model
 "relay:developer-zai (GLM)" : 10
 "gemini:gemini-2.5-flash" : 2
 "codex:gpt-4o" : 1
 "zai:glm-4" : 1

Model	Specialists	Purpose	Why Chosen
relay:developer-zai	10	Implementation, ops, leads	Cost-effective, stable coding
gemini:gemini-2.5-flash	2	Design, infra network	Fast response, easy external API calls
codex:gpt-4o	1	Security review	High reasoning, OWASP knowledge
zai:glm-4	1	Context compression	Free tier, text summarization specialized

By assigning 10 implementation specialists to GLM, we achieved 60-70% total cost reduction.

Composed Agent Architecture

The core innovation is separating role definitions (Expert) from execution profiles (Definition).

With the traditional approach, role and execution logic are coupled — any change requires a full rewrite, and reuse is impossible.

Composed Approach

graph TD
 DEF["Definition
Backend Developer"]
 DEF --> BASE["Base: backend-core"]
 DEF --> CAP["Capabilities:
rest-api, crud, auth-jwt"]
 DEF --> PLAT["Platform: fastapi"]
 DEF --> POL["Policy: blog-default"]

 BASE --> |"compose"| RUN["Runtime Agent"]
 CAP --> |"compose"| RUN
 PLAT --> |"compose"| RUN
 POL --> |"compose"| RUN

Module Structure

agent-library/
├── definitions/ ← 14 agent definitions
├── modules/
│ ├── base/ ← 6 base modules
│ ├── capabilities/ ← 15 capability modules
│ ├── platforms/ ← 5 platform modules
│ └── policies/ ← 1 policy
└── runs/ ← execution history

Advantages

Reusability: rest-api capability module shared by backend developer and backend tech lead
Platform swap: Change platform: fastapi to platform: django for instant switching
Capability extension: Add a new capability module and connect it to the Definition
Policy unification: All agents follow the same blog-default policy

Expert-Definition Mapping

Expert	Definition	Base	Capabilities	Platform
Backend Developer	backend-developer	backend-core	rest-api, crud, auth-jwt	fastapi
Backend Tech Lead	backend-tech-lead	backend-core	rest-api, crud, code-review	fastapi
Frontend Developer	frontend-developer	frontend-core	markdown-renderer, list-filter-sort	nextjs
Server Admin	server-administrator	server-core	docker-management, nginx-config, postgres-admin	ubuntu
Infra Network	infra-network-admin	infra-core	dns-management, ssl-certificates, rate-limiting	cloudflare
Security Reviewer	security-auditor	specialist-core	security-audit	fastapi
Context Compressor	context-compressor	specialist-core	context-compression	markdown

TLS Certificate Strategy: Cloudflare Origin CA

For production TLS certificates, we chose Cloudflare Origin CA over Let’s Encrypt.

sequenceDiagram
 participant Client as Visitor
 participant CF as Cloudflare (Proxy)
 participant Nginx as Nginx (Origin)
 participant API as FastAPI

 Client->>CF: HTTPS request
 CF->>CF: Terminate with Cloudflare-managed cert
 CF->>Nginx: Encrypt with Origin CA cert
 Nginx->>API: HTTP (local)
 API-->>Nginx: Response
 Nginx-->>CF: Encrypted with Origin CA
 CF-->>Client: Response

Item	Let’s Encrypt	Cloudflare Origin CA
Validity	90 days (renewal required)	15 years (no renewal)
Issuance	ACME automation required	Manual from Dashboard
Complexity	certbot setup	Copy cert files only

Production architecture:

Oracle Cloud ARM (4 OCPU, 24GB)
├── PostgreSQL (installed directly on host)
├── Docker Compose
│ ├── blog-api (FastAPI)
│ ├── blog-frontend (Next.js standalone)
│ ├── MinIO (S3-compatible storage)
│ └── Nginx (Cloudflare Origin CA)
└── Cloudflare Proxy (Full Strict SSL)

Relay Plugin: Agent Invocation Mechanism

The team structure runs in Claude Code through the Relay plugin.

sequenceDiagram
 participant User as User
 participant Claude as Claude Code
 participant Plugin as Relay Plugin
 participant MCP as MCP Server
 participant LLM as External LLM

 User->>Claude: /relay:invoke-agent
 Claude->>Plugin: Load definition by expert slug
 Plugin->>Plugin: Compose Definition (base + capabilities + platform + policy)
 Plugin->>Plugin: Check backed_by

 alt relay:developer-zai
 Plugin->>Claude: Run internal agent
 else gemini:*
 Plugin->>MCP: Call gemini_mcp server
 MCP->>LLM: Gemini API
 LLM-->>MCP: Response
 MCP-->>Plugin: Result
 else codex:*
 Plugin->>MCP: Call codex_mcp server
 MCP->>LLM: OpenAI API
 LLM-->>MCP: Response
 MCP-->>Plugin: Result
 end

 Plugin-->>Claude: Final result
 Claude-->>User: Response

backed_by Namespaces

Namespace	MCP Server	Purpose
`relay:developer-zai`	internal agent	Implementation, ops (low cost)
`relay:steering-orchestrator`	internal agent	Coordination, final decisions
`gemini:gemini-2.5-flash`	gemini_mcp	Design, external APIs
`codex:gpt-4o`	codex_mcp	Security analysis
`zai:glm-4`	zai_mcp	Context compression

Design Decision Log

Decision	Alternative	Rationale
Separate infra team	Include in backend	Different workspaces (SSH vs IDE)
Cloudflare Origin CA	Let’s Encrypt	15-year validity, no renewal
PostgreSQL on host	Docker container	Memory efficiency on single server
Composed agent	Single-definition agent	Module reusability, easy platform swap
Assign many GLM	Assign many Claude	60-70% cost reduction

Retrospective: What I Learned

1. “Executable Structure” over “Perfect Structure”

Trying to design everything perfectly can prevent you from ever starting. It’s better to compromise and improve as you execute.

2. Workspace Defines Team Boundaries

People who write code and people who manage servers have different physical work environments — that’s a natural team boundary.

3. The Value of Composed Architecture

In an environment with 14 specialists, 5 teams, and 4 models interacting, module separation is essential. It minimizes the scope of changes and maximizes reusability.

4. Cost is Determined at Design Time

Asking “does this task really need a high-cost model?” every time naturally optimizes costs.

Next Steps

Start Phase 1 implementation: DB, Auth, Post/Category CRUD, Docker
Share team operation experience: Problems encountered during actual execution
Performance monitoring: Response time per model, cost vs quality analysis

This post summarizes my experience building an AI agent team using Claude Code + Relay plugin. It reflects learnings from applying this to a real project — different approaches may be more suitable depending on your situation.

Boosting Server Management Efficiency: Introducing Server Status Checker Skill

Mon, 09 Mar 2026 00:30:00 +0900

Boosting Server Management Efficiency: Introducing Server Status Checker Skill

Are you managing an increasing number of servers?

Individually connecting via SSH to check the status of each server is a waste of time. If you could grasp the CPU, memory, and disk usage of all servers at a glance, your work efficiency would improve significantly.

I faced this problem too, so I built a solution.

The Problem: Repetitive Server Monitoring Tasks

If you’re a DevOps engineer or system administrator, you’ve likely faced this situation:

Repeated SSH connections to each server
Manually running commands like top, htop, df
Manually recording status in Excel or Notion
Modifying management scripts as servers increase

This process wastes time and is repetitive work that can lead to mistakes.

The Solution: Server Status Checker Skill

Server Status Checker is a skill for Claude Code that checks the status of all servers in parallel based on your SSH config file.

Key Features

Feature	Description
Automatic SSH Config Parsing	Automatically discovers server list from `~/.ssh/config`
Real-time Status Check	Collects CPU, Memory, Disk, Uptime, Load information
Parallel Connections	Fast status checking with asyncssh (in seconds)
Group Classification	Automatically categorizes by GCP, OCI, GitHub, Blog, Local, etc.
Online/Offline Status	Intuitive status display with ✓ / ✗

Usage

# Check all server status
/server-status-checker

# Check specific server only
/server-status-checker --server mini01

# Output in JSON format
/server-status-checker --json

# Verbose error messages
/server-status-checker --verbose

Output Example

=== Server Status Report ===

[GCP Servers]
✗ gcp-ajou-ec1 - Offline (Authentication failed)
✗ gcp-fcoinfup-ec1 - Offline (Authentication failed)

[OCI Ajou]
✓ oci-ajou-ec1 - Online
 CPU: 15.2% | Memory: 62.3% | Disk: 45.8%
 Uptime: 15 days | Load: 1.23 1.45 1.38
 OS: Ubuntu 22.04 LTS

[Local Servers]
✓ mini01 - Online
 CPU: 6.7% | Memory: 45.2% | Disk: 5.0%
 Uptime: 2 days | Load: 2.17 2.11 1.94
 OS: macOS 26.3.1

Technical Details

SSH Config Parsing

Parses ~/.ssh/config file to automatically extract:

Host (hostname)
HostName (IP address or domain)
User (username)
Port (port number)
IdentityFile (SSH key path)

Asynchronous Parallel Processing

Uses Python’s asyncssh library to connect to all servers simultaneously:

async def check_server(host: str):
 # SSH connection and command execution
 result = await asyncssh.connect(...)
 return status

Checking 30 servers sequentially takes 5 minutes, but parallel processing completes in under 30 seconds.

Automatic Group Classification

Automatically classifies based on server name patterns:

Group	Pattern	Examples
GCP	`gcp-` prefix	gcp-ajou-ec1, gcp-fcoinfup-ec1
OCI Ajou	`oci-ajou-` prefix	oci-ajou-ec1
OCI Fcoinfup	`oci-fcoinfup-` prefix	oci-fcoinfup-ec1
GitHub	`github-as-` prefix	github-as-actions
Blog	`blog`	blog
Local	`mini`, `mac`	mini01, macbook-pro

System Metrics Collection

Collects the following information from each server:

Linux:

CPU: /proc/stat or psutil.cpu_percent()
Memory: /proc/meminfo or psutil.virtual_memory()
Disk: psutil.disk_usage()
Uptime: /proc/uptime or psutil.boot_time()
Load: /proc/loadavg or os.getloadavg()

macOS:

CPU: psutil.cpu_percent()
Memory: psutil.virtual_memory()
Disk: psutil.disk_usage()
Uptime: psutil.boot_time()
Load: os.getloadavg()

GitHub Release

This skill is released as open source.

🔗 GitHub: https://github.com/yarang/skill-server-status-checker

Installation

git clone https://github.com/yarang/skill-server-status-checker.git
cp -r skill-server-status-checker ~/.claude/skills/server-status-checker

Business Value

Aspect	Improvement
Time Savings	90% reduction in server check time (5 min → 30 sec)
Real-time Monitoring	Immediate server status awareness
Centralized Management	Manage all servers with single SSH config file
Automation	Minimize human errors by eliminating repetitive tasks

Use Cases

1. Daily Server Health Check

Every morning, check all server status with a single /server-status-checker command.

2. Incident Response

When an incident occurs, immediately identify offline servers and take action.

3. Capacity Planning

Monitor disk usage trends to plan capacity expansion in advance.

4. Performance Monitoring

Track CPU and memory usage to identify bottlenecks.

Conclusion

Server Status Checker is more than a simple server status checking tool. It’s a productivity tool that helps DevOps engineers and system administrators focus on core tasks by eliminating repetitive work.

By leveraging the standardized SSH config file and providing fast results through parallel processing, you no longer need to connect to each server individually. Check the health status of all servers with a single command.

Through AI and automation, let’s improve system management efficiency and focus on more important problems.

Related Projects:

domain-checker - Domain availability checker tool

Tags: #DevOps #ServerMonitoring #OpenSource #Claude #AI #Productivity #SSH

Korean Version: 한국어 버전

Boosting Developer Productivity: Introducing Domain Checker Skill

Mon, 09 Mar 2026 00:20:00 +0900

Boosting Developer Productivity: Introducing Domain Checker Skill

What’s the first thing you consider when starting a new project? The “domain name,” of course.

What if your most desired name is already taken in .com or .ai? Have you visited whois sites one by one each time?

I did too. So I built a solution.

The Problem: Repetitive Domain Search Tasks

If you’re a startup founder or developer, you’ve likely faced this situation:

Desired domain is already registered
Visit 10 different whois sites
Manually create comparison table in Excel
Brainstorm alternative domain names

This process wastes time and drains creativity through repetitive work.

The Solution: Domain Checker Skill

Domain Checker is a skill for Claude Code that checks domain availability in real-time and compares costs.

Key Features

Feature	Description
Fast Parallel Lookup	Check 8 major TLDs simultaneously
3-Stage Fallback	RDAP → whois → DNS (ensures reliability)
Automatic Alternative Suggestion	Auto-discovers alternatives when all desired domains are taken
Cost Comparison Table	Shows annual cost and minimum contract period by TLD
Markdown Report	Automatically generates detailed result reports

Usage

# Basic lookup
/domain-checker myapp

# Result example
🔍 Domain Search: myapp*
 🔴 myapp.com (~$13/year)
 🔴 myapp.ai (~$75/year)
 🟢 myapp.io (~$38/year) ← Available!

Target TLDs

TLD	Annual Cost	Min Contract	Characteristics
.com	~$13	1 year	General, highest recognition
.ai	~$75	2 years	AI project specialized
.io	~$38	1 year	Tech startup preferred
.net	~$14	1 year	.com alternative
.co	~$28	1 year	Startup popular
.dev	~$13	1 year	Developer targeted
.tech	~$12	1 year	Tech-related, low cost
.app	~$14	1 year	App service specialized

Technical Details

3-Stage Fallback Mechanism

1. RDAP API → Most accurate, fast
2. whois CLI → Fallback when RDAP fails
3. DNS NS lookup → Last resort

Alternative Domain Suggestion

When all major domains are registered, automatically discovers alternatives:

Search Patterns:

Prefixes: get, try, use, go, my, the
Suffixes: hq, app, hub, lab, pro

Example: myapp → getmyapp.ai, myapp-hq.io, trymyapp.com

Asynchronous Parallel Processing

Uses Python async programming to check 8 TLDs simultaneously, delivering results within 2 seconds.

Real Usage Example

/domain-checker ai

Result:

# 🌐 Domain Search Report: `ai`

## Summary
| Item | Result |
|------|--------|
| Search Domain | `ai` |
| TLDs Checked | 8 |
| 🟢 Available | **0** |
| 🔴 Already Registered | 8 |

## 💡 Alternative Domain Name Suggestions
Domains available among variations of `ai`.

| Domain | Annual Cost | Notes |
|--------|-------------|-------|
| `ai-hq.ai` | ~$75/year | AI specialized (min 2-year contract) |
| `ai-hq.io` | ~$38/year | Tech startup preferred |

GitHub Release

This skill is released as open source.

🔗 GitHub: https://github.com/yarang/skill-domain-checker

Installation

git clone https://github.com/yarang/skill-domain-checker.git
cp -r skill-domain-checker ~/.claude/skills/domain-checker

Business Value

Aspect	Improvement
Time Savings	90% reduction in domain search time (10 min → under 1 min)
Cost Efficiency	Supports optimal selection through TLD comparison
Documentation	Easy team sharing with auto-generated reports
Productivity	Focus on core problems by automating repetitive tasks

Conclusion

Domain Checker is more than a simple domain search tool. It’s a productivity tool that helps developers and entrepreneurs escape repetitive tasks and focus on truly important problems.

By solving small daily inconveniences with AI and automation, we can create greater value.

Related Projects:

server-status-checker - SSH config-based server status checker

Tags: #DevTools #OpenSource #Claude #AI #Productivity #Domain

Korean Version: 한국어 버전

[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: 한국어 버전