Which integrations are available for this server?

Enables creating and managing calendar events, including setting event details like title, time, location, description, attendees, and time zones.

How do I use MCP Google Calendar Server?

1. Click on "Install 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., "@MCP Google Calendar Server create a team meeting tomorrow at 2pm for 1 hour in conference room B" 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.

MCP Google Calendar Server

by nkriman

Overview Schema Related Servers Score Discussions

JavaScript

Hybrid

MCP Google Calendar Server

A Model Context Protocol (MCP) server for creating Google Calendar events.

Setup

Install dependencies:
```
npm install
```
Get Google Calendar API credentials:
- Go to Google Cloud Console
- Create a new project or select existing one
- Enable the Google Calendar API
- Create credentials (OAuth 2.0 Client ID)
- Download the credentials and save as credentials.json in the project root
Authenticate:
- Run the server and use the authenticate_google_calendar tool to get the auth URL
- Visit the URL, grant permissions, and get the authorization code
- Create a token.json file with your credentials

Configure Claude Code: Add to your MCP settings:

{
  "mcpServers": {
    "google-calendar": {
      "command": "node",
      "args": ["/Users/krilet/mcp-google-calendar-server/src/index.js"]
    }
  }
}

Related MCP server: Google Calendar MCP Server

Usage

The server provides two tools:

`authenticate_google_calendar`

Generates an authentication URL for Google Calendar access.

`create_calendar_event`

Creates a new event in your Google Calendar.

Parameters:

summary (required): Event title
startDateTime (required): Start time in ISO format
endDateTime (required): End time in ISO format
description (optional): Event description
location (optional): Event location
timeZone (optional): Time zone (defaults to UTC)
attendees (optional): Array of email addresses

Example:

{
  "summary": "Team Meeting",
  "startDateTime": "2024-12-25T10:00:00-08:00",
  "endDateTime": "2024-12-25T11:00:00-08:00",
  "description": "Weekly team sync",
  "location": "Conference Room A",
  "attendees": ["colleague@example.com"]
}

Available Tools

6 tools

authenticate_google_calendarB

Generate authentication URL for Google Calendar access

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided. Description only mentions generating a URL but does not disclose side effects, OAuth flow details, or what happens after URL generation. More behavioral context is needed.

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?

Single sentence, front-loaded, no fluff. Efficiently conveys core purpose.

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's role in authentication (complex flow), the description is too minimal. It lacks info on output, required prior steps, or user interaction, making it incomplete for an agent.

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, so schema coverage is 100%. Description does not need to add param info; baseline 4 applies.

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 'Generate authentication URL for Google Calendar access', specifying both action and resource. It distinguishes from sibling tools that perform CRUD on events.

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 vs alternatives, prerequisites (e.g., client ID/secret), or when not to use. It lacks context for proper selection.

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

create_calendar_eventB

Create a new event in Google Calendar

ParametersJSON Schema

Name	Required	Description	Default
`summary`	Yes	Event title/summary
`description`	No	Event description (optional)
`startDateTime`	Yes	Start date and time in ISO format (e.g., 2024-12-25T10:00:00-08:00)
`endDateTime`	Yes	End date and time in ISO format (e.g., 2024-12-25T11:00:00-08:00)
`timeZone`	No	Time zone (e.g., America/Los_Angeles)	UTC
`attendees`	No	Array of attendee email addresses (optional)
`location`	No	Event location (optional)

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description 'Create a new event' does not disclose that this is a mutating operation requiring authentication, or any side effects or constraints beyond creation.

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, clear sentence with no wasted words, but could be slightly expanded to improve completeness without losing conciseness.

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 no output schema and no annotations, the description does not explain return values, error handling, or prerequisites like authentication, making it incomplete for effective use.

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

Parameters3/5

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

