Manages Google Calendar reminders with support for time-based and location-based triggers, including creating, listing, and deleting reminders.
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., "@gcalendar-mcp remind me tomorrow at 9am to call mom"
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.
An MCP (Model Context Protocol) server for managing Google Calendar reminders with support for time-based and location-based triggers.
Time-based reminders: "Remind me tomorrow at 9am to call mom"
Location-based reminders: "Remind me to go to store X when I'm near Hashalom street in Tel Aviv"
List reminders: View upcoming reminders
Delete reminders: Remove reminders by ID
Related MCP server: GoogleCalendarMCP
Python 3.11+
uv package manager
Google Cloud project with Calendar API enabled
uv syncGo to Google Cloud Console
Create a new project or select an existing one
Enable the Google Calendar API:
Go to "APIs & Services" > "Library"
Search for "Google Calendar API"
Click "Enable"
Create OAuth 2.0 credentials:
Go to "APIs & Services" > "Credentials"
Click "Create Credentials" > "OAuth client ID"
Choose "Desktop app" as the application type
Download the credentials JSON file
Save the credentials file:
mkdir -p ~/.config/gcalendar-mcp
mv ~/Downloads/client_secret_*.json ~/.config/gcalendar-mcp/credentials.jsonRun the server once to authenticate:
uv run gcalendar-mcpThis will open a browser window for Google OAuth. After authorizing, your credentials will be saved.
Add to your Claude Code MCP configuration (~/.claude/claude_desktop_config.json):
{
"mcpServers": {
"gcalendar": {
"command": "uv",
"args": ["run", "--directory", "/path/to/gcalendar_mcp", "gcalendar-mcp"]
}
}
}Create a time-based reminder.
Parameters:
title (required): What to be reminded about
time (required): When to remind (natural language supported)
description (optional): Additional notes
Examples:
"remind me tomorrow at 9 to call mom"
"remind me in 2 hours to take a break"
"remind me today at 3pm to join the meeting"
Create a location-based reminder.
Parameters:
title (required): What to be reminded about
location (required): The location/address
description (optional): Additional notes
date (optional): Date for the reminder
Examples:
"remind me to buy milk when near the grocery store"
"remind me to go to store X when I'm near Hashalom street in Tel Aviv"
Note: Google Calendar doesn't natively support location-based triggers. This creates an event with the location noted. For automatic location notifications, use Google Maps or a dedicated location reminder app.
List upcoming reminders from the calendar.
Parameters:
max_results (optional): Maximum number of results (default: 10)
Delete a reminder by its event ID.
Parameters:
event_id (required): The ID of the event to delete
You can customize the credentials directory by setting the environment variable:
export GCALENDAR_MCP_CONFIG_DIR=/path/to/custom/config# Install dev dependencies
uv sync --dev
# Run tests
uv run pytestMIT
Create a location-based reminder in Google Calendar. Examples: 'remind me to buy milk when near the grocery store', 'remind me to go to store X when I'm near Hashalom street in Tel Aviv'
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Optional date for the reminder (default: today) | |
| title | Yes | What to be reminded about (e.g., 'buy milk', 'pick up package') | |
| location | Yes | The location/address that triggers the reminder (e.g., 'Hashalom Street, Tel Aviv', 'Central Station') | |
| description | No | Optional additional notes or details |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'create' without disclosing behavioral traits such as required permissions, side effects, or return behavior. Examples add context but do not compensate for the lack of transparency about the tool's actions.
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 concise (two sentences plus examples) and front-loaded with purpose. Examples are relevant but slightly lengthy; no superfluous text.
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?
The description explains what the tool does and gives usage examples, but it omits what the tool returns (e.g., success indication, created object) and does not discuss error cases. For a creation tool with no output schema, this is a moderate gap.
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 coverage is 100%, so the schema already documents all parameters. The description provides examples that illustrate parameter usage but does not add new semantics beyond the schema descriptions.
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 tool creates a 'location-based reminder in Google Calendar,' with specific examples that distinguish it from time-based reminders (sibling create_time_reminder). The verb 'create' and resource 'location-based reminder' are specific.
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 implies usage for location-based reminders versus time-based alternatives (sibling create_time_reminder) through the phrase 'location-based' and examples. However, it does not explicitly state when not to use or name alternatives, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a time-based reminder in Google Calendar. Examples: 'remind me tomorrow at 9 to call mom', 'remind me in 2 hours to take a break'
| Name | Required | Description | Default |
|---|---|---|---|
| time | Yes | When to remind. Supports natural language like 'tomorrow at 9am', 'in 2 hours', 'today at 3pm', or specific dates like '2024-01-15 14:30' | |
| title | Yes | What to be reminded about (e.g., 'call mom', 'take medicine') | |
| description | No | Optional additional notes or details |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose side effects, permissions, or response. It only states creation, which is minimally adequate for a simple tool.
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?
Two sentences plus examples; no wasted words. Front-loaded with purpose, then examples. Highly efficient.
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 simple creation tool with no output schema, the description and schema cover purpose and parameters adequately. Missing return value info, but overall complete.
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 coverage is 100% with good descriptions for each parameter. The description adds no new semantic info beyond what the schema provides, meeting baseline.
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 'Create a time-based reminder in Google Calendar' with specific verb and resource. Examples reinforce purpose and distinguish from sibling tools like create_location_reminder.
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?
Examples provide context for when to use (time-based reminders), but no explicit exclusion of location-based reminders or alternatives beyond the sibling tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a reminder from Google Calendar by its event ID
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | The ID of the event/reminder to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must provide behavioral context. It implies a destructive action but does not disclose permanence, error handling, authorization needs, or side effects. The description is too minimal.
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?
Single sentence, front-loaded, no wasted words. Highly concise and easy to parse.
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 simple one-parameter delete tool, the description is adequate but incomplete. It does not explain the outcome (e.g., success, no return value) or error cases, which would be helpful given no output schema.
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 coverage is 100%, and the schema already describes event_id. The description adds no new semantics beyond restating 'by its event ID'. Baseline score of 3 is appropriate.
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?
Description clearly states the verb 'Delete' and the resource 'reminder from Google Calendar' with the method 'by its event ID'. It is unambiguous and distinct from sibling tools (create, list), though it does not explicitly differentiate itself.
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?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or context that would help an agent decide between deleting a reminder and using other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List upcoming reminders and events from Google Calendar
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | Maximum number of reminders to show (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fails to mention authentication requirements, whether reminders are filtered to future only, or the output format. The term 'upcoming' is vague.
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?
Single sentence, no fluff. Could include more context but still concise and front-loaded with action and resource.
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?
Simple tool with one optional parameter, no output schema. Description is minimal but adequate for a list operation, though it omits details about return type and scope.
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 coverage is 100% with a clear description for max_results. The tool description adds no extra parameter meaning, so baseline 3 is appropriate.
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?
Clearly states it lists upcoming reminders and events from Google Calendar. The verb 'list' and resource are explicit. Sibling tools are all create/delete, so it stands out as the sole list tool.
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?
No explicit when-not-to-use or alternatives, but since siblings are all create/delete, there is no ambiguity. The description implies using this to view reminders.
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.0create_location_remindercreate_time_reminderdelete_reminderlist_remindersScored across 4 tools
Each tool has a clearly distinct purpose: creating location-based reminders, creating time-based reminders, deleting reminders, and listing reminders. There is no overlap or ambiguity.
All tools follow a consistent verb_noun pattern with lowercase snake_case (create_location_reminder, create_time_reminder, delete_reminder, list_reminders). No deviations.
With 4 tools covering creation (two types), deletion, and listing, the set is well-scoped for a reminder management server. Each tool adds clear value.
Core operations are present, but an update tool for modifying reminders is missing, which agents may need. This is a minor gap given the scope.
A MCP server that works with Google Calendar to manage event listing, reading, and updates.
Hosted Google Calendar MCP server for AI agents. No self-hosting or Google Cloud setup.
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.
MCP server for Cronofy — read calendars, events and free/busy, and create, update or delete events.
