Building a Multi-Tenant Google Workspace MCP Server

When building AI agents, connecting them to user data is usually the hardest part. The Model Context Protocol (MCP) solves a lot of this by providing a standard interface for tools. But I ran into a wall when trying to use it for a multi-tenant application.

Most open source MCP servers are built for local desktop clients. They assume a single user and read authentication tokens from local environment variables. That works fine if you are building a personal assistant on your own laptop. It fails completely if you are building a backend service like a Telegram bot that needs to handle requests from thousands of random users simultaneously.

I needed to build a comprehensive Google Workspace integration covering Drive, Gmail, Calendar, Tasks, Docs, and Sheets. I wanted it to be a standalone MCP server.

The initial thought was to wire the MCP server directly to my application's PostgreSQL database. The tool handlers would accept a user ID parameter, query the database for the correct Google OAuth tokens, and execute the request.

That approach technically works but it ruins the architecture. The entire point of MCP is to decouple tools from application logic. If an MCP server has to know about your specific database schema, it is no longer a reusable microservice. You might as well just write the API calls directly in your main backend code.

I needed a way to keep the server completely stateless while passing user specific authentication context on every request.

Architecture

The solution was Connection Level Auth via HTTP.

Instead of running the MCP server over standard input and output, I configured it to run as a centralized HTTP service. When the agent application receives a message from a user, it pulls their OAuth tokens from its own database and injects them into the HTTP headers of the MCP tool call.

The server intercepts these headers before executing the tool. It extracts the access token and builds a lightweight, ephemeral Google API client scoped strictly to that single request. When the request finishes, the ephemeral client is discarded.

If a request comes in without token headers, the server falls back to its local development configuration. This means the exact same codebase works perfectly for local desktop clients and high throughput production environments.

The result is a clean microservice with 45 different Google Workspace actions that knows absolutely nothing about the users calling it.