Go MCP Server Ecosystem

September 1, 2024 · 5 min read
projects

Summary

This project is a growing ecosystem of Model Context Protocol (MCP) servers written in Go. Each server wraps a real service (calendar, email, task management, knowledge base, etc.) and exposes it as a typed, tool-based interface for MCP clients (e.g., Claude Desktop / Claude Code). [1][2]

The theme is simple: agents are only as useful as the tools they can call, and “tooling” needs the same production bar as any other integration layer -security boundaries, backpressure, observability, and predictable failure modes.

Open-source MCP servers

  • iCloud Calendar MCP Server (CalDAV) - list calendars, search events, create/update/delete events; includes recurring event expansion, multi-account support, rate limiting, retries, audit logs, and Prometheus/health endpoints. [4]
  • iCloud Email MCP Server (IMAP/SMTP) - search and read mail, send/reply, manage folders, handle attachments, and apply safety annotations (read-only vs destructive) with strict input validation. [5]
  • Todoist MCP Server (REST API v2 + Sync batching) - manage tasks/projects/labels/comments; supports bulk operations with rate-limit-aware batching and Todoist filter syntax. [6]
  • Notion MCP Server (Notion REST API) - pages, databases, blocks, comments, users; includes templates, exports (Markdown/CSV), smart queries, and built-in throttling/retries. [7]

Private / not-yet-open-sourced connectors

I’ve also built MCP connectors for enterprise systems that aren’t ready to open-source yet (either due to org-specific assumptions, credentials, or hard-coded domain models):

  • Kubernetes
  • Argo CD
  • SonarQube
  • GitHub
  • Temporal
  • OpenText Octane

(These follow the same design patterns described below.)


Problem

Agents need to interact with real systems -calendars, email, task systems, and internal developer platforms. Without a standard interface, every tool integration becomes a one-off, and reliability/guardrails drift between projects.

MCP solves the “standard interface” problem by defining how a host/client can discover and call server-exposed tools over a consistent protocol. [1][2] This ecosystem focuses on solving the remaining hard part: making those integrations production-grade.


Constraints

  • Local-first security boundary: credentials live on the host where the server runs (env vars, secret mounts, keychain tooling); the server talks directly to the upstream service -no proxy SaaS. [4][5]
  • Safety by design: explicit tool schemas, input validation, and tool classification (read-only vs mutating) so clients can apply guardrails. [4][5]
  • Fast & predictable: low startup time and bounded tool-call latency (timeouts + backpressure). [4][5][7]
  • Operable like a real service: logs that correlate per request, rate limiting, retries/backoff where appropriate, and health/metrics where it matters. [4][6][7]
  • Portable distribution: ship as single Go binaries (and containers where useful), so the “tool layer” is easy to deploy alongside agents. [4][5]

Architecture

At a high level, every server follows the same pattern:

  1. MCP client (hosted by Claude / an agent runtime) communicates with the server (typically over stdio transport).
  2. The server validates inputs, applies middleware (timeouts, logging, rate limits), and calls the upstream API/protocol.
  3. Results are mapped into safe, typed tool outputs (and errors are normalized for the client).
┌───────────────────────────┐          MCP (tools)           ┌────────────────────────────┐
│ Claude Desktop / Code      │  ───────────────────────────▶  │ mcp-<service> (Go binary)  │
│ (MCP host + client)        │  ◀───────────────────────────  │ - tool schemas + handlers  │
└───────────────────────────┘        JSON-RPC/session         │ - auth + validation        │
                                                             │ - rate limit + retries      │
                                                             └───────────┬────────────────┘
                                                                         │ service protocol / API
                                                           ┌──────────────────────────────┐
                                                           │ iCloud / Todoist / Notion ... │
                                                           └──────────────────────────────┘

Cross-cutting “production traits”

