New MCP Server: Google Calendar

[JoeCardoso13]

Service

• API docs: https://developers.google.com/calendar/api
• Auth: OAuth 2.0 (primary), also supports API keys and service accounts
• Free tier: Yes — free usage quotas under Google Workspace APIs

Suggested Tools

• create_event — Create a new calendar event with title, time, attendees, and description
• update_event — Modify an existing event (time, title, attendees, etc.)
• delete_event — Remove an event from a calendar
• list_events — List upcoming events within a date range
• get_free_busy — Check availability / free-busy status for one or more users
• find_meeting_time — Find available time slots across multiple participants
• move_event — Reschedule an event to a new date/time

Suggested Skills

1. schedule-meeting — Find a free slot across participants, create the event, and confirm details
2. reschedule-meeting — Look up an existing event, check availability for a new time, and move it
3. daily-briefing — Summarize today's upcoming events with times, attendees, and conflicts

Notes

• OAuth 2.0 is the recommended auth method for user-facing calendar access
• Google Calendar API has rate limits but generous free-tier quotas
• Consider supporting multiple calendars per user (primary + shared)

[JoeCardoso13]

Build Report — Google Calendar MCP Server v0.1.0

Release: https://github.com/JoeCardoso13/mcp-google-calendar/releases/tag/v0.1.0

What went smoothly

• Implementation phase — The template-to-server transition was clean. Renaming mcp_example → mcp_google_calendar across all files was straightforward, and the code patterns from the template held up well for the Google Calendar API.
• Phase 3 (Implement & Verify) — All 45 tests passed on the first run. Format, lint, and type checks all clean.
• Phase 4 runtime validation — MCP handshake, tools/list, and resources/list all returned correct JSON-RPC responses. 10 tools registered, skill resource wired and exposed at skill://google-calendar/usage.
• CI and bundle build — CI passed immediately after push. All 3 bundle runners (darwin/arm64, linux/amd64, linux/arm64) built successfully.

Bumps on the road

1. mpak.json missing from template — The template repo didn't include an mpak.json file, which is required for registry announce. Had to create it manually. This should either be part of the template or flagged earlier in the scaffold phase.

2. Manifest name validation false positive — The build-mcpb pipeline's CONVENTIONS.md and phase-4-validate-bundle.md specify a name regex that only allows lowercase ([a-z0-9]), which flagged @JoeCardoso13/google-calendar as invalid. This is a docs drift issue — the registry is being fixed to normalize case (Fix announce/publish rejecting uppercase owner names mpak#41). Filed CONVENTIONS.md name regex rejects valid mixed-case owners contributor-toolkit#37 to track the docs update.

3. SKILL.md frontmatter inconsistency — SKILL_FORMAT.md says "no YAML frontmatter" for embedded skills, but phase-5-embed-skill.md shows frontmatter with name and description as the expected format. The actual convention includes frontmatter. Filed SKILL_FORMAT.md incorrectly states embedded skills have no frontmatter contributor-toolkit#38 to fix the docs.

4. Registry announce failed (HTTP 400) — All 3 bundle runners hit a 400 on announce due to the uppercase owner name. Bundles are on the GitHub Release but not yet on the mpak registry. Blocked on Fix announce/publish rejecting uppercase owner names mpak#41 merging. Will need a re-announce or patch release after that lands.

Issues filed during this build

• CONVENTIONS.md name regex rejects valid mixed-case owners contributor-toolkit#37 — CONVENTIONS.md name regex rejects valid mixed-case owners
• SKILL_FORMAT.md incorrectly states embedded skills have no frontmatter contributor-toolkit#38 — SKILL_FORMAT.md incorrectly states embedded skills have no frontmatter