MCP Tooling & Tool-Boundary Design

Summary

A collection of Model Context Protocol (MCP) servers and automations that let AI assistants reach real tools through scoped, well-bounded interfaces — GitLab merge-request comments, Google Workspace, meeting-note sync, calendar, and text-to-speech — plus opinions, learned the hard way, about which tasks should and shouldn’t be handed to an agent.

The problem

An AI assistant is only as useful as the tools it can safely touch. Off-the-shelf integrations are inconsistent: uneven auth, over-broad scopes, and boundaries that don’t match how you actually work.

Why it mattered

Tool access is the difference between an assistant that talks about your work and one that can act on it. Getting the boundaries right — scope, error handling, human checkpoints — is what makes that safe rather than reckless.

What I built (and what I adapted)

Being precise about provenance:

• Original — gitlab-mcp (retrieve MR comments), mcp-gsuite-personal, notion-meeting-notes-sync (Krisp → Drive → Notion pipeline), and claude-code-tts (local Kokoro TTS for Claude Code).
• Adapted forks — Granola, Google Calendar, and G Suite MCP servers tailored to my setup. These are forks, credited as such, not presented as original work.

Role

Author of the original servers above; adapter and maintainer of the forks. Designed the tool boundaries and the meeting-note automation pipeline.

Architecture

Each server exposes a narrow, purpose-built surface over one system rather than a generic passthrough. The meeting-note flow chains Krisp → Zapier → Google Drive → Notion so transcripts are captured, stored, and summarized without manual steps. Auth is kept scoped per integration.

Key decisions

• Narrow tools over generic wrappers — smaller surface, clearer failure modes, easier to reason about what the agent can do.
• Automate capture, keep judgment human — the pipeline moves and summarizes notes; decisions about them stay with me.
• Credit forks honestly — adapted work is labeled as adapted.

Tradeoffs

• Purpose-built servers mean more small repos to maintain vs. one large integration.
• Scoped auth is more setup up front, less blast radius later.

Failure modes considered

• Over-broad tool access → constrained by narrow, single-purpose servers.
• Silent automation errors → the note pipeline favors visible, checkable steps.

Outcome

A working personal tool layer that lets assistants act on real systems, and a clear line — captured in the meeting-note article — between what’s worth automating and what isn’t.

What I learned

The hard part of agent tooling isn’t wiring an API; it’s deciding the boundary — scope, error handling, and where a human stays in the loop.

What I’d change next

Consolidate the original servers under a single documented tool-boundary pattern others can build against.