mcp-stack

14 production-ready MCP servers covering auth, storage, scheduling, validation, observability, and more — all in the official MCP Registry.

Comment

Inspiration

The Model Context Protocol (MCP) unlocked a new class of integrations between AI agents and external systems. But the ecosystem was missing a set of reliable, production-grade utility servers that every agent workflow needs: auth, storage, scheduling, validation, search, and observability. I built mcp-stack to fill that gap — 14 servers, all published to npm and registered in the official MCP Registry.

What it does

mcp-stack is a collection of 14 MCP servers, each handling a distinct cross-cutting concern for AI agent workflows:

Server Role
mcp-auth-server JWT / API-key auth middleware
mcp-storage-server Object storage abstraction (S3-compatible)
mcp-scheduler-server Cron + one-shot job scheduling
mcp-validator-server JSON Schema input validation
mcp-search-server Full-text and semantic search
mcp-notification-server Multi-channel alert dispatch
mcp-cache-server TTL-aware result caching
mcp-logger-server Structured agent event logging
mcp-rate-limiter-server Token bucket rate limiting
mcp-transformer-server Data format transformation
mcp-monitor-server Health checks + uptime monitoring
mcp-config-server Runtime configuration management
mcp-audit-server Tamper-evident audit trail
mcp-gateway-server Unified entry point + routing

Every server follows the same pattern: TypeScript, MCP SDK, Zod-validated inputs, zero mandatory cloud dependency, offline-testable stubs.

How I built it

  • MCP SDK (@modelcontextprotocol/sdk) for McpServer + StdioServerTransport
  • Zod for schema-first tool input validation on every server
  • TypeScript with strict mode; compiled to ESM
  • All 14 packages published to npm under the @mukundakatta scope
  • Each server registered in the official MCP Registry (registry.smithery.ai)

Challenges

  • Designing a consistent API surface across 14 different domains while keeping each server independently deployable
  • Making every server work in offline/stub mode so CI passes without live credentials
  • Fitting the full server lifecycle (stdio transport, graceful shutdown, error propagation) into a pattern small enough to clone across 14 packages without drift

What I learned

MCP's stdio transport is elegant — each server is a tiny process that any host (Claude Desktop, a custom agent loop, an IDE plugin) can spawn. The registry makes discovery easy. The real work is in designing good tool schemas: the input validation layer is what makes these servers trustworthy in agentic contexts where the LLM generates the args.

Built With

Share this project:

Updates