Over the past few months, we built and published 13 MCP servers covering the MCP ecosystem itself, developer tooling, infrastructure management, and SaaS integrations. All 13 are on npm and work with Claude Code, Cursor, and any other MCP client. Twelve are MIT-licensed open source; the thirteenth is Yaw MCP - a free, local-first orchestrator CLI that ties them all together.

This is what we built, why we built it, and what we learned along the way.

The Servers

Yaw MCP

An MCP orchestrator CLI, originally shipped as mcph. One command wires it into Claude Code, Codex CLI, Gemini CLI, Claude Desktop, Cursor, VS Code, Windsurf, Zed, Cline, or Continue.dev, then runs every MCP server you’ve configured from a local JSON file you control. Free forever - no account, no license, nothing to buy. Source on GitHub, though the package itself is published UNLICENSED rather than MIT.

npm install -g @yawlabs/mcp && yaw-mcp install <client>

ctxlint

A linter for AI context files. It validates your CLAUDE.md, .cursorrules, and other context files against your actual codebase. Catches broken paths, wrong commands, stale context, and token waste. Ships with a built-in MCP server so your agent can audit its own instructions.

npx -y @yawlabs/ctxlint

mcp-compliance

A test suite that validates any MCP server against the 2025-11-25 specification. Tool schemas, error handling, protocol behavior - it checks everything. We built this to test our own servers and opened it up because the ecosystem needs it. If you're building an MCP server, run your server through it before you ship.

npx -y @yawlabs/mcp-compliance

tailscale-mcp

The largest of the thirteen. 89 admin-API tools (plus 4 opt-in local-CLI diagnostics) covering devices, ACLs, DNS, auth keys, users, webhooks, audit logging, log streaming, posture management, and Tailscale Services. The Tailscale API is broad, and we wanted full coverage. The hardest part was ACL updates - Tailscale uses HuJSON (JSON with comments and trailing commas), and a naive implementation would strip comments on every write. We preserve formatting by round-tripping through HuJSON parsing and using ETag-based concurrency control so two agents can't stomp on each other's changes. What that buys you day to day: five tailnet audits answered in one prompt.

npx -y @yawlabs/tailscale-mcp

npmjs-mcp

Turns the npm registry into a tool your agent can query. Package search, security audits, dependency trees, download stats, version comparison, org management, and provenance checks. If you're evaluating a package or auditing your dependencies, the agent can pull the data directly instead of you switching to a browser.

npx -y @yawlabs/npmjs-mcp

ssh-mcp

Gives AI agents SSH access with built-in diagnostics. Run commands on remote hosts, transfer files, manage tunnels, and troubleshoot connectivity issues. When something fails, the server provides structured diagnostic output instead of a raw error, so the agent can actually fix the problem.

npx -y @yawlabs/ssh-mcp

postgres-mcp

Queries PostgreSQL from an AI assistant, read-only by default - writes opt in via ALLOW_WRITES=1. 21 tools: schema introspection, EXPLAIN with optional HypoPG hypothetical indexes, pg_stat_statements diagnostics, lock inspection, and role/privilege awareness. It speaks the extended-query protocol, which closes the stacked-query SQL injection class - a drop-in replacement for the deprecated @modelcontextprotocol/server-postgres, which still has a known SQLi.

npx -y @yawlabs/postgres-mcp

electron-mcp

Gives AI assistants deep knowledge of Electron app internals. IPC scaffolding generators, security auditing for contextIsolation and sandbox settings, build tooling, and development intelligence. We built it while working on the Yaw Terminal itself - having an agent that understands Electron's main/renderer split, preload scripts, and node integration makes Electron work dramatically less painful. Pair it with electron-optimize, our drop-in utilities library for temp file cleanup, window bounds validation, startup timing, cache management, and power state handling.

npx -y @yawlabs/electron-mcp

caddy-mcp

Manages Caddy web servers via the admin API. Configure reverse proxies, manage TLS certificates, update routes. Caddy's admin API is clean and well-documented, which made this one of the faster servers to build.

npx -y @yawlabs/caddy-mcp

