Go MCP Server Ecosystem

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:
- MCP client (hosted by Claude / an agent runtime) communicates with the server (typically over stdio transport).
- The server validates inputs, applies middleware (timeouts, logging, rate limits), and calls the upstream API/protocol.
- 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 Emailv0.6.0, Todoistv1.0.0, Notionv0.8.0published 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