Provides programmable access to Google Workspace APIs, allowing users to execute JavaScript or TypeScript code to interact with services like Google Drive and Google Calendar via the googleapis SDK.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Google Workspace Code MCP List my calendar events for today"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Important: This is an alternative experiment, not my primary setup
If you are looking for the Google Workspace integration I actually use day-to-day, use this skill instead:
This repository is an alternative code-first MCP experiment built around one execute tool.
It is intentionally aligned with the ideas in:
Your MCP Doesn’t Need 30 Tools: It Needs Code — https://lucumr.pocoo.org/2025/8/18/code-mcps/
That post explores code-supported/code-first MCP design (fewer fixed tools, more programmable capability).
A local JavaScript/TypeScript MCP server with a single tool: execute.
execute runs JavaScript (or TypeScript with type stripping) and gives that code authenticated access to Google Workspace APIs.
Exposes one MCP tool: execute
Runs user-provided JavaScript/TypeScript (async function body; TS types stripped)
Automatically performs OAuth login on first use (browser flow)
Reuses stored tokens on subsequent calls
Provides a small runtime API inside executed code:
auth — Google OAuth client
google — googleapis SDK root
workspace — helper methods (call, service, whoAmI)
state — persistent mutable object across calls
This follows a code-mode design: one flexible execution tool instead of many fixed tools.
Related MCP server: google-workspace-mcp-advanced
Node.js 20+
Local desktop/browser access for the initial OAuth sign-in
npm installnpm startor:
node src/server.jsThis repo already includes .mcp.json:
{
"mcpServers": {
"google-workspace-code": {
"type": "stdio",
"command": "node",
"args": [
"/Users/mitsuhiko/Development/workspace-mcp/src/server.js"
],
"env": {
"GOOGLE_WORKSPACE_AUTH_MODE": "cloud"
}
}
}
}If you move the project, update the args path.
execute
script (string, required): JavaScript/TypeScript async function body (TS type syntax is stripped before execution)
timeoutMs (number, optional): execution timeout in milliseconds (default 30000, max 300000)
scopes (string[], optional): override OAuth scopes for the call
resetState (boolean, optional): clears persistent state before execution
Your script runs as an async function body with these variables in scope:
auth
google
workspace
state
Return values are serialized and sent back as tool output.
const me = await workspace.whoAmI();
const files = await workspace.call('drive', 'files.list', {
pageSize: 5,
fields: 'files(id,name,mimeType)'
});
state.lastEmail = me.email;
return {
user: me,
files: files.files,
remembered: state.lastEmail
};const start = new Date();
start.setHours(0, 0, 0, 0);
const end = new Date(start);
end.setDate(end.getDate() + 1);
return await workspace.call('calendar', 'events.list', {
calendarId: 'primary',
timeMin: start.toISOString(),
timeMax: end.toISOString(),
singleEvents: true,
orderBy: 'startTime'
});First call without token triggers browser login automatically
Default config directory: ~/.pi/google-workspace
Default token path: ~/.pi/google-workspace/token.json
Default auth mode: cloud (unless overridden)
GOOGLE_WORKSPACE_CONFIG_DIR
GOOGLE_WORKSPACE_CREDENTIALS
GOOGLE_WORKSPACE_TOKEN
GOOGLE_WORKSPACE_AUTH_MODE (cloud or local)
GOOGLE_WORKSPACE_CLIENT_ID
GOOGLE_WORKSPACE_CLOUD_FUNCTION_URL
GOOGLE_WORKSPACE_CALLBACK_HOST
Uses Node vm for execution convenience, not a hardened sandbox.
Treat this as trusted local tooling.
Do not expose this server to untrusted users or networks.
Execute JavaScript/TypeScript inside a Node vm context with authenticated Google Workspace access. TypeScript type syntax is stripped before execution. The script runs inside an async function body and can use: auth, google, workspace, state. Return values with return ....
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | JavaScript/TypeScript async function body. Type syntax is stripped before execution. Available variables: auth, google, workspace, state. | |
| timeoutMs | No | Execution timeout in milliseconds (default: 30000). | |
| scopes | No | Optional OAuth scopes override. Defaults to broad Google Workspace scopes. | |
| resetState | No | Reset persistent `state` object before execution. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the execution environment (Node vm), authentication context, TypeScript handling, and available variables, which is valuable. However, it lacks critical behavioral details like security implications, error handling, resource limits, or what happens with the 'state' object persistence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences that each add value: the first establishes the execution context and capabilities, the second explains return value mechanics. There's minimal redundancy, though it could be slightly more front-loaded about the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool that executes arbitrary code with authentication and state management, the description provides adequate technical context about the execution environment but lacks important completeness elements. With no output schema and no annotations, it should explain more about return values, error conditions, security boundaries, and the persistence model for the 'state' object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal parameter semantics beyond the schema - it mentions 'auth, google, workspace, state' for the script parameter, which slightly reinforces the schema. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Execute JavaScript/TypeScript'), the environment ('inside a Node vm context with authenticated Google Workspace access'), and the available resources ('auth, google, workspace, state'). It distinguishes this as a code execution tool with specific runtime characteristics, which is unambiguous even without sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or what scenarios it's designed for. It explains technical capabilities but offers no context about appropriate use cases, prerequisites, or limitations beyond the execution mechanics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0executeScored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The tool has a single, clearly defined purpose: executing JavaScript/TypeScript code in a Google Workspace context.
A single tool inherently has perfect naming consistency. The tool name 'execute' follows a clear verb-based pattern, and there are no other tools to create inconsistency.
One tool is too few for a server with the broad scope implied by 'Google Workspace Code MCP'. This suggests a single-purpose utility rather than a comprehensive interface to Google Workspace, which typically involves multiple resources and operations.
The tool set is severely incomplete for the stated purpose. A Google Workspace integration would typically require tools for managing users, groups, documents, calendars, etc., but this server only provides a generic code execution tool with no specific Workspace operations.
Hosted MCP server with managed OAuth for 15+ toolkits: Google Workspace, Fitbit, Oura, Kalshi, etc.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
The Google Compute Engine MCP server is a fully-managed Model Context Protocol server that provides tools to manage Google Compute Engine resources through AI agents. It enables capabilities including instance management (creating, starting, stopping, resetting, listing), disk management, handling instance templates and group managers, viewing machine and accelerator types, managing images, and accessing reservation and commitment information. The server operates as a zero-deployment, enterprise-grade endpoint at https://compute.googleapis.com/mcp with built-in IAM-based security.
Hosted Google Calendar MCP server for AI agents. No self-hosting or Google Cloud setup.