Schema coverage is 100% with descriptions for all 7 parameters, so baseline is 3. The description adds no additional parameter semantics beyond what the schema provides, so score remains 3.

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 states 'Create a new event in Google Calendar' with a specific verb (create) and resource (event in Google Calendar), clearly distinguishing from siblings like list, update, delete, and authentication tools.

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 is given on when to use this tool versus alternatives (e.g., update_calendar_event), prerequisites like authentication, or scenarios where creation is inappropriate.

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

delete_calendar_eventC

Delete a calendar event

ParametersJSON Schema

Name	Required	Description	Default
`eventId`	Yes	The ID of the event to delete

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of disclosing behavior. It does not state whether deletion is permanent, soft-delete, or requires specific permissions.

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 only one sentence long with no wasted words. While concise, it could benefit from slightly more detail without losing brevity.

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 tool's simplicity (single parameter, no output schema), the description covers the basic purpose but omits important context about behavior and usage.

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

Parameters3/5

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

Schema coverage is 100%, so the description adds minimal value beyond the schema. The eventId parameter is already documented in the schema.

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?

The description clearly states the verb 'Delete' and the resource 'calendar event', making the action unambiguous. However, it does not explicitly differentiate from sibling tools like update_calendar_event, so a small differentiation gap exists.

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. There is no mention of prerequisites, common scenarios, or exclusions.

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

list_calendar_eventsC

List upcoming calendar events

ParametersJSON Schema

Name	Required	Description
`maxResults`	No	Maximum number of events to return (default: 10)
`timeMin`	No	Lower bound for events (ISO format, default: now)
`timeMax`	No	Upper bound for events (ISO format)
`q`	No	Free text search terms to find events

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral aspects such as authentication requirements, rate limits, or that it only reads data. The agent relies solely on the word 'list' for safe operation.

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?

The description is extremely short and to the point, but it lacks additional context that could be useful (e.g., default behavior, timezone implications). It is appropriately sized but could be more informative.

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 absence of annotations and output schema, the description is incomplete. It does not explain what the response contains or that the tool requires prior authentication (implied by sibling tools).

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

Parameters3/5

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

Schema coverage is 100% with clear parameter descriptions. The tool description does not add extra meaning beyond the schema, meeting the baseline of 3.

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?

The description 'List upcoming calendar events' clearly states the action (list) and resource (calendar events). It distinguishes from siblings like create, update, delete. However, 'upcoming' is slightly misleading because the schema allows filtering for past events via timeMin.

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?

The description provides no guidance on when to use this tool versus alternatives like search or other calendar tools. No explicit conditions or exclusions are mentioned.

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

save_auth_tokenC

Save the authorization code received from Google OAuth

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	The authorization code from the OAuth callback URL

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description must bear the burden. It implies a write operation but omits details on side effects, persistence, overwrite behavior, or required permissions.

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?

The description is a single sentence, which is concise but lacks structure. It does not waste words, but could be more informative without being verbose.

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 no output schema and simple parameters, the description is minimally complete. It tells the agent what to provide and where it comes from, but fails to explain the tool's behavior or consequences of use.

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

Parameters3/5

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

Schema coverage is 100% with a clear description for 'code'. The tool description adds no extra meaning beyond the schema, so baseline 3 is appropriate.

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?

The description clearly states the action ('save') and the resource ('authorization code from Google OAuth'). It distinguishes from sibling tools, which focus on calendar events and authentication. However, it could be more specific about what 'save' entails.

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 guidelines on when to use this tool vs alternatives like 'authenticate_google_calendar'. The description does not provide context for when this token should be saved or prerequisites.

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

update_calendar_eventC

Update an existing calendar event

ParametersJSON Schema

Name	Required	Description
`eventId`	Yes	The ID of the event to update
`summary`	No	Event title/summary
`description`	No	Event description
`startDateTime`	No	Start date and time in ISO format
`endDateTime`	No	End date and time in ISO format
`timeZone`	No	Time zone (e.g., America/Los_Angeles)
`attendees`	No	Array of attendee email addresses
`location`	No	Event location

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It implies mutation but fails to disclose whether updates are partial or full, what side effects occur, or required permissions. This is insufficient for a mutation tool.

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?

