Vexa
Meeting bot and transcripts for Google Meet, Teams and Zoom. Live or after, speakers labelled.
Beschreibung vom Entwickler (englisches Original)
Multi-account Gmail on a Cloudflare Worker you deploy yourself: read, send, reply, labels, threads
Diese drei werden nie zu einer Punktzahl zusammengefasst: Meinungen, Messungen und Beliebtheit sind verschiedene Dinge.
Für diesen Server haben wir noch keine Zusammenfassung in einfacher Sprache geschrieben. Unten stehen die Fakten, die wir aus der Registry gelesen haben.
Wähle die KI-App, die du nutzt, und kopiere die Einstellungen.
Der Entwickler hat in der Registry keine Installationsangaben gemacht. Sieh dir unten die README des Entwicklers an.
Läuft auf deinem Computer; die Tool-Liste erscheint nach der Installation in deiner KI-App.
Wir prüfen Informationen, die jeder sehen kann; den Code haben wir nicht gelesen. Checks, die nicht zutreffen, werden nicht mitgezählt. · Geprüft am 6. Nov. 2026
Der Registry-Name wurde mit dem GitHub-Konto mkpoli bestätigt, dem das Repo gehört
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieser Server läuft auf deinem Computer; es gibt keinen Endpunkt im Internet
Läuft auf deinem Computer und nutzt stattdessen lokale Einstellungen
Läuft auf deinem Computer; Tool-Listen können wir nur von Endpunkten im Internet lesen
Verglichen mit allen aktiven Servern dieser Kategorie in der Registry. Sterne zählen nur, wenn dem Herausgeber das Repo gehört.
Er hat 1 von 1 zutreffenden Basischecks bestanden. Den Code haben wir nicht gelesen. Bevor du einen Schlüssel oder Token hinzufügst, sieh nach, welche Zugriffe der Server verlangt, und nutze einen Schlüssel, der nur die Berechtigungen hat, die du brauchst.
Die Registry nennt keinen erforderlichen Schlüssel, manche Server bitten dich aber bei der ersten Nutzung, dich anzumelden.
Er läuft auf deinem Computer. Deine KI-App startet ihn bei Bedarf, und die Daten laufen nicht über die Server des Entwicklers (außer der Server ruft selbst einen Onlinedienst auf).
Das GitHub-Repo wurde zuletzt – geändert, und die neueste Version (0.3.0) kam vor 20 Tagen in die Registry.
Apps, die MCP unterstützen, etwa Claude Desktop, Claude Code, Cursor und VS Code.
In derselben Kategorie: Vexa, emailmd, MCP WhatsApp Cloud
Server derselben Kategorie von anderen Entwicklern, sortiert nach Sternen.
So liest du eine Karte:★ GitHub-SterneiDrei Säulen: Bewertungen · Checks · NutzungiAktualisiert = neueste Version in der Registry veröffentlichti
Meeting bot and transcripts for Google Meet, Teams and Zoom. Live or after, speakers labelled.
Render markdown into email-safe HTML, lint drafts for deliverability problems, and preview emails.
MCP server for WhatsApp Cloud API (Meta) — messages, media, and templates via Graph API
Unverändert aus dem Repo des Entwicklers übernommen. PopNx MCP hat den Inhalt weder geprüft noch empfiehlt es ihn. HTML, Bilder und Skripte wurden entfernt. Links führen von dieser Website weg.
Gmail for your AI assistant — several accounts at once, on a server you own.
*日本語版 · 简体中文*
gmail-mcp connects Gmail to Claude and any other MCP client. It can search and read mail, send and reply-all with quoted history, forward, handle attachments and inline images, and manage drafts, labels, and threads — across several Google accounts at the same time.
It runs as a remote server on your own Cloudflare Worker, so the same connection answers from Claude Code on a laptop, claude.ai in a browser, and Claude on a phone. Each connection signs in to one Google account, and the Google refresh token stays in your Cloudflare account.
Two things push people here. The Gmail connectors built into Claude and Google read mail and write drafts, but cannot send, and hold one Google account per assistant account. Servers that can send are usually local processes — fine at a desk, invisible from a phone.
A longer comparison — six projects, twelve rows
| | gmail-mcp | Claude · Google built-in | taylorwilsdon/ google_workspace_mcp | ArtyMcLabin/ Gmail-MCP-Server | shinzo-labs/ gmail-mcp | aaronsb/ google-workspace-mcp | | :-- | :-: | :-: | :-: | :-: | :-: | :-: | | Where it runs | Cloudflare Workers | vendor-hosted | your server or local | local | local | local | | Reachable from a phone | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | | Several mailboxes at once | ✅ bound per connection | ❌ | ✅ chosen per call | ❌ aliases only | ❌ | ✅ chosen per call | | Send mail | ✅ | ❌ | ✅ | ✅ | ✅ | ✅ | | Attachments · inline cid: images | ✅ | undocumented | ✅ | ✅ | ❌ | ✅ | | Reply-all with quoted history | ✅ | ❌ | drafts only | no quoting | ❌ | ✅ | | Forward | ✅ | ❌ | ✅ | ❌ | ❌ | ✅ | | Honors each part's charset | ✅ | — | ❌ UTF-8 assumed | ❌ UTF-8 assumed | ❌ | ❌ | | Rejects CRLF header injection | ✅ | — | ✅ framework | ✅ strips | ❌ none | ✅ | | Mailbox settings (filters, vacation) | ❌ out of scope | ❌ | filters | filters | ✅ | ❌ | | Tool count | 24 | 11–16 | 14 (Gmail) | 30 | 64 | 11 | | Who holds your refresh token | you | vendor | you | you | you | you |
google_workspace_mcp is the most complete project here. It covers all of Workspace rather than Gmail alone, and it appends your Gmail signature and pulls attachments straight from a URL, neither of which gmail-mcp does. shinzo-labs/gmail-mcp reaches vacation responders, delegates, and S/MIME through its 64 tools; those live under gmail.settings.*, a scope gmail-mcp never requests, so they stay beyond its reach whatever happens to a grant.
Two design differences decide most of the rest. Routing accounts by a call argument lets one grant touch every connected mailbox, while binding the mailbox to the connection means a wrong argument reaches nothing. And on reading, the local servers decode every part as UTF-8: ISO-2022-JP and Shift_JIS mail arrives garbled, and long messages that Gmail stores as attachment blobs come back with an empty body.
About ten minutes. You need a Cloudflare account, bun, and a Google account. A domain on the Cloudflare account is optional — without one the Worker answers on workers.dev.
PROJECT="gmail-mcp-$(openssl rand -hex 3)"
gcloud auth login gcloud projects create "$PROJECT" --name="gmail-mcp" gcloud config set project "$PROJECT" gcloud services enable gmail.googleapis.com
Google exposes no API for the next two steps, so they happen in the Cloud console:
https:// /callback as an authorized redirect URI. Keep the client ID and secret. is the domain you point at the Worker, or the workers.dev hostname it gets otherwise. Deploying first and coming back to fill this in works — the guide the Worker serves at / shows the exact value.
The button copies the repository into your GitHub account, creates the KV namespace and the Durable Object, and asks for the four secrets. It deploys to workers.dev; a custom domain is attached afterwards under Settings → Domains & Routes.
From a terminal instead:
git clone https://github.com/mkpoli/gmail-mcp && cd gmail-mcp
bun install bun run setup
bun run setup asks which domain to answer on, creates or reuses the OAUTH_KV namespace, takes the client ID and secret, generates a cookie key, and deploys. Those first two answers land in wrangler.local.jsonc, which git ignores — wrangler.jsonc names no account's namespace and no one's domain, so a clone deploys anywhere. Re-running setup to rotate a single secret is safe.
Leave the client ID and secret fields empty — MCP clients register themselves.
claude mcp add --transport http gmail-personal https://<your-host>/mcp
claude mcp add --transport http gmail-work https:// /mcp/work
Run /mcp in Claude Code to sign each connection in to its Google account. In claude.ai it is Settings → Connectors → Add custom connector with the same URL. Any single-segment label works after /mcp/, which is how one deployment serves several mailboxes to clients that reject two servers sharing a URL.
Your deployment serves this guide at https:// /.
📖 Read ✍️ Write 🏷 Organize
whoami
search_messages
get_message
get_thread
get_attachment
send_message
reply_all
forward_message
create_draft
update_draft
send_draft
delete_draft
list_drafts
stage_attachment_begin
stage_attachment_append
stage_attachment_finish
list_labels
create_label
update_label
delete_label
modify_labels
modify_thread_labels
batch_modify_messages
trash_message · untrash_message
trash_thread · untrash_thread
Messages leave the way a mail client sends them: plain text with an HTML alternative, file attachments, and inline images referenced by cid:, nested as multipart/mixed › multipart/related › multipart/alternative. Subjects and display names use RFC 2047, filenames use RFC 2231, so Japanese, Chinese, and emoji survive the trip.
reply_all reads the original's Reply-To, From, To, and Cc, drops your own address and any address you send mail as, answers from the one the sender wrote to, carries the References chain, and quotes the original in whichever parts you send. forward_message reproduces the forwarded envelope and can re-attach the original's files; when they cannot all go, nothing is sent.
create_draft with replyToMessageId writes the reply as a draft to edit before sending: it joins the original's thread, carries In-Reply-To and References, derives the reply-all recipients and the Re: subject, and quotes the original. update_draft changes only the fields it is given; recipients, text, files added by hand in any client, and the thread the draft answers are read back and kept. A file whose base64 will not fit through tool arguments is staged instead: stage_attachment_begin returns an upload URL that takes the raw bytes in one curl -T, stage_attachment_append takes base64 in chunks, and every attachments field accepts the resulting stagingId.
Reading is bounded on purpose: message and thread bodies have character budgets, a whole response has a byte ceiling, and an attachment is returned inline only while it stays small enough to read. A long mailing-list thread comes back trimmed with a note saying so rather than filling the assistant's context. A larger file comes back as a download link that works for an hour while the session stays open, and curl -o saves it to disk without its bytes passing through the conversation.
Two OAuth flows meet in one Worker. The MCP client authenticates *to* the Worker; the Worker authenticates *to* Google on your behalf. Neither side holds the other's credentials.
sequenceDiagram
autonumber participant C as MCP client (Claude Code · claude.ai) participant W as Worker (OAuthProvider + McpAgent) participant G as Google (OAuth + Gmail API)
C->>W: POST /register (dynamic client registration) C->>W: GET /authorize (PKCE challenge) W->>C: approval dialog C->>G: consent screen — pick the account G->>W: GET /callback?code=… W->>W: allowlist check on the verified email W->>G: exchange code → access + refresh token W->>C: MCP access token (Google tokens sealed inside the grant) C->>W: POST /mcp — tools/call W->>G: Gmail REST (token refreshed as needed) G->>W: message / thread / label data W->>C: tool result
| Layer | File | What it does |
|---|
| 🔐 MCP-side OAuth | [workers-oauth-provider](https:
Nur der Anfang wird gezeigt; den Rest findest du im Repo