Google ships 35+ official MCP servers. Exactly zero of them can autonomously send a message to someone outside a Google domain.

Not for arbitrary recipients. The official catalog covers BigQuery, Cloud SQL, AlloyDB, Spanner, Firestore, Bigtable, GCE, GKE, Cloud Run, Cloud Storage, Pub/Sub, Logging, Monitoring, Maps, and Workspace (Drive, Calendar, Chat, People, Gmail). The only servers in that list whose surface includes a tool that puts text in front of a person are Gmail (create_draft, plus label/thread management) and Calendar (create_event, which can email a non-Google guest as a side effect). There is no SMS MCP, no Voice MCP, no consumer-messenger MCP. If your customer is on WhatsApp and not actively reading email, no published Google MCP server can deliver to them.

Per the published Workspace MCP configuration page (developers.google.com/workspace/guides/configure-mcp-servers), Chat ships exactly two tools: search_conversations and list_messages. There is no create_message, no post_to_space, no send. The Chat REST API supports those operations, but they are not yet exposed through the MCP layer. So an agent that wants to post into a Google Chat space has to use the REST API directly with a service account; it cannot do it through the published Chat MCP.

Two reasons. First, create_draft saves a message to the user's drafts folder; it does not send. The user (or another tool) still has to issue the send. The MCP surface as published does not include send_message, only the draft create plus label/search/thread plumbing. Second, Gmail is not where most of the customer base for a Brazilian gym, an Indian tutor, or an Egyptian e-commerce shop actually reads anything. Even if the agent could send autonomously, the recipient would not see the email for hours or days. The empty cell on the catalog table is real.

Identically to any other MCP child. The host (Claude Code, Cursor, Claude Desktop) reads a config that names servers and how to launch them; remote Google servers are HTTP entries with OAuth, the local WhatsApp server is a stdio entry that runs the whatsapp-mcp binary. The host forks the stdio child, opens HTTP connections to the remote ones, and presents the union of all tool surfaces to the agent. The agent then chains create_draft (Gmail) plus whatsapp_search plus whatsapp_send_message in a single turn.

After whatsapp_send_message presses Return, the WhatsApp MCP child sleeps 1.0 second and re-traverses the WhatsApp app's accessibility tree (Sources/WhatsAppMCP/main.swift, line 924). It collects every AXGenericElement, looks for one whose description begins with the literal string 'Your message, ', strips the timestamp suffix with a regex, and compares the resulting text against what the agent asked to send. If it matches, the JSON response carries verified:true. If not, the response still carries success:true (because Cmd+V plus Return was issued) but flips verified to false and includes the last bubble it found in a warning field. This is observation of the rendered chat, not a delivery webhook.

No server, no proxy, no glue service. The MCP host is the only integrator. You add the WhatsApp entry to the same JSON file that already lists your Google entries, restart the host, and the agent sees both tool surfaces at once. The cross-server chain (call Gmail, then call WhatsApp) is just two tool calls in the same turn from the agent's perspective. The state shared between them is whatever the agent puts into the prompt, not anything the servers know about each other.

Remote. Each Google MCP server is hosted at a googleapis.com endpoint and authenticated via OAuth 2.0. Configuration differs slightly by client: Gemini CLI uses Desktop-app OAuth credentials in settings.json; Claude needs Web-application credentials with redirect URI https://claude.ai/api/mcp/auth_callback; other clients need HTTP transport with OAuth 2.0 support. To use Google's remote MCP servers from Claude.ai or Claude Desktop, you need an Enterprise, Pro, Max, or Team plan. WhatsApp MCP imposes none of this; it is local stdio with macOS Accessibility as the only gate.

Yes, that is the entire point of the host model. A single tools/list call returns the union of every server's tool surface; the host routes each tools/call to the child that owns the named tool. From the agent's perspective there is no boundary between the Google half and the WhatsApp half, just a longer list of tools. The trade-off is that two of the children speak HTTP+OAuth to googleapis.com and one speaks stdio to a local Swift process, but the host abstracts that.

Pub/Sub is machine-to-machine. It moves bytes between services. There is no human reader on the other end of a Pub/Sub topic unless you build the consumer side (a worker that reads the topic and pushes to email, push, or chat). The published Pub/Sub MCP exposes topic CRUD and publish, but the consumer of those messages has to be wired separately. For a real human-to-human notification you want either Gmail (if email is the channel) or a non-Google MCP that talks to the actual chat surface the human uses.

Yes. WhatsApp MCP runs standalone with a single config entry and grants you 11 tools (search, open, send, read, list, navigate, scroll, status, start, quit, get_active_chat). For a flow that is purely WhatsApp-side (replies, follow-ups, reminders), the Google half is not needed. The pairing only matters when the agent is doing some Google-side reasoning (parsing email threads, scheduling on a calendar, looking up Drive files) and then needs to surface the result to a human who lives on WhatsApp.

Possibly. The published Google MCP catalog is growing fast (Cloud Run, Cloud Storage, Resource Manager, Pub/Sub, Dataplex were all listed as in flight as of early 2026). Workspace's Chat MCP could plausibly add a send_message in a future release, which would close the in-Workspace loop, though it still would not reach a non-Google user. Gmail could plausibly add an autonomous send_message, which would close the email-side loop. Neither of those would extend Google's MCP into WhatsApp, SMS, iMessage, Telegram, or any consumer surface outside Google's perimeter. That cell stays empty until either Google or a third party publishes a server for the corresponding app. WhatsApp MCP for macOS is the third-party answer for one of those cells.