AppsScriptPulse

Solutions, AI, Advanced

The Age of the Agent: Google’s Managed MCP Servers and Community Contributions

Tags:
| | 0 Comments |

Image credit: Kanshi Tanaike

 

The “USB-C for AI” has officially arrived at Google.

If you have been following the rapid rise of Anthropic’s Model Context Protocol (MCP), you know it promises a standardised way for AI models to connect to data and tools. Until now, connecting an LLM to your Google Drive or BigQuery data meant building custom connectors or relying on fragmented community solutions.

That changed this week with Google’s announcement of fully managed, remote MCP servers for Google and Google Cloud services. But typically for the Google Workspace developer community, we aren’t just waiting for official endpoints—we are building our own local solutions too.

Here is an overview of the different approaches emerging for MCP tools and what the future looks like for Workspace developers.

The Official Path: Managed MCP Servers

Google’s announcement represents a massive shift in how they view AI agents. Rather than asking developers to wrap every granular API endpoint (like compute.instances.insert) into a tool, Google is releasing Managed MCP Servers.

Think of these as “Client Libraries for Agents.” Just as Google provides SDKs for Python or Node.js to handle the heavy lifting of authentication and typing, these managed servers provide a simplified, reasoned interface for agents.

The announcement lists a massive rollout over the “next few months” covering everything from Cloud Run and Storage to the Android Management API. The goal described is to make MCP the standard way agents connect to the entire Google ecosystem. To start with Google announced MCPs for:

  • Google Maps: instead of just raw data, the agent gets “Grounding Lite” to accurately answer location queries without hallucinating.
  • BigQuery: The agent can interpret schemas and execute queries in place, meaning massive datasets don’t need to be moved into the context window.
  • Google Kubernetes Engine (GKE): Agents can diagnose issues and optimize costs without needing to string together brittle CLI commands.

The Community Path: Privacy-First and Scriptable

While managed servers are excellent for scale and standardisation, there are some other notable approaches using local execution.

1. The Gemini CLI Workspace Extension As detailed in a recent tutorial by Romin Irani, the official google-workspace extension for the Gemini CLI takes a privacy-first approach. Instead of running in the cloud, the MCP server runs locally on your machine.

It uses your own local OAuth token, meaning your data flow is strictly Google Cloud <-> User's Local Machine <-> Gemini CLI. This is ideal for tasks like searching Drive, checking your Calendar, or drafting Gmail replies where you want to ensure no third-party intermediary is processing your data.

2. The Power of Apps Script (gas-fakes) For true customisability, Kanshi Tanaike has been pushing Google Apps Script. A recent proof-of-concept using gas-fakes CLI demonstrates how to build MCP tools directly using Apps Script.

This is a big step for Apps Script developers. It allows you to write standard GAS code (e.g., DriveApp.getFilesByName()) and expose it as a tool to an MCP client like Gemini CLI or Google Antigravity. Because it uses the gas-fakes sandbox, you can execute these scripts locally, bridging the gap between your local AI agent and your cloud-based Workspace automation.

The Future: A Universal MCP Strategy?

We are likely moving toward a world where every Google product launch includes three things: API documentation, Client SDKs, and an Official MCP Server Endpoint.

For developers, the choice will come down to granularity and control:

  • Use Managed Servers when you need reliable, standard access to robust services like BigQuery or Maps with zero infrastructure overhead.
  • Use Community/Local Tools (like the Workspace extension or gas-fakes) when you need rapid prototyping, deep customization, or strict data privacy on your local machine.

The “Agentic” future is here, and whether you are using Google’s managed infrastructure or writing your own tools, the ecosystem is ready for you to build.

Sources:

Snippet, Solutions, Calendar, Gmail, Beginner

How to use Google Apps Script to automate your Gmail out-of-office message

Tags:
| | 0 Comments |

As a Developer Advocate for Google Workspace, I live and breathe productivity tools. But even the most tech-savvy among us can have frustratingly simple oversights. My recurring pain point? Forgetting to turn on my Gmail vacation responder to automatically notify people of my absence before heading out of office.

Google Workspace Developer Advocate, Chanel Greco, has shared a clever solution to automate their Gmail out-of-office notification using Google Apps Script. Faced with the recurring problem of forgetting to set up the out-of-office notification, Chanel crafted a script that does the job based on Google Calendar events marked as ‘outOfOffice’.

