Runs on your machine from its package; the steps are below.
At most: creates or changes data: records, files, settings.
Odel charges nothing per call. The publisher may charge for its own service.
Runs locally over stdio
This server isn't hosted — your MCP client launches it from a package registry. Use one of the commands below, or drop the config into your client (e.g. Claude Desktop).
Run
uvx mcp-gee-sweet
MCP client config
{
"mcpServers": {
"gee-sweet": {
"command": "uvx",
"args": [
"mcp-gee-sweet"
]
}
}
}
mcp-gee-sweet
The Google Workspace MCP server built for depth.
Google ships its own Sheets and Docs MCP servers now (Developer Preview), but they're shallow — thin CRUD, both approval-gated. mcp-gee-sweet goes deeper: raw formula access — reads =VLOOKUP() and friends directly, structural Docs support (colspan/rowspan tables, themes, named styles, an HTML/Markdown→AST→Docs pipeline), plus complete Drive and Calendar coverage Google's preview doesn't touch at all.
A few things no other Workspace MCP has:
=VLOOKUP(), =SUM(), and =IF() expressions, not just the values they produce.Install (stable):
uvx mcp-gee-sweet
Install (bleeding edge — every code change on develop):
uvx --prerelease=allow mcp-gee-sweet
| Service | Tools | Google's own MCP | Highlights |
|---|---|---|---|
| Google Sheets | 35 | 6 | Formula access, batch read/write, 8 chart types, structural ops |
| Google Drive | 38 | — | File ops, sharing/permissions, local sync, revision history |
| Google Docs | 34 | 2 | Full HTML→Doc pipeline, tables, range styling, themes, Markdown export |
| Google Calendar | 17 | — | Event CRUD, free-slot finder across multiple calendars |
uv — local use and developmentIf 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.
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
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.
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.
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; its tools return an error telling you to run mcp-gee-sweet auth.
Service accounts (recommended for headless server deployments — see Option B above), base64 credential injection, and Application Default Credentials are also supported. See Authentication for all options.
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"
}
}
}
See Client Setup for more options including tool filtering.
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.
MIT — see LICENSE.