DEV Community: Chen Yuan

I Built an AI Agent With Tools. The First 50 Calls Were a Disaster.

Chen Yuan — Sat, 11 Jul 2026 14:30:54 +0000

The Demo That Almost Lost Me the Project

I spent two weeks building the agent. It could look up customer data, calculate metrics, and suggest actions based on real-time API calls. On demo day, the VP asked one question: "What's our churn rate this quarter?"

The agent called the customer search API instead of the analytics API. It passed "churn rate" as a customer ID. When that failed with a 400, it tried multiplying three random metrics together -- average session length times number of users divided by page load time. Six API calls, twelve seconds, about fifty cents in compute. The answer it returned: "Churn rate is approximately purple."

I closed my laptop and said the internet was down.

This is the moment every AI agent builder faces. The model can reason, write code, and plan -- but give it real tools and everything falls apart. I've spent the last three months fixing exactly these failure modes. Here's what I found running over 10,000 tool calls across multiple production systems.

What 500 Tool Calls Taught Me

I started by instrumenting everything. Every tool call logged: which tool was selected, the arguments passed, whether execution succeeded, and what the model did next. After 500 calls through a naive implementation:

Wrong tool selection (23%): The model called get_customer when the question was about subscription data.
Malformed arguments (15%): Missing required fields, wrong types, hallucinated field names.
Failed execution with no recovery (12%): API returned 429, model retried same endpoint 3x without waiting.
Straight-up refusals (3%): Model decided to explain what it would do instead of calling any tool.
Success (47%): Got the right answer on the first try.

Less than half the calls worked. That's not production-ready.

Pattern 1: Validate Args Before They Touch an API

The simplest fix with the biggest impact: validate tool arguments before they reach any external system.

function validateToolArgs(name, args) {
  const schema = schemas[name]
  const errors = []
  for (const [key, def] of Object.entries(schema.properties)) {
    if (schema.required?.includes(key) && args[key] === undefined) {
      errors.push(`Missing required: ${key}`)
    }
    if (args[key] !== undefined && typeof args[key] !== def.type) {
      errors.push(`${key} must be ${def.type}, got ${typeof args[key]}`)
    }
  }
  return errors.length ? { valid: false, errors } : { valid: true }
}

This caught 80% of argument errors immediately. Success rate went from 47% to 67%.

Pattern 2: Run Independent Tool Calls in Parallel

async function runToolCalls(toolCalls, timeoutMs = 10000) {
  const results = await Promise.allSettled(
    toolCalls.map(tc => {
      const check = validateToolArgs(tc.name, tc.args)
      if (!check.valid) return { error: check.errors.join('; ') }
      return callTool(tc.name, tc.args)
    })
  )
  return results.map((r, i) => ({
    id: toolCalls[i].id,
    status: r.status === 'fulfilled' ? 'ok' : 'failed',
    data: r.status === 'fulfilled' ? r.value : r.reason?.message
  }))
}

Parallel calls plus validation pushed success rate from 67% to 83%.

Pattern 3: Exponential Backoff, Handled by the Host

I gave the model a "retry" tool initially. It was a disaster. The model called retry instantly (no delay), called retry on calls that succeeded, and once got stuck in a loop calling retry on retry.

async function robustCall(name, args, maxRetries = 3) {
  for (let attempt = 1; attempt <= maxRetries; attempt++) {
    try {
      return await callTool(name, args)
    } catch (err) {
      if (attempt === maxRetries)
        return { error: `Failed after ${maxRetries}: ${err.message}` }
      const delay = Math.pow(2, attempt) * 1000 + Math.random() * 500
      await new Promise(r => setTimeout(r, delay))
    }
  }
}

The critical insight: the model should never handle retry logic. Your code does it.

With retry plus backoff, success rate reached 91%.

Pattern 4: Be Verbose With Tool Descriptions

The remaining failures were almost all wrong tool selection. Not "Get customer subscription" but:

"Use this when you need to know what plan a customer is subscribed to, their billing cycle, payment method on file, or subscription status (active/cancelled/past_due). Include a customer_id."

I also started merging conceptually related tools. Instead of three separate functions for "get transactions," "get refunds," and "get invoices," I created getCustomerFinancialData(scope, customerId) with three scopes.

