Which integrations are available for this server?

Provides tools for reading and managing Google Calendar events, including listing calendars, viewing schedules, finding free slots, creating, moving, modifying, and deleting events with safety constraints.

How do I use Google Workspace MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Google Workspace MCP Server What's on my calendar 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.

Google Workspace MCP Server

by wrik0

Overview Schema Source Related Servers Discussions Admin

Python

Local

Google Workspace MCP Server

CI Status License: MIT Python Version

A hardened, safety-first Google Calendar Model Context Protocol (MCP) server designed for enterprise reliability, strict data isolation, and deep agentic workflow integrations. This server empowers AI agents (like Claude Desktop, Cursor, or Antigravity) to read and manage calendars while enforcing strict user-defined security limits at runtime.

✨ Core Features & Safety Constraints

To protect user accounts and prevent unauthorized modifications, the server implements multiple runtime safeguards:

🔒 Domain Boundary Whitelist: Blocks agents from sending calendar invites to external or unauthorized email domains (via GWS_ALLOWED_DOMAINS).
🛡️ PII & Description Scrubber: Redacts email addresses, phone numbers, and meeting details dynamically based on privacy levels (GWS_PII_MODE).
👥 Double-Booking Prevention: Checks calendar availability automatically before booking an event unless the client explicitly requests an override (ignore_availability=True).
⚠️ Two-Turn Delete Flow: Forces a dry-run confirmation step for event deletions, returning a detailed preview card before executing changes.
📁 Profile-Based Token Storage: Isolates authentication tokens based on GWS_PROFILE to allow multi-tenant/account setups (e.g., separating personal and corporate accounts).
⏱️ API Rate Limiter: Enforces a global minimum interval of 100ms between calls to avoid flooding Google Cloud API quotas.
📝 Structured Audit Logging: Appends timestamped, owner-only readable (chmod 600) JSON log lines for all modifying actions.

Related MCP server: gcal-mcp

🚀 Quick Start & Installation

1. Run the Interactive Installer (Recommended)

We provide an interactive installer script that handles virtual environments, fetches dependencies, guides you through placing your Google credentials, runs the auth flow, and auto-injects configuration settings into Claude Desktop:

# Clone the repository and kick off the configuration engine
curl -fsSL https://raw.githubusercontent.com/wrik0/gws-workspace-agent/master/setup.sh | bash

Alternatively, if you already cloned the repository locally:

./setup.sh

You can also configure a custom profile (e.g., work) during setup:

./setup.sh --profile work

2. Manual Installation

If you prefer to configure the environment manually:

# Clone the repository
git clone https://github.com/wrik0/gws-workspace-agent.git
cd gws-workspace-agent

# Set up environment and install package in editable mode
uv venv
uv pip install -e ".[dev]"

3. Google OAuth Setup

Before running the server, place your Google Cloud Client Secrets file (credentials.json) in the standard application data folder:

Linux: ~/.config/google-workspace-mcp/credentials.json
macOS: ~/Library/Application Support/google-workspace-mcp/credentials.json
Windows: %APPDATA%\gws\google-workspace-mcp\credentials.json

Next, run the CLI authorization utility:

# Performs browser login and caches the OAuth token
# On Unix (using the symlinked binary):
gws-auth
# Or directly via virtual environment:
.venv/bin/gws-auth

⚙️ Environment Configuration

You can configure the server behaviour using environment variables or equivalent command-line options when serving:

Environment Variable	CLI Option	Default	Description
`GWS_PROFILE`	`--profile`	`default`	Workspace profile name. Resolves to `token_{GWS_PROFILE}.json`.
`GWS_MODE`	`--mode` / `--readonly`	`full`	Mode of operation: `full` (read/write tools) or `readonly` (read tools only).
`GWS_PII_MODE`	`--pii-mode`	`redact`	Privacy filter: `none` (no masking), `redact` (phone/emails masked), `metadata_only` (description/title removed).
`GWS_ALLOWED_DOMAINS`	`--allowed-domains`	None	Comma-separated domain whitelist for invitees (e.g. `company.com,partner.org`).
`GWS_TIMEZONE`	None	System Local	Local timezone database name (e.g. `America/New_York` or `Asia/Kolkata`).
`GWS_AUDIT_LOG`	None	`APP_DIR/audit.log`	Destination path for the append-only JSON audit logs.

🛠 Command Line Interface (CLI)

The package exposes three entry points:

`gws-serve`

Starts the stdio FastMCP server.

gws-serve --mode readonly --pii-mode redact --allowed-domains company.com

`gws-auth`