fetch-mcp

HTTP fetch with guardrails. SSRF protection (blocks private IPs, RFC 1918 ranges, cloud metadata endpoints), HTML-to-markdown, reader-mode extraction, metadata / link / sitemap / RSS-Atom parsing, and robots.txt verdicts. Built for agents that need to read the web without becoming a vector for blind-SSRF attacks against your own network.

npx -y @yawlabs/fetch-mcp

aws-mcp

Calls any AWS API from an AI assistant. One generic aws_call tool covers the full CLI surface, seven aws_resource_* tools wrap the Cloud Control API for generic CRUD across hundreds of resource types (including a diff that simulates JSON-Patch updates locally before they hit AWS), and a device-code SSO flow handles mid-session token expiry without dropping you back to a terminal. We wrote up the reasoning in an alternative to the official AWS MCP server.

npx -y @yawlabs/aws-mcp

lemonsqueezy-mcp

Connects your LemonSqueezy store to AI assistants. Products, variants, orders, subscriptions, license keys, customers, discounts, webhooks, and checkout links. We use LemonSqueezy for yaw's licensing, so this server scratches our own itch.

npx -y @yawlabs/lemonsqueezy-mcp

redis-mcp

Inspects and operates Redis from an AI assistant. SCAN-based key exploration instead of a blocking KEYS, TTL / memory / keyspace introspection, slowlog and INFO health checks, and a DBA advisor that flags risky patterns before they turn into an incident. The newest of the thirteen.

npx -y @yawlabs/redis-mcp

What We Learned

The lessons below are the short form. The long form -- with worked examples per pattern, the @yawlabs portfolio case studies, and chapters on schema, auth, error handling, testing, and hosting -- is MCP in Production (and the longest chapter, on the tool-surface problem, has a standalone form at MCP schema design).

Tool descriptions are more important than tool implementations

The LLM decides which tool to call based on the name and description. If your description is ambiguous, the agent will pick the wrong tool. If it's too long, it wastes context. We spent more time writing and rewriting tool descriptions than we expected. A good rule: describe what the tool does, not what it is. "List all devices in the tailnet with their online status, IP addresses, and tags" beats "Get devices endpoint."

Return structured data, not messages

Early versions of our servers returned human-readable strings: "Successfully created auth key tskey-auth-abc123." That's fine for a chat response, but terrible for tool chaining. When the agent needs to use that key in the next step, it has to parse the string. Return structured JSON and let the agent decide how to present it.

Error responses need to be actionable

When a Tailscale API call fails with a 403, don't just return "Forbidden." Return what permission is missing, what scope the current key has, and how to fix it. The agent can't fix problems it can't diagnose. Our ssh-mcp server was built around this principle - every failure includes structured diagnostics.

Keep the tool count reasonable

tailscale-mcp has 89 tools. That's a lot. Every tool description consumes context tokens, and some MCP clients struggle with large tool lists. If we were starting over, we'd consider grouping related operations into fewer tools with a action parameter. But for full API coverage, sometimes you need the granularity. We put numbers on the tradeoff in the hidden cost of 200 MCP tools in context.

npx distribution is great for adoption, rough for cold starts

Publishing on npm with npx -y @yawlabs/server-name makes installation trivial. But the first run downloads and installs the package, which can take several seconds. Users expect MCP servers to start instantly. We're looking at pre-built binaries and better caching to address this.

Test against the spec, not just your client

We built mcp-compliance because we kept finding edge cases where our servers worked in Claude Code but broke in other clients. The MCP spec has nuances around error codes, pagination, and schema validation that are easy to get wrong. If your server only works in one client, it's not an MCP server - it's a plugin.

What's Next

We're continuing to maintain all 13 servers and add coverage as APIs evolve. They run alongside Yaw MCP, our local-first orchestrator CLI that ties everything together with token-budget-aware dispatch.

All servers are on our MCP Servers page with install commands, descriptions, and links to GitHub and npm. To wire up every one of them at once rather than server by server, Yaw MCP installs them into whichever client you use with a single command.

Published by Yaw Labs.

Related Articles