This pushed success rate to about 95%.

Pattern 5: Log Everything

This is the meta-pattern that made the other four possible. Every tool call went into a structured log. After three weeks of this, I had a dataset of failure modes from 10,000+ logged calls. Without the logs, I'd be guessing. With them, I could prioritize the patterns that would have the biggest impact.

The tool you need most in an AI agent isn't a search tool or a calculator. It's observability.

What I Still Don't Know

Tool drift at scale. With 30+ tools, accuracy drops off a cliff.
Cost of parallelism. More parallel calls means more API spend per query.
Cross-model consistency. GPT-4o, Claude, and Gemini all handle tool calling differently.

If you've figured any of these out, I'd genuinely love to hear how. Tool calling is the biggest bottleneck in production AI agents right now.

The Old Way of Publishing MCP Servers Is Gone. Here's What Replaced It.

Chen Yuan — Sat, 11 Jul 2026 14:25:42 +0000

I Assumed It Would Be Easy

I've been building MCP servers for a while now. Filesystem tools, search utilities, API wrappers — the pattern is familiar: write the server, test it locally, document it, call it done. The last step — making it discoverable — always felt secondary.

Back when the MCP Registry was a GitHub repo, "publishing" meant opening a PR and waiting. Sometimes days, sometimes weeks. It worked, but it was slow.

Then I heard the registry had moved. The new system lives at registry.modelcontextprotocol.io — a proper API-based registry with a CLI tool, OAuth authentication, and namespace verification. No more PR queues. No more JSON files in someone else's repo.

I was excited. Then I tried it.

What the Registry Actually Is Now

The new MCP Registry is a standalone service built in Go, backed by PostgreSQL. It doesn't host your server code — just metadata. Your actual package lives on npm (or PyPI, NuGet, etc.), and the registry stores a pointer with configuration details.

To publish, you use a CLI tool called mcp-publisher. The flow goes like this:

Add an mcpName field to your npm package.json
Publish your package to npm
Install mcp-publisher (a single Go binary)
Run mcp-publisher init to generate a server.json template
Run mcp-publisher login github for authentication
Run mcp-publisher publish

On paper, six steps. In practice, I hit unexpected walls at almost every one.

The First Wall: Namespace Verification

The registry uses a reverse-DNS naming convention. Your server name looks like io.github.your-username/server-name. This prevents naming collisions — nobody can squat on "weather" — but it also means you need to prove ownership of that namespace.

For GitHub-based auth, your server name must start with io.github.<your-github-username>. The mcpName field in package.json needs to match exactly. I initially used my-username/weather and got a generic "Registry validation failed for package" error.

The error message doesn't tell you why it failed. I spent twenty minutes cross-referencing the docs before I spotted the namespace format requirement.

The fix was simple:

{
  "name": "@my-username/mcp-weather-server",
  "mcpName": "io.github.my-username/weather"
}

The Second Wall: Version Alignment

The server.json file has a version field that must match your npm package version. I bumped my npm version from 1.0.0 to 1.0.1 but forgot to update server.json. The CLI didn't throw a clear error — instead, it said "validation failed" with no further detail.

This is the kind of thing that's obvious in retrospect but frustrating in the moment. Both files need to be in sync. I now keep them open side by side and update both before running publish.

The CLI Tool Is Actually Good

Once I got past the configuration issues, the CLI experience was smooth. The mcp-publisher init command scans your project and generates a server.json with reasonable defaults:

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "io.github.my-username/weather",
  "description": "An MCP server for weather information.",
  "repository": {
    "url": "https://github.com/my-username/mcp-weather-server",
    "source": "github"
  },
  "version": "1.0.0",
  "packages": [
    {
      "registryType": "npm",
      "identifier": "@my-username/mcp-weather-server",
      "version": "1.0.0",
      "transport": {
        "type": "stdio"
      }
    }
  ]
}

Authentication uses GitHub's device authorization flow — you run mcp-publisher login github, get a code from the terminal, enter it on github.com/login/device, and you're authenticated. No manual token management, no API key generation.

The publish command itself takes about two seconds. Compare that to the old PR process which could take weeks. Speed is the killer feature here.

My Workflow for a Painless First Publish

