The Model Context Protocol (MCP) has become the standard interface for giving AI agents access to external services. Google has built an official suite of MCP servers, and a thriving ecosystem of community servers covers everything from productivity apps to developer infrastructure. WorkingAgents can sit in front of all of them – acting as the permission layer that decides which agents can call which tools, and logging every call.
Google’s Official MCP Servers
Google maintains several production MCP servers under github.com/google/mcp:
Google Workspace covers the full productivity stack: Gmail, Google Docs, Google Sheets, Google Slides, and Google Calendar. This is the canonical server for enterprise productivity access. Authentication uses OAuth 2.0 with Google’s standard consent flow.
MCP Toolbox for Databases exposes BigQuery, Cloud SQL, AlloyDB, Spanner, and Firestore. An agent that needs to query a data warehouse or run analytics against a Cloud SQL instance uses this server. No separate database driver is needed – the MCP interface handles connection pooling and query execution.
Google Colab MCP lets agents execute code in a live Colab notebook and retrieve results. Useful for data analysis workflows where the agent needs to run Python, inspect outputs, and iterate on a script.
gcloud MCP (googleapis/gcloud-mcp) wraps the full gcloud CLI surface – infrastructure provisioning, IAM, Cloud Run, Cloud Storage, and more. An agent with gcloud_admin permission can manage GCP resources through MCP tool calls.
Cloud Security (google/mcp-security) connects to Security Command Center and Chronicle for threat detection, finding analysis, and security event queries.
Community Workspace Servers
For teams that want more control over the Workspace integration, taylorwilsdon/google_workspace_mcp is the most feature-complete community server. It covers 12 services – Gmail, Drive, Docs, Sheets, Slides, Calendar, Chat, Forms, Tasks, Contacts, Meet, and Search – with over 100 individual tools. It supports OAuth 2.1 multi-user mode, which means different agents or users can authorize with their own Google accounts, making it a natural fit for a multi-user WorkingAgents deployment. It runs as either a local stdio subprocess or a remote HTTP server.
How WorkingAgents Integrates These Servers
WorkingAgents proxies MCP tool calls rather than implementing the tools itself. The integration pattern is straightforward:
- The external MCP server (Google Workspace, gcloud, etc.) runs as a subprocess or remote HTTP endpoint
- WorkingAgents registers the tools it exposes and assigns permission keys to each group
-
When an agent calls
gmail_send_email, WorkingAgents checks the agent’s permission set before forwarding the call - The result is returned to the agent; the call is recorded in the audit log
The agent never has direct access to the upstream server. It does not hold Google OAuth tokens – those stay in the WorkingAgents process. The agent holds a WorkingAgents bearer token that maps to a permission set.
Authentication: Two Patterns
User OAuth 2.0 is the standard pattern for personal or per-user access. Each user authorizes their own Google account through a consent screen. WorkingAgents stores the refresh token server-side and exchanges it for access tokens on each request. The agent sees only the result – never the credential.
Service Account with Domain-Wide Delegation is the enterprise pattern. A Google Workspace admin grants a service account permission to impersonate any user in the organization. WorkingAgents uses the service account key to call Google APIs on behalf of whichever user the agent is acting for. No per-user consent screens, no token refresh management.
Popular Tools Beyond Google
Google is not the only ecosystem with strong MCP coverage. WorkingAgents can proxy any compliant MCP server:
| Tool | Key Capabilities |
|---|---|
| GitHub (official) | Repos, issues, pull requests, code search, Actions workflows |
| Slack (official) | Channels, messages, threads, canvases, user search |
| Atlassian Rovo (official) | Jira issues, Confluence pages, JQL queries, worklogs |
| Notion | Pages, databases, semantic search, full CRUD |
| Linear | Issues, projects, teams, workflow automation |
| Stripe | Customers, payments, subscriptions, refunds |
| HubSpot | CRM contacts, deals, marketing campaigns |
| PostgreSQL / SQLite | Direct SQL database access |
| Puppeteer / Playwright | Browser automation and web scraping |
| Brave Search / Tavily | Real-time web search |
| AWS / Azure | Cloud infrastructure management |
| Docker | Container and image management |
What WorkingAgents Adds
Running agents directly against Google APIs or a raw MCP server creates a flat access model – the agent either has the OAuth token or it does not. WorkingAgents adds the dimension that enterprise use requires:
-
Granular permissions –
gmail_readandgmail_sendare separate grants. An agent that summarizes emails does not need send access. - Audit trail – every tool call is logged with the agent identity, timestamp, and arguments. This is not optional; it is how the system works.
- Credential isolation – Google OAuth tokens, service account keys, and API keys never leave the WorkingAgents process. Agents hold opaque bearer tokens.
- Consistent revocation – revoking a WorkingAgents permission immediately cuts off the agent’s access to all tools under that permission key. No need to rotate Google credentials.
The external MCP servers handle the “how to talk to Google” problem. WorkingAgents handles the “who is allowed to talk to Google and under what conditions” problem. The two layers compose cleanly.
Getting Started
The practical path for a WorkingAgents deployment integrating Google Workspace:
- Set up a Google Cloud project and configure OAuth credentials (or a service account for domain-wide delegation)
-
Run
taylorwilsdon/google_workspace_mcpas a local subprocess (stdio transport) or remote HTTP server -
Register the tools in WorkingAgents with appropriate permission keys (e.g.
workspace_gmail,workspace_drive,workspace_calendar) - Grant permissions to agent users via the WorkingAgents admin interface
-
Agents connect to WorkingAgents and call
gmail_search,drive_list_files,calendar_create_eventjust like any other tool
The agent does not know – or care – whether the tool is backed by Google, ArangoDB, Slack, or an internal service. It sees a tool name and a schema. WorkingAgents decides whether to let the call through.