MCP Integration Portfolio — Lucas Draney
Overview
I build production MCP servers connecting Claude to internal tools — not tutorials, not proofs of concept. This page is a guided tour of live work, architecture, and methodology. Everything here is running on self-hosted infrastructure I maintain.
Production MCP Servers
Seven MCP servers in production, each following the same repeatable integration architecture:
| Server | Integrates | Pattern | Status |
|---|---|---|---|
| <strong>pal-e-docs-mcp</strong> | Knowledge platform API (500+ notes, semantic search, project management) | SDK → MCP stdio | Production |
| <strong>forgejo-mcp</strong> | Self-hosted Git platform (Forgejo) — issues, PRs, repos, labels | SDK → MCP stdio | Production |
| <strong>woodpecker-mcp</strong> | CI/CD pipeline (Woodpecker) — 117 SDK endpoints | SDK → MCP stdio | Production |
| <strong>gmail-mcp</strong> | Email (Gmail API) — send, read, draft | MCP Remote HTTP | Production |
| <strong>gcal-mcp</strong> | Calendar (Google Calendar API) — events, scheduling | MCP Remote HTTP | Production |
| <strong>linkedin-mcp-scheduler</strong> | Social media publishing — scheduled posts with SQLite queue | MCP Remote HTTP | Production |
| <strong>notion-mcp</strong> | External knowledge base (Notion API) | MCP Remote HTTP | Production |
Integration Architecture: The Triplet Pattern
Every integration follows the same three-layer architecture. This is the repeatable pattern — new systems plug in without reinventing the wheel:
- SDK — Typed Python client for the service API. Published to PyPI (private registry). Full type hints, error handling, retry logic. This is the foundation — everything else builds on it.
- MCP Server (stdio) — MCP server wrapping the SDK for local Claude Code use. Agents get structured tool access to the service. Runs as a subprocess alongside Claude.
- MCP Remote (HTTP) — Streamable HTTP connector for Claude.ai and remote clients. OAuth-secured, deployed to k8s. This is the production-grade access layer.
This pattern means ramping on a new system is predictable: write the SDK, wrap it in MCP tools, deploy. The architecture is documented in detail: Integration Triplet Pattern.
Agentic Workflow
MCP servers are infrastructure. What matters is the operating model built on top of them. I run a 5-agent system where each agent has scoped MCP access and clear responsibilities:
- Betty Sue (Coordinator) — Plans work, dispatches agents, manages documentation. Uses pal-e-docs-mcp, forgejo-mcp, woodpecker-mcp.
- Dev (Developer) — Writes all code across frontend, backend, and infrastructure. Uses forgejo-mcp for issue/PR lifecycle.
- QA (Quality) — Reviews PRs with domain-specific expertise. Catches bugs AND process violations.
- Penny (Communications) — Handles email, calendar, social, external knowledge bases. Uses gmail-mcp, gcal-mcp, linkedin-mcp-scheduler, notion-mcp.
- Dottie (Documentation) — Maintains the knowledge platform. Uses pal-e-docs-mcp for note lifecycle.
The full agent architecture, including separation of concerns and DORA metric integration, is documented here: Pal-E Agency Architecture.
Project execution is tracked via continuous kanban boards with DORA metrics (Deployment Frequency, Lead Time, Change Failure Rate, Mean Time to Recovery). The workflow SOP: Agent Workflow.
How I'd Approach Your Problem
The job description asks for MCP integrations connecting Claude to CRM, deal platforms, and data systems. Here's how my proven pattern maps to each:
- CRM Integration — SDK-first: build a typed Python client for the CRM's REST API (HubSpot, Salesforce, Pipedrive — the pattern is the same). Then wrap it in an MCP server so Claude can search contacts, update deals, log activities, and pull reports through structured tools. No prompt-stuffing, no screen scraping — clean API access with type safety.
- Deal Platforms — Same triplet pattern. OAuth for production access. MCP tools scoped to deal lifecycle: create, update status, attach documents, notify stakeholders. Each platform gets its own SDK so integrations don't couple.
- Data Systems — Webhook listeners for real-time events + MCP query tools for Claude to pull structured data. If the system has an API, it gets an SDK. If it pushes events, we catch them and surface them as tool context.
- Workflow Automation — Agent specialization. Each workflow gets a purpose-built agent with scoped MCP access — just like my current system where the communications agent only touches email/calendar tools and the developer agent only touches code/git tools. Separation of concerns prevents Claude from taking unintended actions.
Platform
Everything above — this page, the documentation, the git hosting, the CI/CD, the MCP servers — runs on self-hosted k3s with Tailscale ingress, Forgejo for git, Woodpecker CI for pipelines, and Prometheus/Grafana for observability. No vendor lock-in. Full control. This page is served by the platform.