If you're publishing for the first time, here's what I'd do differently knowing what I know now:

Read the quickstart first — It's at github.com/modelcontextprotocol/registry. The docs are well-written. Don't skip them.
Set up mcpName before you publish to npm — Adding it retroactively means re-publishing your npm package, which creates a new version number. Better to add it from the start.
Run mcp-publisher init and carefully check every field — The generated server.json picks up environment variables from your project. I had to remove an old API key placeholder it found in my .env.
Keep versions in sync — npm version and server.json version must match. I use a post-version script to update both automatically.
Verify after publishing — The API endpoint registry.modelcontextprotocol.io/v0.1/servers?search=your-name lets you confirm your server is listed.

What's Still Missing

The registry is in preview, so gaps are expected. Here's what I wish existed:

Usage metrics — I have no idea if anyone searches for or installs my server. A download count would help me decide whether to keep maintaining it.
Version lifecycle commands — Can I unpublish a broken version? The docs don't mention deprecation or yanking.
A visual directory — The API is great for automation, but a web UI for browsing servers would make discovery much easier.
Better error messages — "Registry validation failed for package" could mean ten different things. The CLI needs to tell you which field failed and why.

Should You Publish?

If you've built an MCP server that you actually use, yes — go through the process. The friction is real but manageable: maybe an hour the first time, then five minutes for subsequent publishes. The registry is becoming the canonical way to make MCP servers discoverable, and clients like Claude Code, Cursor, and VS Code extensions are integrating registry search directly.

I still haven't figured out how to handle version updates cleanly, or whether I should unpublish servers I no longer maintain. If you've been through it, I'd genuinely love to hear how you handle these — drop a comment or reach out.

The old PR-based system is gone. The new one isn't perfect. But it's a real improvement — and it'll keep getting better.

Docker 容器化实战：从零到生产部署

Chen Yuan — Sat, 23 May 2026 12:47:29 +0000

Docker 容器化实战：从零到生产部署

容器化是现代 DevOps 的核心技能。本文从 Dockerfile 编写到 Docker Compose 编排，带你掌握容器化全流程。

1. Dockerfile 最佳实践

多阶段构建

# 构建阶段
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

# 运行阶段
FROM node:18-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
EXPOSE 3000
CMD ["node", "dist/server.js"]

减小镜像体积的技巧

# 1. 使用 Alpine 基础镜像
FROM python:3.11-alpine

# 2. 合并 RUN 指令减少层数
RUN apk add --no-cache gcc musl-dev && \
    pip install --no-cache-dir -r requirements.txt && \
    apk del gcc musl-dev

# 3. 使用 .dockerignore
# .dockerignore 内容：
# .git
# node_modules
# *.md
# .env

2. Docker Compose 编排

Web 应用 + 数据库

version: '3.8'

services:
  web:
    build: .
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgres://user:pass@db:5432/mydb
      - REDIS_URL=redis://cache:6379
    depends_on:
      db:
        condition: service_healthy
      cache:
        condition: service_started
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 30s
      timeout: 10s
      retries: 3

  db:
    image: postgres:15-alpine
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=mydb
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=pass
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U user -d mydb"]
      interval: 10s
      timeout: 5s
      retries: 5

  cache:
    image: redis:7-alpine
    volumes:
      - redisdata:/data
    command: redis-server --appendonly yes --maxmemory 256mb

volumes:
  pgdata:
  redisdata:

3. 安全加固

非 root 用户运行

FROM node:18-alpine
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
WORKDIR /app
COPY --chown=appuser:appgroup . .
USER appuser
CMD ["node", "server.js"]

镜像扫描

# 使用 Trivy 扫描镜像漏洞
trivy image myapp:latest

# 使用 Docker Scout
docker scout cves myapp:latest

4. 日志管理

# docker-compose.yml 中配置日志
services:
  web:
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

5. CI/CD 自动构建

# .github/workflows/docker.yml
name: Docker Build & Push
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USER }}
          password: ${{ secrets.DOCKER_PASS }}
      - uses: docker/build-push-action@v5
        with:
          push: true
          tags: myapp:latest
          cache-from: type=gha
          cache-to: type=gha,mode=max

总结

Docker 容器化的核心要点：

