mcp-gog-bridge

# 🌉 mcp-gog-bridge **A Google Workspace MCP server built for the reply, not the inbox.** Reading your mail from Claude is the easy part. The afternoon goes on what comes after it: the answer that has to leave from the work address, and the meeting that has to move to Friday. Every connector stops at the read and hands the rest back to you, in a browser tab, with the draft on the clipboard. Two tools, the whole [gog](https://github.com/openclaw/gogcli) command line behind them, and a policy that decides what may not pass. ## 🧱 The problem You ask Claude to answer Marc. It has read the thread, it has written the reply, and now it needs something that can send. On a Windows machine the candidates are three, and none of them does it. Claude Cowork runs its shell commands inside a Linux VM, so the `gog.exe` sitting in your user profile is out of reach: the VM has no Windows binary, no Credential Manager and no path to either. gog ships its own MCP server, `gog mcp`, and it is deliberately narrow: measured on v0.40.0 it exposes 8 tools by default, all reads, and 10 with `--allow-write`, which adds a Docs write and a Sheets range update. Nothing in it sends a mail, creates an event or shares a file. Anthropic's own Google connectors search and read the mailbox and the calendar, and the write you need is not there either. So the draft goes into Gmail by hand, and the model that did the thinking watches you do the clicking. This server takes the other route. Claude Desktop starts it on the host, from `claude_desktop_config.json`, next to `gog.exe` and the signed-in accounts, and both Cowork and the Chat tab reach it. `gog_run` hands the model the whole command line. What a raw shell would let through, the policy stops: the model picks an account from the aliases you configured and nothing in its arguments can name another, and the commands that administer gog itself, `auth` first among them, never run. ## 📦 Install ```bash uvx mcp-gog-bridge --version ``` That…