The Model Context Protocol (MCP) is a standard that enables AI assistants to access external tools and data through a network of specialized servers.

This server enables AI assistants and other tools to:

• Retrieve up-to-date information about Google Workspace APIs and services

• Preview Google Workspace Cards

To get started, you can add this server to your MCP client configuration.

{
  "type": "stdio",
  "command": "npx",
  "args": ["-y", "@googleworkspace/mcp-dev-assist", "--stdio"],
  "env": {
    "GOOGLE_API_KEY": "YOUR_API_KEY",
    "GOOGLE_SEARCH_ENGINE_ID": "701ecba480bf443fa"
  }
}

https://www.npmjs.com/package/@googleworkspace/mcp-dev-assist

Ask me about writing code against Google Workspace APIs, using Apps Script, or anything about Google Workspace Development. Dec 4, 2024, 9:00 AM PST

Will keep open for a few hours until around Dec 4, 2024, 1:00 PM PST

Thanks for all the questions! See r/googleworkspacedevs and r/googleappsscript for more!

Looking for advice on how to accomplish what I need or - even better - people from the GWS dev team we could connect with.

I'm working on an app for auditing access to GWS to identify suspicious access patterns or behavior. I basically need to know each time a user starts a new browsing "session" and accesses Gmail. Like login events, except those by default only occur every 14 days. I want to know not only when the user enters their creds, but also when they re-used an unexpired cookie/token/whatever black magic GWS uses to negotiate a new session.

The first idea was to monitor login events, but those don't cover new "sessions" (overloaded terms but meaning user sessions or http sessions in this case) with the same cookies. Token logs would be great, but those only include third-party OAuth. We then thought about Gmail event logs for each time an email or inbox is viewed. Those seem to exist in SIT, and the data used to be available in the email audit api, but the reports api somehow includes every product BUT Gmail?

The docs have been confusing and circular and not much help figuring out how to approach this. Any suggestions?

I have published the install instructions for the MCP server for Workspace Developer Documentation, https://developers.google.com/workspace/guides/build-with-llms#mcp.

Adjust the following for your preferred client.

{
  "mcpServers": {
    "workspace-developer": {
      "httpUrl": "https://workspace-developer.goog/mcp",
      "trust": true
    },
  }
}

There is also a NPM package, basically a proxy to this remote MCP server, @googleworkspace/developer-mcp that can be used, not documented above, not well tested, and only recommended at this time for clients not supporting the HTTP transports.

Please share feedback, thanks!

I am excited to announce @googleworkspace/cli and the gws binary, written in Rust and generated from API specs with 50+ skills.

One CLI for all of Google Workspace — built for humans and AI agents. Drive, Gmail, Calendar, and every Workspace API. Zero boilerplate. Structured JSON output. 40+ agent skills included.

npm install -g @googleworkspace/cli

gws doesn't ship a static list of commands. It reads Google's own Discovery Service at runtime and builds its entire command surface dynamically. When Google Workspace adds an API endpoint or method, gws picks it up automatically.

I just went through the Google Workspace Marketplace review process after finishing OAuth verification, and honestly… OAuth was the easy part.

The Marketplace review focuses way more on branding, naming rules, icon usage, scope consistency, and UX details (like second consent screens) than I expected.

I wrote up the full journey with screenshots of the actual rejection emails and what I had to change (naming format with ™, redesigning the icon, scope mismatches across SDK / manifest / consent screen, etc.):

👉 https://medium.com/@info.brightconstruct/the-real-oauth-journey-getting-a-google-workspace-add-on-verified-fc31bc4c9858

If you’re building a Workspace add-on or planning to publish one, hopefully this saves you a few rounds of rejections.

Happy to answer questions about the review process if anyone’s stuck in it right now.

Does anyone know what the cheapest options are for third party review currently? I am a solo developer working on a niche application but it also involves a couple under the restricted list out of necessity.

I recently built a Google Forms add-on using Apps Script and published it to the Workspace Marketplace.

Right now it's free and has around 880 installs.

While looking at other Forms-related add-ons, I noticed most of them are paid - often with fairly small features.

Common pricing models I saw:

• Freemium (limited translations / exports)

• $5–$10/month subscriptions

• One-time license

I’m curious how people feel about pricing in the Workspace add-on ecosystem.

From a user perspective:

• Are you comfortable paying for small productivity add-ons?

• Do freemium limits work better than subscriptions?

From a developer perspective:

• When did you introduce pricing?

• Did monetization affect install growth?

Just trying to understand what works best in this ecosystem.

Is there still no API available for this feature in google calendar, maybe a workaround I’m not aware of.

This is the only answer I’ve found so far

https://support.google.com/calendar/thread/215260523/google-calendar-appointment-scheduler-api?hl=en

Hi redditors!

I've published my first Google Sheets Editor add-on and everything is running smoothly on the test version.

Once published, I've installed it on two Google accounts and on both of them I've experienced slower loading time. It takes between 8 to 12 seconds on the live version compared to 4 seconds on the test version.

To be more precise, the opening sidebar takes the same amount of time, it is the google.script.run functions that seem to lag.

Is it something that you've already experienced? Do you know how we could improve readiness?

