This release is a pre-release and may not be stable for production use.
mcp-gee-sweet
A Google Workspace MCP server built for depth.
mcp-gee-sweet gives AI clients deep, direct access to Google Sheets, Docs, Drive, Calendar, and Gmail. It reads raw formulas like =VLOOKUP(), builds Docs structurally (colspan/rowspan tables, themes, named styles, an HTML/Markdown→AST→Docs pipeline), and covers Drive files, sharing, and sync alongside Calendar events and Gmail messages, threads, and drafts.
A few highlights:
- Caching — repeated reads return in ~2ms from a local cache instead of a round-trip API call every time.
- Formula access — reads raw
=VLOOKUP(),=SUM(), and=IF()expressions, not just the values they produce. - Local sync — two-way sync between a local folder and Google Drive.
Install (stable):
uvx mcp-gee-sweet
Install (bleeding edge — every code change on develop):
uvx --prerelease=allow mcp-gee-sweet
What's covered
| Service | Tools | Highlights |
|---|---|---|
| Google Sheets | 36 | Formula access, batch read/write, 8 chart types, structural ops |
| Google Drive | 38 | File ops, sharing/permissions, local sync, revision history |
| Google Docs | 34 | Full HTML→Doc pipeline, tables, range styling, themes, Markdown export |
| Google Calendar | 17 | Event CRUD, free-slot finder across multiple calendars |
| Gmail | 15 | Search and read messages and threads, send and reply, drafts you can review, edit, or discard before sending, labels (OAuth only) |
Quick start
Option A: uv — local use and development
If you cloned the repo or just want to use the server from your machine, uv is all you need. No Docker required.
git clone https://github.com/khuisman/mcp-gee-sweet.git
cd mcp-gee-sweet
uv sync
Then point your MCP client at it using stdio transport (see MCP client config below). The client spawns the server as a subprocess on demand — each session gets its own isolated process, so restarting the server for a code change or config update doesn't affect other open sessions.
Option B: Docker — persistent shared server (SSE)
Use Docker when you want a single long-running server that multiple clients connect to over SSE — for example, Claude Desktop talking to the same instance as Claude Code.
git clone https://github.com/khuisman/mcp-gee-sweet.git
cd mcp-gee-sweet
echo "MCP_SERVER_TOKEN=$(python3 -c 'import secrets; print(secrets.token_urlsafe(32))')" >> .env
make build # build the container image
make start # start the server (SSE on port 47000)
make logs # tail logs
Point your MCP client at http://localhost:47000/sse, sending the token from .env as an Authorization: Bearer <token> header (see the SSE config below). The server rejects any request without it. Without Docker, --transport sse and --transport streamable-http listen on 127.0.0.1 only, and need MCP_SERVER_TOKEN to serve on any other address; see HTTP transport authentication.
Note: when using SSE, all clients share one server process. After a code change or restart (
make restart), you must also restart each MCP client to reconnect.
Configuration
The server tries auth methods in a waterfall by default, OAuth first — it authenticates as you and has full personal Drive access, which is what local/dev use (Option A above) needs. For OAuth, download an OAuth Client ID JSON from GCP Console and point the server at it:
export CREDENTIALS_PATH="/path/to/credentials.json"
export TOKEN_PATH="/path/to/token.json"
mcp-gee-sweet auth # one-time browser login; `uvx mcp-gee-sweet auth` for a PyPI install
Pass the same CREDENTIALS_PATH and TOKEN_PATH in your MCP client's env. A stdio server with no token doesn't open a browser itself. Instead its first tool call offers you the Google consent link (or you run mcp-gee-sweet auth), and you retry the call. A token revoked mid-session is handled the same way, with no restart.
Service accounts (recommended for headless server deployments, see Option B above), base64 credential injection, and Application Default Credentials are also supported. Gmail tools need OAuth. See Authentication for all options.
MCP client config
Claude Desktop — stdio (cloned repo):
{
"mcpServers": {
"mcp-gee-sweet": {
"command": "uv",
"args": ["run", "--directory", "/path/to/mcp-gee-sweet", "mcp-gee-sweet"],
"env": {
"CREDENTIALS_PATH": "/path/to/credentials.json",
"TOKEN_PATH": "/path/to/token.json"
}
}
}
}
Claude Desktop — SSE (Docker):
{
"mcpServers": {
"mcp-gee-sweet": {
"transport": "sse",
"url": "http://localhost:47000/sse",
"headers": {
"Authorization": "Bearer <token>"
}
}
}
}
See Client Setup for more options including tool filtering.
Using a client with a tool limit
Some MCP clients cap how many tools they accept, and with every tool registered this server is over each cap:
| Client | Limit |
|---|---|
| VS Code + GitHub Copilot (agent mode) | 128 tools per request, built-in tools included. Over it, every request fails with "Cannot have more than 128 tools per request" |
| Windsurf | 100 tools in total, across all servers |
| Cursor | Depends on the model ("Too many MCP tools are enabled for this mode") |
| Google Antigravity | 100 tools per server (user report) |
On these clients, set ENABLED_TOOLS in the server's env to one of the suggested subsets, each under 100 tools, e.g. all Docs tools, or Docs + Drive combined. Clients with a tool limit has a ready-to-paste config for VS Code, Cursor, and Windsurf.
Docs
- Tools — full tool reference, grouped by domain
- Authentication — all four auth methods
- Configuration — env vars, caching, tool filtering
- Client Setup — MCP client config examples
- Design Principles — tool inclusion policy, composite tool decisions
- Roadmap — planned features and known gaps
Contributing
See CONTRIBUTING.md for setup, QA workflows, and PR guidelines. A signed-off docs/qa/runs/vX.Y.Z.md record is required before any stable PyPI release — see docs/qa/README.md for the QA workflow.
License
MIT — see LICENSE.
Credits
- xing5/mcp-google-sheets — upstream this project was forked from
- FastMCP
- freema/mcp-gsheets and piotr-agier/google-drive-mcp — roadmap inspiration
1 maintainer
Metadata
1 maintainer
Release files for mcp-gee-sweet 0.9.6.dev73
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| mcp_gee_sweet-0.9.6.dev73.tar.gz | 3.5 MB | With provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| mcp_gee_sweet-0.9.6.dev73-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 3.8 MB
Release files / mcp_gee_sweet-0.9.6.dev73.tar.gz
| Download URL | mcp_gee_sweet-0.9.6.dev73.tar.gz |
|---|---|
| Size | 3.5 MB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
4790636898507a5f42c78059d1f35a0265c5692223779b18e748e288d002a3a0
|
|
BLAKE2b-256 checksum How to use checksums |
12e745574bec9386dcf848db6a11b2f782f8e640f363659bfb740653ea3ca818
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 26, 2026.
Transparency logRelease files / mcp_gee_sweet-0.9.6.dev73-py3-none-any.whl
| Download URL | mcp_gee_sweet-0.9.6.dev73-py3-none-any.whl |
|---|---|
| Size | 363.4 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
c16f05e691ee52e8cde2ba4dfae36a4b5258de49052a111994a880b59256fc07
|
|
BLAKE2b-256 checksum How to use checksums |
e08489b233f79b35608b831a7057d1cf6ccde6fb20c2e3104eb22497f629aafb
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 26, 2026.
Transparency logSecurity for mcp-gee-sweet 0.9.6.dev73
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for mcp_gee_sweet-0.9.6.dev73.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 26, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.
