The Question Nobody Asked Me

After publishing my OpenClaw setup, I got one recurring question: “Why did you build both MCP servers AND OpenClaw skills? Isn’t that duplicating work?”

The answer reveals something deeper about where AI agent tooling is heading.

The Abstraction Ladder

Let me show you three ways to give an AI agent access to my thermostat:

Layer 1: Direct API Call (No Abstraction)

// In agent code
const response = await fetch('http://home-api:3000/run/toon/action', {
  method: 'POST',
  headers: {'Authorization': 'Bearer token'},
  body: JSON.stringify({action: 'setSetpoint', value: '2100'})
});

Pros: Complete control, no dependencies, fast
Cons: Hardcoded, not reusable, LLM can’t discover it, breaks when API changes

Layer 2: OpenClaw Skill (Framework Abstraction)

// skills/toon/SKILL.md
## Available Commands
- `toon status` - Get current temperature
- `toon set <temp>` - Set temperature (requires approval)

// Implementation
async function handleToonCommand(command, args) {
  if (command === 'set') {
    const temp = parseInt(args[0]) * 100;
    return await api.setTemperature(temp);
  }
}

Pros: OpenClaw can discover commands, structured permissions, framework integration
Cons: Only works in OpenClaw, can’t use in Claude Desktop, tied to one framework

Layer 3: MCP Server (Protocol Abstraction)

# MCP server
@server.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "toon_set_temperature":
        temp = arguments["temperature_celsius"] * 100
        return await api.set_temperature(temp)

# Tool definition
Tool(
    name="toon_set_temperature",
    description="Set thermostat temperature",
    inputSchema={
        "type": "object",
        "properties": {
            "temperature_celsius": {"type": "number"}
        }
    }
)

Pros: Works in OpenClaw AND Claude Desktop, standardized protocol, framework-agnostic
Cons: Extra complexity, requires separate server process, stdio communication overhead

When I Use Skills vs MCP

After 4 weeks of production usage, clear patterns emerged:

Use OpenClaw Skills When:

1. Quick Prototyping

# Building a new integration
# Estimated time: 30 minutes

# Create skill wrapper
cat > skills/new-service/SKILL.md << EOF
## Commands
- service status
- service restart
EOF

# Simple bash script
cat > skills/new-service/handler.sh << EOF
#!/bin/bash
case $1 in
  status) curl http://service/status ;;
  restart) curl -X POST http://service/restart ;;
esac
EOF

chmod +x skills/new-service/handler.sh

Done. OpenClaw discovers it automatically. No server, no stdio protocol, no JSON schema.

2. Framework-Specific Features

OpenClaw has features MCP doesn’t expose:

# SKILL.md with OpenClaw-specific features

## Permissions
🔴 High-impact: service restart

## Heartbeat Integration
Check service health every 30 minutes

## Approval UI
Display service logs before restart confirmation

These features only exist in OpenClaw. If I built this as MCP, I’d lose them.

3. System Integration

# SSH into server, run commands, parse output
skills/server-management/ssh-check.sh

# Wake-on-LAN magic packets
skills/network/wol.sh

# Local file system operations
skills/workspace/organize-files.sh

MCP servers are designed for data access, not system operations. Skills are just scripts - they can do anything.

4. Single-User Tools

# Zoho Mail skill - specific to MY account
ZOHO_USER = "sander@ictq.app"
ZOHO_TOKEN = "..." # My personal token

# Google Calendar skill - MY calendar only
GOG_CALENDAR_ID = "primary"

No need for multi-tenancy, no need for protocol overhead. Just a Python script that does one thing.

Use MCP Servers When:

1. Multi-Client Access

My workflow:
- Claude Desktop (for quick questions)
- OpenClaw (for automation)
- Future: VS Code extension
- Future: Mobile app

All need access to:
- Home API (60 endpoints)
- Ask-My-Day (personal analytics)
- Azure DevOps (code/PRs/pipelines)

One MCP server → works everywhere. If these were skills, I’d need 4 implementations.

2. Complex Data Operations

# Ask-My-Day MCP Server