Chanel’s project not only solves a personal problem but also demonstrates the benefits of Google Apps Script for task customization and productivity. By harnessing the power of Workspace APIs, you can create innovative solutions to automate routine tasks and streamline workflows.

Follow the source link to read more…

Source: How I Used Apps Script to Never Forget My Gmail Vacation Responder Again

Library, New IDE, Solutions

Creating a custom Google Apps Script project version history 

Tags:
| | 0 Comments |

This report introduces the method for managing the histories of the Google Apps Script project.

On August 23, 2023, the project history has been implemented in the new IDE of Google Apps Script. In the current stage, the users can see the history of the previously deployed script version. … In the case of the classic IDE, the users had been able to see the previously saved script version regardless of the deployment and just the save of the script. This is not implemented in the new IDE.

In August 2023, Google updated the online Apps Script Editor adding a feature which lets you view previously deployed script versions and compare them to the current script version. A current limitation the history is limited to versioned deployments. As noted in this source post from Kanshi Tanaike, deployments require several steps and you have to remember to go through the process. To make the process easier Kanshi has published a ScriptHistoryApp library, which can be used to create a custom web interface for making your own Apps Script project version history. Perhaps more usefully you can also manage snapshots of your script projects by fetching a URL. This makes it easy for you to either regularly save a project on a timed trigger or an event based mechanism.

Source: Managing History of Google Apps Script

Library, Intermediate

Easily managing time-driven triggers using Google Apps Script and the TriggerApp library

Tags:
| | 0 Comments |

Google Apps Script can be executed by time-driven triggers. This is one of the very important points for taking cloud computing. But, the scenarios using time-driven triggers are different for each user, and there are a lot of situations for using time-driven triggers. But, when a script for implementing time-driven triggers is developed, each script is different and complicated. In this report, I would like to introduce easily managing time-driven triggers using a Google Apps Script library.

In Google Apps Script time-driven triggers are a powerful way to automate tasks including Google Sheets. However, managing them can be difficult, especially if you have a lot of triggers and need triggers to run at different times and frequencies. The TriggerApp library from Kanshi Tanaike makes this a lot easier and this post includes a number of examples that are easy to copy/modify for your own script projects. The post covers the following scenarios:

  • Execute 2 functions at specific dates and times
  • Execute a function with a specific cycle between specific times between specific dates
  • Execute 3 functions with a specific cycle between specific times on weekdays
  • Send an email on a birthday every year
  • Execute specific functions on specific weekdays in a week
  • Execute 6 different functions every 10 minutes from “09:00:00” to “11:50:00” in order
  • Opening hours of Google Form from 09:00 to 17:00 on Weekdays
  • Opening Hours of Google Spreadsheet from 09:00 to 17:00 on Weekdays
  • Execute specific functions at 09:00 on Monday to Friday at the beginning of specific months

The source code for the library is on GitHub and includes documentation on all the methods it uses.

Source: Easily Managing Time-Driven Triggers Using Google Apps Script

Library, Solutions, Docs, Sheets, Slides, Intermediate

Easily merge data from Google Sheets into Google Docs and Slides with the TemplateApp Google Apps Script

Tags:
| | 0 Comments |

This report introduces the method for easily processing the template of Google Documents and Google Slides using Google Spreadsheet as a database using Google Apps Script. Google Spreadsheet is used as a database. Google Documents and Google Slides are used as templates. The simple method for creating new Google Documents and Google Slides using the database and the templates is introduced.

Latest Apps Script magic from Kanshi Tanaike, this time they turn their addition to an easy way to use data from Google Sheets as a ‘document merge’ for templates created in Google Docs and Google Slides. This is achieved by using the TemplateApp Apps Script library, which has lots of useful features including simply methods for sheetRangeToDocuments() as well as the ability to embeded and fixed width images from placeholders. There are some llimitations documented in the GitHub repo, as well as examples for all the methods available in the library.

[In other ‘merge’ news Google have announced that you can now use Google Sheets with Google official mail merge in Gmail]

 

Source: Easily Processing Templates of Google Documents and Google Slides using Google Spreadsheet with Google Apps Script