Most Google Docs servers are one person's local process holding one refresh token. This is built the other way round: users sign in through your deployment, refresh tokens are encrypted in Postgres, and access is isolated per user — so a team can share one endpoint. That buys real infrastructure cost, a Postgres and a Redis before the first document is read, which is the right trade only if more than one person is using it.
A Next.js application that runs as a remote MCP server for Google Docs, deployed on Vercel and reached over SSE. It handles Google OAuth for you, stores per-user tokens, and supports several users against one deployment with isolated access. Authorisation happens on demand from inside the assistant rather than as a setup step.
- `authorize_google` starts the OAuth flow and returns a link — run it first
- `read_document` reads the content of a Google Doc
- `create_document` makes a new one
- `update_document` applies batch edits to an existing document
- `append_text` adds text to the end of a document
- `list_documents` lists the documents you have access to
- A web dashboard for issuing API keys when you want programmatic access instead
You host it. A Google Cloud project with the Docs and Drive APIs enabled and an OAuth 2.0 web client, a PostgreSQL database, a Redis instance for the Vercel MCP adapter, and a Vercel deployment carrying `NEXTAUTH_SECRET`, `NEXTAUTH_URL`, `GOOGLE_CLIENT_ID`, `GOOGLE_CLIENT_SECRET`, `DATABASE_URL` and `REDIS_URL`. Run `pnpm db:push` after deploying. Clients connect with `claude mcp add --transport sse` to your `/sse` endpoint; an `X-API-Key` header is the alternative to browser sign-in.
One command plus a key — claude mcp add --transport sse google-docs https://your-app.vercel.app/sse, then supply credentials