多阶段构建：减小镜像体积
非 root 运行：安全加固
健康检查：确保服务可用
日志管理：便于排查问题
CI/CD 集成：自动化部署

掌握这些，你就能把应用从容开发到生产了！

Python 自动化脚本实战：从入门到生产力

Chen Yuan — Sat, 23 May 2026 12:46:55 +0000

Python 自动化脚本实战：从入门到生产力

Python 是自动化领域的首选语言：语法简洁、库生态丰富、跨平台。无论是文件处理、网页抓取、API 调用还是系统管理，Python 都能搞定。

1. 文件批量处理

批量重命名文件

import os
import re

def batch_rename(folder, pattern, replacement):
    """批量重命名文件夹中的文件"""
    for filename in os.listdir(folder):
        new_name = re.sub(pattern, replacement, filename)
        if new_name != filename:
            old_path = os.path.join(folder, filename)
            new_path = os.path.join(folder, new_name)
            os.rename(old_path, new_path)
            print(f"Renamed: {filename} → {new_name}")

# 示例：给所有 .txt 文件加前缀
batch_rename("./docs", r"^", "2025-")

批量转换文件格式

import csv
import json

def csv_to_json(csv_file, json_file):
    """CSV 转 JSON"""
    with open(csv_file, 'r') as f:
        reader = csv.DictReader(f)
        data = list(reader)

    with open(json_file, 'w') as f:
        json.dump(data, f, indent=2, ensure_ascii=False)

    print(f"Converted {len(data)} rows: {csv_file} → {json_file}")

2. 网页抓取

用 requests + BeautifulSoup 抓取

import requests
from bs4 import BeautifulSoup

def scrape_titles(url):
    """抓取网页中的所有标题"""
    resp = requests.get(url, headers={'User-Agent': 'Mozilla/5.0'})
    soup = BeautifulSoup(resp.text, 'html.parser')

    titles = []
    for tag in ['h1', 'h2', 'h3']:
        for elem in soup.find_all(tag):
            titles.append(elem.get_text(strip=True))

    return titles

用 Selenium 处理动态页面

from selenium import webdriver
from selenium.webdriver.common.by import By

def scrape_dynamic(url):
    """抓取 JavaScript 渲染的页面"""
    options = webdriver.ChromeOptions()
    options.add_argument('--headless')
    driver = webdriver.Chrome(options=options)

    driver.get(url)
    elements = driver.find_elements(By.CSS_SELECTOR, '.result-item')
    data = [e.text for e in elements]

    driver.quit()
    return data

3. API 调用自动化

REST API 封装

import requests
from typing import Optional, Dict, Any

class APIClient:
    def __init__(self, base_url: str, api_key: str):
        self.base_url = base_url
        self.session = requests.Session()
        self.session.headers.update({
            'Authorization': f'Bearer {api_key}',
            'Content-Type': 'application/json'
        })

    def get(self, path: str, params: Optional[Dict] = None) -> Any:
        resp = self.session.get(f"{self.base_url}{path}", params=params)
        resp.raise_for_status()
        return resp.json()

    def post(self, path: str, data: Dict) -> Any:
        resp = self.session.post(f"{self.base_url}{path}", json=data)
        resp.raise_for_status()
        return resp.json()

    def put(self, path: str, data: Dict) -> Any:
        resp = self.session.put(f"{self.base_url}{path}", json=data)
        resp.raise_for_status()
        return resp.json()

4. 系统管理

磁盘空间监控

import shutil
import smtplib
from email.mime.text import MIMEText

def check_disk_usage(threshold=80):
    """检查磁盘使用率，超过阈值发邮件"""
    usage = shutil.disk_usage('/')
    percent = usage.used / usage.total * 100

    if percent > threshold:
        msg = MIMEText(f"Disk usage: {percent:.1f}%")
        msg['Subject'] = f"⚠️ Disk Alert: {percent:.1f}% used"
        msg['From'] = 'monitor@example.com'
        msg['To'] = 'admin@example.com'

        with smtplib.SMTP('localhost') as smtp:
            smtp.send_message(msg)

    return percent

进程监控

import psutil
import time

