Internal Tooling MCP Server

Confidentiality: Delivered under a consulting engagement. The client's identity, internal naming, and environment-specific identifiers have been withheld; only my own work, the general architecture, and the technologies used are described.

Overview#

A Model Context Protocol (MCP) server that securely connects AI assistants — such as Claude — to an organization's internal tooling, including GitHub, Jira, Google Drive, Slack, Harvest, Zoom, Gmail, Calendar, and Figma. It sits between AI clients and those services as a single authenticated gateway, enforcing enterprise SSO, per-user OAuth, multi-workspace routing, and full audit logging.

The Problem#

As AI assistants became part of the team's daily workflow, they needed safe, governed access to internal systems. Wiring each assistant directly to each service would be insecure, unauditable, and impossible to manage at the scope level. The MCP server centralizes that access behind one gateway where every action is authenticated, scope-checked, and logged.

My Role#

Senior Software Engineer, Delivery Lead, and Tech Lead on the engagement — owning the architecture, the security model, and delivery.

Architecture & Approach#

• MCP transport over Express with a deliberately ordered middleware stack: CORS and parsers, an auth-bypassing health check, OAuth proxy routes, bearer-token validation, per-integration OAuth route registration (each gated by a feature flag), and finally the MCP transport endpoint.
• Enterprise SSO. Non-public requests require a bearer JWT from the org's identity provider whose audience is validated; tools/call requests additionally enforce per-tool required scopes and emit an audit-log row on every response.
• OAuth proxy (the non-obvious core). MCP clients send an RFC 8707 resource parameter that the SSO provider rejects. The server advertises itself as the authorization server via discovery metadata, strips the offending parameter, forwards to the provider, and proxies the token exchange — so clients integrate against the proxy, not the provider directly.
• Per-user integration OAuth. Google, Slack, Harvest, and Zoom each use a per-user, server-side OAuth flow with encrypted refresh-token storage and signed one-time "connect" links surfaced directly through tool results, so no separate connect-first UX is needed.
• Multi-workspace registry. The server can act across multiple workspaces, resolving per-workspace credentials from a secrets store through a cached registry and defaulting to the primary workspace.

Technical Highlights#

• Security-first secrets model. A least-privilege IAM split keeps the running service read-only on the secrets store, while an explicit IAM Deny makes a shared GitHub App private key unreadable to any human identity — and because an explicit Deny always overrides any Allow, that's the load-bearing guarantee. Workspace credential CRUD requires a human with a dedicated admin policy.
• Encrypted tokens end to end. Per-user OAuth tokens are stored encrypted, with HMAC-signed state and connect-link tokens.
• Auditing & retention. All tool calls are audit-logged to PostgreSQL with a retention policy enforced by a separate scheduled Lambda; migrations run on boot and fail the process closed if they error.
• Environment-aware feature gating. Integrations are selected per environment, with production requiring two independent flag dictionaries to agree before a feature is live.
• Production deployment on ECS Fargate behind a load balancer, fully Terraform-managed, with bastion-based admin tunneling to the database.

Skills Demonstrated#

MCP and AI-tooling infrastructure, OAuth 2.0 / OIDC and identity integration, secure secrets management and least-privilege IAM design, multi-tenant architecture, and production AWS delivery — directly adjacent to the AI-platform engineering I'm focused on.