Starts the OAuth token refresh browser loop.

# Request only read-only scopes from Google
gws-auth --mode readonly
# Request write scopes (requires verification if app is in sandbox)
gws-auth --mode full

`gws-purge`

Purges cached tokens and credentials files.

# Deletes cached token file but leaves credentials.json intact
gws-purge --token-only
# Deletes the entire application config directory
gws-purge --all

🔌 Client Integration

Claude Desktop

Add this to your claude_desktop_config.json:

{
  "mcpServers": {
    "google-workspace": {
      "command": "~/.local/bin/gws-serve",
      "args": ["--readonly", "--pii-mode", "redact"],
      "env": {
        "GWS_ALLOWED_DOMAINS": "mycompany.com"
      }
    }
  }
}

Cursor IDE

Navigate to Cursor Settings > Features > MCP > + Add New MCP Server:

Name: google-workspace
Type: command
Command: ~/.local/bin/gws-serve --readonly --pii-mode redact

📦 MCP Tools Reference

Read Tools (Available in `readonly` and `full` modes)

list_calendars(): Lists all calendars in the account with their name, ID, and access roles (e.g. owner, reader).
view_schedule(time_min, time_max, calendar_id="primary"): Displays events in a specific window. Outputs summary, times, descriptions, and color emojis (derived from Google Color IDs).
find_slots(time_min, time_max, duration_minutes, calendar_id="primary"): Queries free/busy state and aggregates open slots available for scheduling.

Write Tools (Available only in `full` mode)

create_event(summary, start_iso, end_iso, ...): Creates a calendar event. Validates invitee domains, checks double-booking conflicts, and records the action in audit.log.
move_event(event_id, new_start_iso, new_end_iso): Shift events in time via a single PATCH API request.
modify_event(event_id, ...): Dynamically updates text details or appends new whitelisted attendees.
delete_event(event_id, confirm=False): Two-turn deletion flow. Run with confirm=False to inspect the event details card, and run with confirm=True to execute the API call.

🧪 Developer & Testing Suite

We use pytest for unit testing. The test suite uses mocks to fully simulate Google Cloud services and config directories:

# Run pytest locally
.venv/bin/pytest -v

Style & Format Enforcement

To maintain code quality, run Ruff checkers:

# Format codebase
.venv/bin/ruff format
# Run linter checks
.venv/bin/ruff check --fix

📄 License

This project is licensed under the terms of the MIT license.

Available Tools

7 tools

create_eventA

Create a new calendar event. Returns event ID and HTML link.

Use ignore_availability=True only when the user explicitly requests overlapping/conflicting bookings.

ParametersJSON Schema

Name	Required	Default
`end_iso`	Yes
`summary`	Yes
`color_id`	No
`location`	No
`start_iso`	Yes
`recurrence`	No
`calendar_id`	No	primary
`description`	No
`attendee_emails`	No
`ignore_availability`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds value beyond annotations by noting the return of event ID and HTML link, and provides a caution on ignore_availability. However, it does not disclose other behavioral aspects such as permission requirements, rate limits, or side effects beyond creation. Annotations only include destructiveHint=false, so the description carries some burden but falls short.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences. The first sentence conveys purpose and output, the second provides a critical usage guideline. There is no wasted text, and the key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 10 parameters (3 required) and an output schema exists, the description is too brief. It lacks details on date format, attendee specification, recurrence settings, and other important context that would help the agent use the tool correctly. The output schema's existence reduces the need to describe returned values, but parameter usage remains underspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must heavily compensate. It only clarifies the 'ignore_availability' parameter; other parameters like summary, start_iso, end_iso, and calendar_id are left unexplained. The schema provides titles but no further meaning, leaving significant ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a new calendar event' specifying the verb and resource. It also mentions the return format (event ID and HTML link), making the tool's purpose unambiguous. This distinguishes it from sibling tools like delete_event or modify_event.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on the 'ignore_availability' parameter, stating it should only be used when the user requests overlapping bookings. However, it does not offer broader guidance on when to choose this tool over alternatives, though the sibling names make the context clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_eventA

Destructive

Delete a calendar event by its ID.

ALWAYS call twice:

delete_event(confirm=False) -> Returns preview card.
delete_event(confirm=True) -> Executes deletion.

ParametersJSON Schema