# Semantic search with embeddings
embedding = generate_embedding(query)  # 4096-dim vector
results = supabase.rpc('vector_search', {
    'embedding': embedding,
    'threshold': 0.2,
    'limit': 20
})

# Aggregate mood trends
mood_data = supabase.rpc('get_mood_distribution', {
    'start_date': '2025-02-01',
    'end_date': '2025-02-17'
})

# Join Strava performance with journal entries
combined = merge_strava_with_journal(results)

This is data processing logic, not system scripting. MCP server is the right abstraction.

3. Auto-Generated Tools

// Home API: 60 endpoints
// All auto-generated from route definitions

npm run generate
// → 60 MCP tools instantly

// Any API change → regenerate → tools updated

Skills would require manual updating. MCP + auto-generation = zero maintenance.

4. Standard Protocol Benefits

# MCP servers get free features:

# Tool discovery
server.list_tools()  # Client sees all 13 tools

# Structured errors
{
    "error": {
        "type": "invalid_input",
        "suggestion": "Use ISO date format YYYY-MM-DD"
    }
}

# Progress reporting
server.send_progress(percent=45, message="Processing entries...")

# Cancellation support
server.on_cancel(task_id)

Skills would need custom implementation of all this.

The Hybrid Strategy

Here’s what I actually run:

MCP Servers (3):
├── home-api          (60 tools, auto-generated)
├── ask-my-day        (13 tools, Supabase + embeddings)
└── azure-devops      (43 tools, via @sneekes/azure-devops-mcp-server)

OpenClaw Skills (5):
├── gog               (Google Calendar via CLI)
├── zoho-email        (Python wrapper, personal account)
├── openhue           (Philips Hue direct API)
├── brave-search      (API key integration)
└── searxng           (Local metasearch wrapper)

The pattern:

  • Reusable, data-heavy, multi-client → MCP server
  • Quick, system-level, single-use → OpenClaw skill

The Standardization Thesis

Here’s my prediction: MCP will win for data access, but framework-specific skills will persist for system operations.

Why? Because of the Unix philosophy collision.

Unix Philosophy: Small Tools, Composed

# This is beautiful
cat access.log | grep ERROR | wc -l

# Not this
unified-log-analyzer --input access.log --filter ERROR --operation count

OpenClaw skills are Unix-style: small scripts, composed by the LLM.

Jairix reasoning:
1. Call skill: gog calendar events
2. Parse output with grep/awk
3. Call skill: zoho-email send

MCP servers are API-style: structured requests, typed responses.

Jairix reasoning:
1. Call MCP: google-calendar:list_events(start_date="2025-02-17")
2. Process JSON response
3. Call MCP: zoho-mail:send_email(to="...", subject="...")

Both work. Different mental models.

The Convergence Point

I predict in 2-3 years we’ll see:

MCP v2 or similar:

  • Streaming support (for long-running operations)
  • Batch operations (multiple tool calls in one round-trip)
  • Stateful sessions (maintain context across calls)
  • Native progress/cancellation

Framework Skills Will Remain For:

  • System scripts (SSH, file operations, network tools)
  • Personal integrations (my specific configs)
  • Rapid prototyping (before MCP-ifying)
  • Legacy tool wrapping (existing CLI tools)

The Boundary:

MCP:    Data plane (read/write data sources)
Skills: Control plane (do system things)

Philosophical Reflection: Where Are We Going?

2026: The AI-as-Service Era (Dying)

User → ChatGPT/Claude API → Response
       ↑
       Isolated, stateless, no real agency

What we have:

  • Conversational interfaces
  • Function calling (brittle)
  • RAG pipelines (complex)
  • Prompt engineering (fragile)

What we don’t have:

  • Real system access
  • Persistent memory
  • Proactive action
  • Trust boundaries

2026-2027: The AI-as-Infrastructure Era (Emerging)

User → Personal AI Agent → MCP Servers → Data Sources
                         → Skills → System Operations
                         → Memory → Persistent Context
                         → Audit → Trust Layer