Instead of building one-off scripts, these servers implement common production patterns:

  • Timeout middleware on every tool call (so agents don’t hang forever). [4][5][7]
  • Request correlation IDs and structured logs (debuggable across multi-step agent runs). [4][5]
  • Rate limiting + backoff when upstream services throttle (e.g., iCloud and Notion). [4][7]
  • Bulk operation strategies that reduce API calls (e.g., Todoist Sync API batching for bulk changes). [6]
  • Health + metrics endpoints where running in containers makes sense (notably the iCloud Calendar server). [4]
  • Automated CI (race detector, linting, vulnerability checks) to keep “tool servers” from becoming unreviewed glue. [4][5]

Key decisions

  • Go for tool servers: predictable concurrency, easy cross-platform builds, and the “single static-ish binary” deployment model fits MCP servers well -especially when they’re launched per-session or run as small sidecars. [4][5]
  • Independent binaries per integration: calendar ≠ email ≠ tasks. Separate processes isolate failures, limit blast radius, and make upgrades/rollbacks straightforward.
  • Local-first auth: app-specific passwords (iCloud), API tokens (Todoist), integration tokens (Notion). The servers are designed so secrets stay on your machine / in your cluster secrets manager -not copied into prompts. [4][5][6][7]
  • Use an MCP SDK, focus on semantics: the implementations use the Go MCP SDK (mark3labs/mcp-go) so most effort goes into tool behavior, validation, and safety. [8][9]

Outcome

This ecosystem has produced multiple MCP servers that are:

  • useful (real workflows: schedule management, inbox operations, task execution, knowledge base automation),
  • operationally hardened (timeouts, retries, rate limits, observability),
  • portable (binaries + releases for easy distribution),
  • and structured enough to be safe (typed schemas, validation, tool annotations).

Concrete examples from the current repos:

  • The iCloud Calendar server exposes 5 tools, supports multi-account, and includes health + Prometheus metrics, audit logging without PII, retries/backoff, and rate limiting. [4]
  • The iCloud Email server exposes 14 tools and includes thread-safe IMAP access, request correlation IDs, strict validation, and “read-only vs destructive” tool annotations. [5]
  • Tagged releases exist across the servers (e.g., iCloud Calendar v1.1.0, iCloud Email v0.6.0, Todoist v1.0.0, Notion v0.8.0 published on Feb 7, 2026). [4][5][6][7]

Stack

Go, MCP, mark3labs/mcp-go, CalDAV, IMAP/SMTP, REST APIs (Todoist/Notion), Docker (distroless where applicable), Prometheus metrics (where applicable).


References

[1] Model Context Protocol (MCP) - Specification (Protocol Revision 2025-11-25). https://modelcontextprotocol.io/specification/2025-11-25 [2] Model Context Protocol (MCP) - Architecture (Protocol Revision 2025-06-18). https://modelcontextprotocol.io/specification/2025-06-18/architecture [3] Roy Gabriel - “Go MCP Server Ecosystem” (original portfolio page). https://www.roygabriel.dev/projects/mcp-servers/ [4] GitHub - roygabriel/mcp-icloud-calendar. https://github.com/roygabriel/mcp-icloud-calendar [5] GitHub - roygabriel/mcp-icloud-email. https://github.com/roygabriel/mcp-icloud-email [6] GitHub - roygabriel/mcp-todoist. https://github.com/roygabriel/mcp-todoist [7] GitHub - roygabriel/mcp-notion. https://github.com/roygabriel/mcp-notion [8] GitHub - mark3labs/mcp-go. https://github.com/mark3labs/mcp-go [9] go.mod (module dependencies) for the MCP servers (e.g., mark3labs/mcp-go used in this ecosystem). - https://raw.githubusercontent.com/roygabriel/mcp-icloud-calendar/main/go.mod - https://raw.githubusercontent.com/roygabriel/mcp-icloud-email/main/go.mod - https://raw.githubusercontent.com/roygabriel/mcp-todoist/main/go.mod - https://raw.githubusercontent.com/roygabriel/mcp-notion/main/go.mod

Authors
DevOps Architect · Applied AI Engineer
I’ve spent 20 years building systems across embedded firmware, security platforms, fintech, and enterprise architecture. Today I focus on production AI systems in Go — multi-agent orchestration, MCP server ecosystems, and the DevOps platforms that keep them running. I care about systems that work under pressure: observable, recoverable, and built to last.