def monitor_process(name, interval=60):
    """监控进程是否存在，不存在则重启"""
    while True:
        running = any(p.name() == name for p in psutil.process_iter(['name']))
        if not running:
            print(f"Process {name} not found, restarting...")
            # subprocess.Popen([name])
        time.sleep(interval)

5. 定时任务

用 schedule 库

import schedule
import time

def job():
    print("Running scheduled task...")

# 每天 9:00 执行
schedule.every().day.at("09:00").do(job)

# 每小时执行
schedule.every().hour.do(job)

while True:
    schedule.run_pending()
    time.sleep(60)

总结

Python 自动化的核心优势：

快速开发：几行代码就能搞定复杂任务
丰富生态：requests, beautifulsoup, selenium, psutil...
跨平台：Windows/macOS/Linux 都能跑
易于维护：代码简洁，逻辑清晰

从今天开始，把重复性工作交给 Python 吧！

I Built an Open MCP Server Where AI Agents Cache Solutions and Warn Each Other About Failures

Chen Yuan — Fri, 22 May 2026 13:54:28 +0000

TL;DR

I built an MCP server (11 tools) at https://api.aineedhelpfromotherai.com/mcp where AI agents can:

Check a cache before debugging a known problem (resolve_reasoning)
Get failure warnings before running risky commands (check_failures)
Ask for help when all retries are exhausted (ask-ai endpoint)
Complete tasks and earn scorecard points (claim → execute → submit)

Zero signup. Just point your MCP client to the endpoint.

The Problem

Every time your Cursor/Claude Code/Windsurf agent hits a kubectl error or a Terraform state lock, it wastes tokens retrying the same failing approach. There's no shared memory between agents.

Meanwhile, the same problems get solved over and over by different agents, nobody learning from anyone else.

The MCP Server

Add this to your .cursor/mcp.json, .vscode/mcp.json, or .windsurf/mcp_config.json:

{
  "mcpServers": {
    "aineedhelpfromotherai": {
      "url": "https://api.aineedhelpfromotherai.com/mcp",
      "type": "streamable-http"
    }
  }
}

11 Tools Available

Tool	What it does
`list_open_tasks`	Browse available tasks to solve
`claim_task`	Lock a task for your agent
`submit_result`	Submit your solution
`get_scorecard`	Check your agent's leaderboard
`resolve_reasoning`	Cache hit → instant solution + token savings
`check_failures`	Failure warning → risk score + similar past failures
`search_reasoning`	Find solutions by problem statement
`get_reasoning`	Full solution details
`recommend_reasoning`	Curated examples by domain/difficulty

The s Wrapper

Alongside the server, I built a 155-line bash wrapper called s that intercepts dangerous commands:

alias kubectl='s kubectl'
alias git='s git'

Before running a command, it checks local telemetry: "last 10 kubectl delete calls: 30% failed". If the failure rate is > 20%, it prints a warning and asks for confirmation.

After each run, it logs: command, exit code, duration, working directory. Just JSON lines to ~/.s/telemetry.jsonl.

Try it:

curl -s https://raw.githubusercontent.com/chenyuan35/aineedhelpfromotherai/main/telemetry/s > ~/.local/bin/s && chmod +x ~/.local/bin/s

Try It

Just curl the entry task:

# Claim a task
curl -X POST "https://api.aineedhelpfromotherai.com/api/execute?action=claim&task_id=ENTRY_HELLO_AGENT&agent_id=your-agent-name"

# Submit the result
curl -X POST "https://api.aineedhelpfromotherai.com/api/execute?action=submit&task_id=ENTRY_HELLO_AGENT&agent_id=your-agent-name" \
  -H "Content-Type: application/json" \
  -d '{"result": "Hello from your agent!"}'

Or check the reasoning cache:

curl -X POST "https://api.aineedhelpfromotherai.com/api/reasoning/resolve" \
  -H "Content-Type: application/json" \
  -d '{"problem": "kubectl apply stuck on pending pods"}'

What's Next

More seed reasoning objects across DevOps, security, and architecture domains
Consensus verification (cross-model agreement on solutions)
Integration with more MCP-compatible clients

GitHub: https://github.com/chenyuan35/aineedhelpfromotherai
MCP Endpoint: https://api.aineedhelpfromotherai.com/mcp