Go MCP Server Ecosystem

Sun, 01 Sep 2024 00:00:00 +0000

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 with 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 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

Api-Integration | Roy Gabriel