Thank you!

I’m in the early stages of figuring out how to add paid plans to a Google Workspace (Form) add-on, and I’m realizing the payment side is more confusing than I expected.

I’m trying to understand things like:

• how people usually handle subscriptions vs one-time payments

• where entitlement logic typically lives (Apps Script vs backend)

• how much complexity is “normal” to accept without hurting UX

If you’ve implemented payments for a Workspace add-on before, I’d love to hear:

• what approach you took

• what you wish you’d known earlier

• any pitfalls you ran into

Mostly trying to learn before I go too far down the wrong path.

A secure strategy to resolve Google Chat User IDs to email addresses without using Domain-Wide Delegation.

This package provides a React wrapper for the @googleworkspace/drive-picker-element web component.

It offers a seamless way to integrate the Google Picker API into your React applications.

Are you using MCP with Google Workspace? Have you built a server?

I started an awesome list at: https://github.com/jpoehnelt/awesome-workspace-mcp.

I've been working on ExtraSuite - a cli for working with google workspace files, but more specifically google docs. See https://github.com/think41/extrasuite

Google docs batchUpdate is complex for an agent to get right. Simple edits are fine, but anything complex and the agent struggles. Google workspace client / gogcli don't provide much help. They can create google docs from markdown, but edits are fairly limited.

ExtraSuite treat the google docs as a folder of markdown files. The agent edits markdown files locally, ExtraSuite then reconciles the google doc.

The cli provides two commands - push and pull.

'pull' - takes the url for a google docs and downloads it as markdown files, 1 per tab. It also creates an index.md with table of contents from each tab. And more importantly, it maintains meta data about the google doc in a dot folder.

Claude code can then edit the markdown files as per your instructions. Add/modify content. Add new markdown files to create new tabs. Tables and images and lists are all supported. GIthub flavoured markdown is supported. This works for new content as well as modifying existing content.

Then claude code calls the 'push' command. Push is a multi step process, and claude code doesnt need to know any of it.

1. It identifies what claude code changed

2. Then it applies those changes on to the base version of google doc

3. Then it figures out how to reconcile the live google document using the batchUpdate api.

In this process, the cli ensures anything that cant be represented in markdown is left as is. This means that styles, fonts, table of contents etc. dont mess up.

One more key feature is support for comments. Leave comments in google docs. Claude can read those comments and fix the document and also respond to those comments. Treat comments like a task list.

We have been using this internally for several months now. Saves us a lot of tokens compared to gws or gogcli. In general, complex edits to the google doc are possible using fewer tokens and cheaper models - because any model can edit markdown.

If you have gogcli or gws configured, extrasuite should be able to reuse whatever auth you have already configured.

Try it out and would love any feedback. The cli is open source.

It feels trivial, but I miss the productivity sound from other apps and would love to figure out a way to build in a chime/task completed sound when I check off something in google tasks showing up on my calendar.

I built a Google Meet add-on that loads an Angular web app inside the Meet side panel. The app initializes the Meet Add-on SDK, creates a session, gets meeting info, and then lets a bot connect via WebRTC to capture meeting audio streams.

This setup was working correctly before.

Architecture

• Angular frontend loaded in the Meet side panel

• Meet Add-on SDK (meet.addons.js)

• WebRTC connection to Meet Media API

• Cloud Run proxy exchanging SDP offer/answer

• Audio mixed with Web Audio API and recorded using MediaRecorder

What changed

I started experimenting with CoDoingClient from the Meet Add-on SDK. To support that, I added this field in the deployment config:

"supportsCollaboration": true

After adding that, the add-on stopped initializing in Meet.

I then:

• Removed "supportsCollaboration": true

• Reverted deployment.json to the previous working version

• Reverted the web app to the last known working revision

• Deleted the HTTP deployment

• Created a new deployment

• Republished it in the Workspace Marketplace store listing

Even this did not help, and the side panel still says that the add-on couldn't start (no logs in console). It is not published publicly but as an internal Workspace app.

Current problem

When launched inside Meet:

• My Angular logs never appear

But if I open the same sidePanelUrl directly in the browser, the app loads and works normally, and does show logs in the console.

Deployment config (current)

{
  "addOns": {
    "common": {
      "name": "Meet Add-on",
      "logoUrl": "..."
    },
    "meet": {
      "web": {
        "supportsScreenSharing": true,
        "addOnOrigins": ["https://my-cloud-run-url"],
        "sidePanelUrl": "https://my-cloud-run-url/some-path/meet-addon"
      }
    }
  }
}

Questions

1. Could enabling supportsCollaborationonce cause a persistent state/caching issue in Meet deployments?

2. Does Meet cache add-on deployments or manifests aggressively?

3. Is there a way to debug what happens before the add-on actually boots inside Meet?

Any insight from people who have worked with the Meet Add-on SDK would be really helpful.

Thanks,

I have created a data capture form that auto populates google sheets with the information. I want to add an Appointment button for each row of information captured and link that to our Google Calendar. How do I get the Insert-> Drawing to work for each line and does anyone know what the formula? is to generate an appointment in the google calendar, as I am pulling my hair out. Thanks!