Skip to main content
Pre-release

This release is a pre-release and may not be stable for production use.

mcp-gee-sweet logo

mcp-gee-sweet

A Google Workspace MCP server built for depth.

GitHub License

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

Full documentation →


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). By default nothing is sent until the user confirms it; a client that can't ask leaves the email as a draft. See Gmail sending

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 — one-click bundle: download mcp-gee-sweet-<version>.mcpb from the latest GitHub Release and open it in Claude Desktop. It asks for your OAuth client file and needs no config editing (details).

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


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

Metadata

Release files for mcp-gee-sweet 0.9.6.dev144

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for mcp-gee-sweet 0.9.6.dev144
File Size Uploaded Provenance Actions
mcp_gee_sweet-0.9.6.dev144.tar.gz 3.7 MB With provenance Details for mcp_gee_sweet-0.9.6.dev144.tar.gz

Built distribution (wheel)

Table of built distributions (wheels) for mcp-gee-sweet 0.9.6.dev144
File Interpreter ABI Platform Actions
mcp_gee_sweet-0.9.6.dev144-py3-none-any.whl Python 3 none any Details for mcp_gee_sweet-0.9.6.dev144-py3-none-any.whl

Total release size: 4.1 MB

Release files / mcp_gee_sweet-0.9.6.dev144.tar.gz

Download URL mcp_gee_sweet-0.9.6.dev144.tar.gz
Size 3.7 MB
Tags Source
SHA-256 checksum
How to use checksums
3485604228b2f2e2755a38840ab553d7d7968045303c725eb272fc9bde53cc96
BLAKE2b-256 checksum
How to use checksums
2ce8cd3f4e4a2b628d4d3c0e1bbfee1c09b62ec025f07dc246f0506c66b58bbb
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 Nov 1, 2026.

Transparency log

Release files / mcp_gee_sweet-0.9.6.dev144-py3-none-any.whl

Download URL mcp_gee_sweet-0.9.6.dev144-py3-none-any.whl
Size 415.6 kB
Tags Python 3
SHA-256 checksum
How to use checksums
5fe33d1451cf81e396e31bb3c52c639bf184e6799036e3fc4ffa4fd597097169
BLAKE2b-256 checksum
How to use checksums
c9903245942b61619ea7d06278116e1f02104f3bddec6377956fb1ad383304c4
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 Nov 1, 2026.

Transparency log

Security for mcp-gee-sweet 0.9.6.dev144

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.

Select from 2 files

Attestation for mcp_gee_sweet-0.9.6.dev144.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 Nov 1, 2026.

Transparency log

A 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.

Release history Release notifications | RSS feed

This release
Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page