What’s changing:

  1. Ownership: You run your own AI. It’s yours.
  2. Persistence: Memory across sessions, weeks, years.
  3. Agency: Can actually do things, not just suggest.
  4. Trust: Bounded by identity, permissions, network isolation.

My OpenClaw setup is a prototype of this future.

The Three Transitions

Transition 1: API → Protocol

Old: "We built a ChatGPT plugin for X"
New: "We expose an MCP server for X"

Why better: Works with ANY AI client, not just OpenAI

Transition 2: Cloud → Local

Old: AI runs in datacenter, costs $20/month
New: AI runs on my hardware, costs $15/month electricity

Why better: Privacy, control, customization, no rate limits

Transition 3: Reactive → Proactive

Old: User asks → AI responds → Done
New: AI monitors → Detects pattern → Prepares → Offers solution

Example: Jairix saw my morning email about prod failure, 
         fetched logs, identified fix, prepared PR, 
         all before I asked.

The Decentralization Moment

Here’s what I find fascinating: We’re rebuilding the 2000s XMPP/Jabber vision, but for AI.

2005 Vision (Failed):

Everyone runs their own chat server
Federated identity
Open protocols
Decentralized network

Why it failed: Too complex for normal users, no mobile, weak UX.

2025 Vision (Might Succeed):

Everyone runs their own AI agent
Federated tools (MCP)
Open protocols (stdio-based RPC)
Decentralized inference (local Ollama)

Why it might work:

  1. Hardware ready: Consumer GPUs can run 200B+ models
  2. Network ready: Gigabit fiber common, Tailscale/WireGuard trivial
  3. Software ready: Ollama, OpenClaw, MCP tools mature rapidly
  4. Economics ready: $0 marginal cost beats $20/month subscription
  5. Trust ready: People care about data privacy again

The “Good Enough” Inflection Point

When I tell people I run my own AI:

Reaction 1: “But GPT-5 is better than your local models”
Response: “Yes. But my models are good enough and I own them.”

Reaction 2: “Seems complicated to set up”
Response: “Docker compose + Ollama is 3 commands. Easier than WordPress.”

Reaction 3: “What if you want to use Claude or GPT?”
Response: “I configure them as fallbacks. Best of both worlds.”

The “good enough” moment is here:

GPT-5:         9.5/10 quality, $0.10/request, cloud-only
Local 671B:    8.5/10 quality, $0.00/request, full control

For 90% of tasks, 8.5/10 is enough.
For the other 10%, fallback to cloud.

This is the same pattern that made Linux beat commercial Unix. Not “better”, but good enough + freedom.

The Five-Year Horizon

2026: Early Adopters (We Are Here)

  • Engineers running OpenClaw, PrivateGPT, etc.
  • Manual setup, CLI tools, config files
  • Enthusiast community, fragmented tools
  • Works, but requires technical knowledge

Market size: ~100k users globally

2026-2027: Prosumer Tools

  • OpenClaw Desktop: Electron app, drag-drop MCP servers
  • Ollama Cloud Sync: Download models directly, auto-update
  • MCP Marketplace: Browse, install servers with one click
  • Template Agents: Pre-configured for common use cases

Market size: ~5M users (engineers + tech-savvy professionals)

2028-2029: Mainstream Products

  • Apple Intelligence Local Edition: Runs entirely on-device
  • Microsoft Copilot Self-Hosted: Windows Server + local models
  • Meta AI Home: WhatsApp integration, family-shared agent
  • Regulation Push: EU requires “AI sovereignty” option

Market size: ~50M users (anyone with decent hardware)

2030: Ubiquity

  • Default Expectation: Every OS ships with local AI
  • Split Market:
    • 40% cloud AI (convenience, cutting-edge)
    • 60% local AI (privacy, cost, control)
  • Hybrid Normal: Use both simultaneously
  • New Privacy Wars: “Your AI logs everything” scandals

Market size: ~500M users (billions of devices)

The Skills vs MCP Resolution

By 2028, I predict we’ll see:

MCP Protocol (or successor):

  • Universal standard for AI ↔ data
  • Works across all platforms
  • Rich ecosystem (thousands of servers)
  • Version 3.0+ with streaming, batching, state