Name	Required	Default
`confirm`	No
`event_id`	Yes
`calendar_id`	No	primary

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide destructiveHint=true, and the description adds the critical two-step confirmation pattern, enhancing understanding of the tool's safety mechanism.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded with purpose, followed by usage instructions. It is efficient, though the two-step process could be formatted for even quicker scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema and the destructive nature, the description adequately covers the required behavior. It could mention the preview card's content, but overall it provides sufficient context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description only mentions 'by its ID' for event_id. It does not explain calendar_id or confirm beyond the usage instructions, leaving parameter meanings partially unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Delete a calendar event by its ID'. It distinguishes from sibling tools like create_event, modify_event, and move_event.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs 'ALWAYS call twice' with a two-step confirmation process, specifying the sequence and behavior of each call.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find_slotsA

Read-only

Find open time slots using the Google freebusy API.

Checks availability for the user AND all invitees in one API call. Returns available windows (not raw busy blocks) — agent-ready output.

ParametersJSON Schema

Name	Required	Description	Default
`time_max`	Yes
`time_min`	Yes
`calendar_ids`	No
`invitee_emails`	No
`duration_minutes`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description adds valuable behavioral details: it uses the freebusy API, checks both user and invitee calendars, and returns pre-processed available windows instead of raw busy blocks. This fully discloses the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise: two sentences that convey the core purpose and key behavioral aspects. It is front-loaded and every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 parameters, 3 required, output schema exists), the description adequately covers its function, input requirements (implicitly), and output nature ('agent-ready windows'). It provides sufficient context for an agent to understand when and how to use it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not explain any parameter details despite 0% schema description coverage. Although parameter names are somewhat self-explanatory, there is no guidance on format, constraints, or relationships. The description should have compensated for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('find') and resource ('time slots'). It distinguishes itself from sibling tools like 'create_event' and 'view_schedule' by focusing on availability checking using the freebusy API.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly guides usage by stating it checks availability for the user and all invitees in one call, which suggests when to use it (e.g., for scheduling). However, it does not explicitly mention when not to use it or compare with alternatives like 'view_schedule'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_calendarsA

Read-only

List all calendars accessible to the user.

Returns calendar IDs needed for multi-calendar operations. Call once per session and reuse the IDs.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, it explains that the tool returns calendar IDs needed for multi-calendar operations, adding practical behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with front-loaded purpose; no unnecessary words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with output schema, the description adequately covers return values and usage pattern, making it complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so baseline is 4. The description does not need to add parameter information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists all calendars accessible to the user, with a specific verb and resource. It distinguishes from sibling tools which focus on events and slots.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance to call once per session and reuse IDs, which is helpful context. Does not mention when not to use, but the purpose is straightforward.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

modify_eventB

Modify text/metadata fields of an event using PATCH.

ParametersJSON Schema

Name	Required	Default
`event_id`	Yes
`calendar_id`	No	primary
`new_summary`	No
`new_color_id`	No
`new_location`	No
`add_attendees`	No
`new_description`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide destructiveHint=false, so the description's mention of 'PATCH' adds minor value by indicating partial update. However, no further behavioral details are given (e.g., permissions, side effects). The description does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, but it is appropriately short for a simple tool. However, a bit more detail on key parameters could be added without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description does not explain return values or usage context. With 7 parameters and only 1 required, the description is too minimal to fully inform an agent on how to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description only says 'text/metadata fields' without explaining specific parameters like event_id, calendar_id, new_summary, etc. The description fails to add meaning beyond the schema's property titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool modifies text/metadata fields of an event using PATCH, which is a specific verb and resource. It distinguishes from siblings like move_event (which changes time) and delete_event.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. For example, it doesn't mention that for changing event time, move_event should be used instead. The description lacks context for appropriate usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

move_eventC

Change the start and end time of an existing event by ID.

ParametersJSON Schema

Name	Required	Default
`event_id`	Yes
`calendar_id`	No	primary
`new_end_iso`	Yes
`new_start_iso`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations show destructiveHint=false, so description's 'change' is consistent but adds no further behavioral context (e.g., error handling, idempotency, impact on other fields). Minimal beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise single sentence, but overly brief, sacrificing necessary detail. No structural elements like bullet points or examples.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters, no output schema details, and no parameter descriptions, the description is insufficient for an agent to know return value, conflict behavior, or how to properly invoke the tool. Incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description provides no information about parameters. It only mentions 'by ID' for event_id but no details on new_start_iso, new_end_iso format, or calendar_id. Completely inadequate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'change' and resource 'existing event by ID', indicating time modification. However, it doesn't explicitly differentiate from sibling modify_event, which might also change times.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use versus alternatives like modify_event or create_event. No prerequisites or conditions mentioned. Implied usage only.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

view_scheduleA

Read-only

