When I saw the gws repository last week, the first thing I did was clone it and test it against a sandbox account. Not because the tool is perfect — it’s pre-v1.0 and has rough edges — but because what it represents is bigger than the tool itself.

Google just published an open-source CLI that connects every Workspace API through a single entry point. Drive, Gmail, Calendar, Sheets, Docs, Chat, Admin — all accessible from one command line. And what makes it relevant for any team working with AI agents: it includes a built-in MCP server that turns every Workspace operation into a skill an agent can invoke.

Google Just Gave AI Agents the Keys to Workspace

gws isn’t a static wrapper around Google’s APIs. It builds itself dynamically from Google’s Discovery Service, which means every time Google adds or modifies an API, the CLI reflects it automatically. It’s a smart architecture decision — and also the reason it doesn’t need constant manual updates.

Unified access is what matters here. Before gws, connecting an AI agent to Gmail required one SDK, to Calendar another, to Drive yet another — each with its own authentication and pagination quirks, plus edge cases unique to that service. Now it’s a single binary with a single credential configuration.

The caveat you can’t ignore: this is NOT an official Google product. The README says it explicitly — “not an officially supported Google product”. It’s pre-v1.0. APIs will change without notice. If you build on top of it, you need to be prepared for things to break. I mention this because the temptation to ship it straight to production will be strong.

40 Agent Skills and 50 Recipes — What That Actually Means

Skills vs. recipes

Skills are atomic operations: read an email, create a calendar event, list files in a Drive folder, write a row to a Sheets spreadsheet. They’re the building blocks.

Recipes are pre-built combinations of those skills that solve complete workflows. “Search emails from a specific sender, extract attachments, and save them to Drive” — that’s a recipe.

The practical difference: skills give you full flexibility to build your own flows; recipes give you quick results for the most common use cases. If your team has engineering capacity, skills are the starting point. If you’re looking to quickly validate whether the tool fits your needs, start with the recipes.

MCP server integration

This is what really changes things. gws ships with an MCP (Model Context Protocol) server that exposes the 40+ skills as tools invocable by any compatible agent.

If you already work with MCP-compatible agents — and we covered what MCP is and why it matters in our WebMCP standard analysis — this is plug-and-play. Your agent discovers available tools, reads their descriptions, and invokes them. No custom integration code. No Google SDK in your agent.

It’s the same principle that gives the protocol its power: separating intelligence (your agent) from capabilities (the Workspace APIs). And gws just made that separation practical, not just theoretical.

Three Workflows We’d Build First

Not everything that can be automated is worth automating. These are the three flows we’d put an agent on top of gws for today — in a test environment, not production.

Weekly operations digest

Monday at 7 AM, an agent reads unread emails from the previous week in Gmail and checks the coming week’s Calendar events. It also pulls recently modified documents from Drive. With that, it generates a one-page briefing: what’s pending, what’s coming, and which documents need attention.

It’s not magic. It’s the task someone already does manually, or worse, that nobody does and that’s why Monday starts without context.

Client document pipeline

A contract arrives by email. The agent detects it and moves it to the right Drive folder. From there, it extracts key data (amount, dates, signers) into a Sheets spreadsheet — and sets up Calendar reminders for critical dates.

Step	Manual	With agent
Detect email with contract	~5 min	Automatic
Move to Drive folder	~2 min	Automatic
Extract data to Sheets	~15 min	~30 sec
Create date reminders	~5 min	Automatic
Total	~27 min	~1 min

Multiply that by 20 contracts a month and that’s ~9 hours recovered. It’s not digital transformation — it’s operational hygiene.

Cross-platform meeting intelligence

Before each meeting, the agent searches Drive for documents shared by attendees and extracts the relevant points into a brief. After the meeting, it generates a summary and posts it to the team’s Chat channel.

If you combine this with the agent operations logic we’ve already covered, the result is an information flow that doesn’t depend on someone remembering to send the summary.

The Risks You Need to Know Before Building on This

Pre-v1.0 means exactly what it says

As we detailed in our Google AI ecosystem evaluation for B2B, Google has a mixed track record with experimental tools. Some become solid products. Others die without notice. gws falls in the “interesting but no continuity guarantee” category.

If you build production pipelines that depend on gws directly, you’re accepting the risk that an update breaks your flow on a Tuesday at 3 PM. For an internal engineering team that can fix it quickly, that’s manageable. For a product you sell to clients, it’s not.

OAuth scopes are governance decisions

Giving an agent access to the CEO’s Gmail is a governance decision, not an engineering one. The same applies to Drive, Calendar, Admin.

Every gws skill requires specific OAuth scopes. “Minimum scope” should be the rule — the agent only sees and touches what it needs. But in practice, the temptation is to grant broad scopes because it’s easier to configure. Don’t.

And there’s a risk that gws documentation doesn’t mention: prompt injection via email. An attacker who knows your agent reads emails can send a message designed to manipulate the agent’s instructions. If the agent has write scope on Drive, that email could end up modifying documents. The mitigation is simple: human oversight for any write action, no exceptions at this stage.

Build behind an adapter

gws is one of several options for connecting agents to Workspace. Microsoft has Graph API for its ecosystem. There are independent wrappers. If you connect your agent directly to gws without an abstraction layer, you’re coupling your logic to a pre-v1.0 tool.

The right investment is an adapter: your agent talks to your interface, your interface talks to gws (or whatever comes next). Three extra days of work today that save you three weeks when Google breaks the API.

How to Evaluate This for Your Company

It makes sense to try it today if:

• Your team already works with AI agents and has experience with MCP
• You have a test environment separate from production where you can break things without impact
• The workflow you want to automate is internal, low-risk, and doesn’t touch client data or regulated processes

Better to wait if:

• Your team doesn’t have experience with CLIs or OAuth credential configuration
• The first use case you have in mind is a critical production process — that’s the wrong place to experiment with a pre-v1.0 tool
• Engineering capacity to maintain the integration when the API changes isn’t available

At IQ Source, we’ve been testing gws internally since last week. We connected the MCP server to a test agent that reads emails and creates summaries in Chat. It works. It’s impressive how fast you can build a flow. But we wouldn’t put it in client production yet — not until there’s a stable release or at least a commitment from Google to the current API.

If you want to evaluate whether gws (or any other Workspace automation tool) makes sense for your operations, we offer a 30-minute mapping session. We review your repetitive Workspace processes, identify which ones actually benefit from an agent, and give you an honest recommendation — including “this isn’t worth it yet.” No commitment, no pitch. Schedule here.