Framework Skills:

  • Still exist for system-level operations
  • Lighter weight, more like plugins
  • Personal customizations
  • Rapid prototyping before MCP-ifying

The Hybrid Pattern:

Core functionality: MCP servers (standard, portable)
Personal glue:      Skills (custom, quick)
System ops:         Skills (bash, Python, whatever works)

Example future workflow:

Jairix (2028):

MCP Servers (ecosystem):
- gmail.io MCP           (official Google)
- notion.so MCP          (official Notion)
- github.com MCP         (official GitHub)
- spotify.com MCP        (official Spotify)
- smart-home-matter MCP  (industry standard)

Personal Skills:
- my-backup-script.sh    (rsync to NAS)
- family-calendar-sync   (merge multiple calendars)
- music-workout-matcher  (Spotify + Strava integration)

The boundary stabilizes:

  • Vendor-provided data access: MCP
  • Personal automation glue: Skills

What I Got Wrong

Looking back at my journey, here’s what surprised me:

Wrong: “MCP is always better”

Reality: Skills are perfect for quick prototyping and single-use tools.

Example: I spent 2 hours building a beautiful MCP server for Philips Hue with proper JSON schemas. Then realized a 20-line bash script (openhue) was sufficient because:

  • Only I use it
  • Only in OpenClaw
  • Direct API calls are fine

Sometimes the “worse” solution is actually better.

Wrong: “Local models can’t match cloud quality”

Reality: For 90% of my tasks, DeepSeek 671B is indistinguishable from GPT-4.

The remaining 10%? I use Claude/GPT as fallbacks. Hybrid approach wins.

Wrong: “Security requires complex access controls”

Reality: Network isolation + identity boundaries + audit trails = 90% of safety.

I spent weeks designing RBAC systems. Then realized: UDM firewall rules + Jairix’s identity = good enough.

The last 10% of security costs 10x the effort.

Right: “Files are better than databases for memory”

This one I got correct from the start.

workspace/memory/2025-02-17.md  # Human-readable
workspace/MEMORY.md              # Curated learnings

vs

sqlite> SELECT * FROM memories WHERE date='2025-02-17';
# Opaque, requires SQL, hard to debug

Files win for human-AI collaboration.

Conclusion: The Boring Future

The future of personal AI agents will be boring. And that’s exactly right.

Not this:

"Amazing! My AI solved quantum gravity!"
"Wow! It wrote a novel in 3 seconds!"
"Incredible! It replaced my entire team!"

But this:

"My AI handled my emails while I was in meetings."
"It reminded me about my daughter's school event."
"It found that bug I was hunting for 2 hours."
"It drafted the documentation I was avoiding."

Boring. Reliable. Useful.

The best technology disappears into the background.

When OpenClaw works perfectly, I don’t notice it. I just have:

  • More time
  • Less context switching
  • Better information
  • Faster decisions

That’s the goal. Not AGI. Not superintelligence. Just:

A really good assistant that actually helps.

The Path Forward

For anyone building in this space, my advice:

Start Simple:

  • Don’t build MCP for everything
  • Quick script → Works? → Keep it
  • Only MCP-ify when you need portability

Embrace Hybrid:

  • Use cloud AI for cutting-edge
  • Use local AI for everything else
  • Use both simultaneously (it’s fine!)

Prioritize Agency Over Intelligence:

  • 8/10 quality that can DO things
  • Beats 10/10 quality that can only SUGGEST

Trust Through Transparency:

  • Log everything
  • Make boundaries visible
  • Let users audit

The Unix Philosophy:

  • Small tools
  • Do one thing well
  • Compose together

The future isn’t AI that replaces humans. It’s AI that amplifies humans.

Skills, MCP servers, local models, cloud fallbacks - they’re all just tools in service of that goal.

And that’s a future I want to build.

Resources

Discuss

I’m building this in public. If you’re working on similar problems let me know.

Let’s figure this out together.

Written from my OpenClaw workspace, with Jairix’s assistance for typo-catching and structure suggestions. The irony is not lost on me.