List calendar events in a time range with color-coded type labels.

Window is capped at GWS_MAX_WINDOW_DAYS to prevent bulk data exposure. Returns events formatted with emoji type labels derived from color IDs.

ParametersJSON Schema

Name	Required	Default
`time_max`	Yes
`time_min`	Yes
`calendar_id`	No	primary
`max_results`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint=true, which the description does not contradict. The description adds behavioral context: window capped at GWS_MAX_WINDOW_DAYS, emoji labels from color IDs. This adds value beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, all meaningful and front-loaded with the main action. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema, the description adequately covers the tool's purpose and behavioral constraints but lacks parameter explanations. For a tool with 4 params and 0% schema coverage, more detail is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description should compensate. It only mentions 'time range' broadly but does not explain any of the 4 parameters (time_min, time_max, calendar_id, max_results) in detail. This is insufficient for a tool with no schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List calendar events in a time range' with specific details about color-coded labels. It distinguishes from siblings like list_calendars (lists calendars) and find_slots (finds slots).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for viewing events in a time range but does not explicitly guide when to use this vs alternatives like find_slots or list_calendars. No exclusions or when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv0.1.0Jul 8, 2026
- First observedcreate_event
- First observeddelete_event
- First observedfind_slots
- First observedlist_calendars
- First observedmodify_event
- First observedmove_event
- First observedview_schedule

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Scored 2026-07-08 05:35 across 7 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: creating, deleting, modifying, moving events, finding slots, listing calendars, and viewing schedule. No overlap in functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., create_event, delete_event, find_slots). Perfect alignment.

Tool Count5/5

7 tools cover the essential calendar operations without bloat. Each tool serves a clear need, making the set well-scoped.

Completeness4/5

Core CRUD and scheduling workflows are supported, but a dedicated tool for retrieving a single event by ID or managing attendees is missing, which agents might need in some scenarios.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

CalendarMCP
ai.calendarmcp
Hosted Google Calendar MCP server for AI agents. No self-hosting or Google Cloud setup.
Calendar Management Workplace & Productivity
2
Kalender Sync A
de.kalender-sync
GDPR-compliant calendar access for AI assistants: read, create, edit, RSVP. Google, MS 365, Apple.
Calendar Management Workplace & Productivity
81
Chronary A
ai.chronary
Calendar API for AI agents: events, availability, Google/Microsoft setup, scheduling, and iCal.
Calendar Management Workplace & Productivity
542
ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24

Related MCP Servers

calendar-mcp
Calendar Management Workplace & Productivity
apex-500
A
license
Not graded
quality
Not graded
maintenance
MCP server that lets AI agents manage Google Calendar -- create events, check availability, and manage schedules.
Updated 6 months ago (2026-03-13 05:27 UTC)
MIT
gcal-mcp
Calendar Management Workplace & Productivity
eh24905-wiz
F
license
Not graded
quality
D
maintenance
A Model Context Protocol (MCP) server for read-only Google Calendar integration, providing calendar access to AI assistants.
Updated 9 months ago (2025-12-17 19:28 UTC)
-
mcp-google-gcal
Calendar Management Workplace & Productivity
sleepytimeshon
A
license
Not graded
quality
D
maintenance
An MCP server that enables AI assistants to manage Google Calendar events, calendars, sharing, and scheduling with full read/write access across multiple Google accounts, supporting natural language creation, recurring events, and Google Meet.
Updated 5 months ago (2026-04-06 02:19 UTC)
40
MIT
google-calendar-mcp
Calendar Management Workplace & Productivity
Naim-Howlader
A
license
Not graded
quality
C
maintenance
A production-ready MCP server that lets AI assistants interact with your personal Google Calendar using the Google Calendar API and OAuth 2.0.
Updated 2 months ago (2026-07-14 13:52 UTC)
56
MIT

Google Workspace MCP Server

✨ Core Features & Safety Constraints

🚀 Quick Start & Installation

1. Run the Interactive Installer (Recommended)

2. Manual Installation

3. Google OAuth Setup

⚙️ Environment Configuration

🛠 Command Line Interface (CLI)

gws-serve

gws-auth

gws-purge

🔌 Client Integration

Claude Desktop

Cursor IDE

📦 MCP Tools Reference

Read Tools (Available in readonly and full modes)

Write Tools (Available only in full mode)

🧪 Developer & Testing Suite

Style & Format Enforcement

📄 License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`gws-serve`

`gws-auth`

`gws-purge`

Read Tools (Available in `readonly` and `full` modes)

Write Tools (Available only in `full` mode)