The description is a single sentence of 5 words, which is concise but lacks valuable context. It could include behavioral details without being overly long.

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 8 parameters and no output schema or annotations, the description is insufficient. It does not explain that only eventId is required, that other fields are optional, or how updates behave. This is incomplete for a complex update tool.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond what the input schema already provides for each parameter.

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?

The description 'Update an existing calendar event' clearly states the verb and resource. It distinguishes from sibling tools like 'create_calendar_event' and 'delete_calendar_event'. However, it does not specify the scope of updates or that it is a partial update.

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 is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., authentication) or exclusion criteria. The sibling tools include authentication steps, but the description offers no context.

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. Dates show when Glama detected each change.

6 tool updatesv1.0.0May 31, 2026
- First observedauthenticate_google_calendar
- First observedcreate_calendar_event
- First observeddelete_calendar_event
- First observedlist_calendar_events
- First observedsave_auth_token
- First observedupdate_calendar_event

Install Server

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

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a distinctly different purpose: two for authentication flow and four for CRUD operations on calendar events. There is no overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., authenticate_google_calendar, create_calendar_event, save_auth_token). The pattern is predictable and clear.

Tool Count5/5

With 6 tools, the server is well-scoped. It includes necessary authentication tools and core CRUD operations for calendar events without unnecessary extras.

Completeness4/5

The server covers the essential CRUD cycle (create, read via list, update, delete) plus authentication. However, it lacks a dedicated tool to retrieve a single event by ID, relying on list for that purpose.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Chronary A
ai.chronary
Calendar API for AI agents: events, availability, Google/Microsoft setup, scheduling, and iCal.
Calendar Management Workplace & Productivity
542
mayla-debug-mcp-google-calendar2
ai.smithery
Schedule and manage Google Calendar events directly from your workspace. Check availability, view…
Calendar Management App Automation
2
Kalender Sync A
de.kalender-sync
GDPR-compliant calendar access for AI assistants. Google, Microsoft 365, Apple & more. EU-hosted.
Calendar Management Workplace & Productivity
71
google-workspaceOAuth
com.proscendia
Permissioned access to Gmail, Drive and Calendar via the user's own Google account
Email Cloud Storage Calendar Management
1

Related MCP Servers

Google Calendar MCP Server
Calendar Management Workplace & Productivity
kayesFerdous
F
license
Not graded
quality
D
maintenance
Enables interaction with Google Calendar through OAuth 2.0 authentication. Supports listing, creating, and deleting calendar events with timezone handling and RFC3339 date formatting.
Updated a year ago (2025-08-08 09:28 UTC)
-
Google Calendar MCP Server
Calendar Management App Automation Workplace & Productivity
YusukeYoshiyama
F
license
Not graded
quality
D
maintenance
Enables interaction with Google Calendar through the Google Calendar API. Supports listing calendars, creating/deleting events, and retrieving calendar events with OAuth2 authentication.
Updated a year ago (2025-10-08 11:07 UTC)
-
Google Calendar MCP Server
Calendar Management App Automation Workplace & Productivity
goldk3y
F
license
Not graded
quality
D
maintenance
Enables interaction with Google Calendar through OAuth2 authentication, supporting calendar and event management including creating, updating, deleting events with attendees, reminders, and search functionality.
Updated a year ago (2025-07-04 08:34 UTC)
1
-
Google Calendar MCP Server
Calendar Management App Automation
bezael
F
license
Not graded
quality
D
maintenance
Enables language models to interact with Google Calendar through OAuth2 authentication, allowing creation, retrieval, listing, updating, and deletion of calendar events.
Updated 9 months ago (2025-11-29 10:45 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nkriman/mcp-google-calendar-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server