en es ja ko zh

Google Calendar - No deletion

Name: Google Calendar - No deletion
Author: erickva

by erickva

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

Servidor MCP de Google Workspace

Un servidor de Protocolo de Contexto de Modelo (MCP) que proporciona herramientas para interactuar con las API de Gmail y Calendario. Este servidor permite gestionar los correos electrónicos y eventos del calendario mediante programación a través de la interfaz MCP.

Características

Herramientas de Gmail

list_emails : enumera los correos electrónicos recientes de tu bandeja de entrada con filtrado opcional
search_emails : Búsqueda avanzada de correo electrónico con sintaxis de consulta de Gmail
send_email : Envía nuevos correos electrónicos con soporte para CC y CCO
modify_email : Modificar las etiquetas de correo electrónico (archivar, papelera, marcar como leído/no leído)

Herramientas de calendario

list_events : enumera los próximos eventos del calendario con filtrado de rango de fechas
create_event : Crea nuevos eventos de calendario con asistentes
Los eventos a continuación se eliminaron de este servidor por medidas de seguridad, ya que la API de Google Cloud Calendar no tiene un alcance que permita la creación pero impida la eliminación o las actualizaciones.
update_event : Actualizar los eventos del calendario existentes
delete_event : Eliminar eventos del calendario

Related MCP server: google-workspace-mcp-server

Prerrequisitos

Node.js : Instale Node.js versión 14 o superior
Configuración de la consola de Google Cloud :
- Ir a la consola de Google Cloud
- Crea un nuevo proyecto o selecciona uno existente
- Habilitar la API de Gmail y la API de Google Calendar:
  1. Vaya a "API y servicios" > "Biblioteca".
  2. Busque y habilite "API de Gmail"
  3. Busque y habilite "API de Google Calendar"
- Configurar las credenciales de OAuth 2.0:
  1. Vaya a "API y servicios" > "Credenciales".
  2. Haga clic en "Crear credenciales" > "ID de cliente OAuth".
  3. Seleccione "Aplicación web"
  4. Establezca "URI de redireccionamiento autorizado" para incluir: http://localhost:4100/code
  5. Anote el ID del cliente y el secreto del cliente

Instrucciones de configuración

Instalación mediante herrería

Para instalar Google Workspace Server - No Calendar Deletion para Claude Desktop automáticamente a través de Smithery :

npx -y @smithery/cli install @erickva/google-workspace-mcp-server-no-calendar-deletetion --client claude

Instalación manual

Clonar e instalar :

git clone https://github.com/epaproditus/google-workspace-mcp-server.git
cd google-workspace-mcp-server
npm install

Crear credenciales de OAuth : cree un archivo credentials.json en el directorio raíz:

{
    "web": {
        "client_id": "YOUR_CLIENT_ID",
        "client_secret": "YOUR_CLIENT_SECRET",
        "redirect_uris": ["http://localhost:4100/code"],
        "auth_uri": "https://accounts.google.com/o/oauth2/auth",
        "token_uri": "https://oauth2.googleapis.com/token"
    }
}

Obtener token de actualización :
```
node get-refresh-token.js
```
Esto hará lo siguiente:
- Abra su navegador para la autenticación de Google OAuth
- Solicitar los siguientes permisos:
  - https://www.googleapis.com/auth/gmail.modify
  - https://www.googleapis.com/auth/calendar
  - https://www.googleapis.com/auth/gmail.send
- Guarde las credenciales en token.json
- Mostrar el token de actualización en la consola
Configurar los ajustes de MCP : agregue la configuración del servidor a su archivo de configuración de MCP:
- Para la extensión Claude de VSCode: ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
- Para la aplicación de escritorio de Claude: ~/Library/Application Support/Claude/claude_desktop_config.json
Agregue esto al objeto mcpServers :
```
{
  "mcpServers": {
    "google-workspace": {
      "command": "node",
      "args": ["/path/to/google-workspace-server/build/index.js"],
      "env": {
        "GOOGLE_CLIENT_ID": "your_client_id",
        "GOOGLE_CLIENT_SECRET": "your_client_secret",
        "GOOGLE_REFRESH_TOKEN": "your_refresh_token"
      }
    }
  }
}
```
Construir y ejecutar :
```
npm run build
```

Ejemplos de uso

Operaciones de Gmail

Lista de correos electrónicos recientes :

{
  "maxResults": 5,
  "query": "is:unread"
}

Buscar correos electrónicos :

{
  "query": "from:example@gmail.com has:attachment",
  "maxResults": 10
}

Enviar correo electrónico :

{
  "to": "recipient@example.com",
  "subject": "Hello",
  "body": "Message content",
  "cc": "cc@example.com",
  "bcc": "bcc@example.com"
}

Modificar correo electrónico :

{
  "id": "message_id",
  "addLabels": ["UNREAD"],
  "removeLabels": ["INBOX"]
}

Operaciones del calendario

Lista de eventos :

{
  "maxResults": 10,
  "timeMin": "2024-01-01T00:00:00Z",
  "timeMax": "2024-12-31T23:59:59Z"
}

Crear evento :

{
  "summary": "Team Meeting",
  "location": "Conference Room",
  "description": "Weekly sync-up",
  "start": "2024-01-24T10:00:00Z",
  "end": "2024-01-24T11:00:00Z",
  "attendees": ["colleague@example.com"]
}

Actualizar evento :

{
  "eventId": "event_id",
  "summary": "Updated Meeting Title",
  "location": "Virtual",
  "start": "2024-01-24T11:00:00Z",
  "end": "2024-01-24T12:00:00Z"
}

Eliminar evento :

{
  "eventId": "event_id"
}

Solución de problemas

Problemas de autenticación :
- Asegúrese de que se concedan todos los ámbitos OAuth necesarios
- Verifique que el ID del cliente y el secreto sean correctos
- Comprobar si el token de actualización es válido
Errores de API :
- Consulta Google Cloud Console para conocer las cuotas y los límites de la API
- Asegúrese de que las API estén habilitadas para su proyecto
- Verificar que los parámetros de la solicitud coincidan con el formato requerido

Licencia

Este proyecto está licenciado bajo la licencia MIT.

Available Tools

7 tools

create_eventC

Create a new calendar event

ParametersJSON Schema

Name	Required	Description
`attendees`	No	List of attendee email addresses
`description`	No	Event description
`end`	Yes	End time in ISO format
`location`	No	Event location
`start`	Yes	Start time in ISO format
`summary`	Yes	Event title

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 full burden of behavioral disclosure. It only states 'create', which implies mutation, but omits details like authorization requirements (e.g., calendar write access), side effects (e.g., notifications to attendees), or whether the event is created immediately. 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 with no extraneous words, which is concise. However, it is too minimal and does not fully earn its place by providing additional context. It could include a brief note on required fields or behavior without significant length increase.

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 complexity (6 parameters, no output schema, no annotations), the description is incomplete. It does not specify return values (e.g., created event ID), constraints (e.g., title length, time range), or error conditions. An agent would lack critical context for successful invocation.

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 baseline is 3. The description adds no extra meaning beyond the schema's property descriptions (e.g., 'Start time in ISO format' already in schema). It does not clarify relationships between parameters or provide usage hints beyond what the schema offers.

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 'Create a new calendar event', specifying the verb 'create' and resource 'calendar event'. It distinguishes from sibling tools like 'update_event' and 'delete_event', which modify or remove existing events. However, it could be more precise about the scope (e.g., single event creation with required fields).

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 such as 'update_event' for modifications or 'list_events' for viewing. The description lacks context about prerequisites or typical scenarios, leaving the agent without decision-making support.

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

list_emailsB

List recent emails from Gmail inbox

ParametersJSON Schema

Name	Required	Description	Default
`maxResults`	No	Maximum number of emails to return (default: 10)
`query`	No	Search query to filter emails

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 carries the full burden of behavioral disclosure. It only states 'list recent emails', omitting crucial details such as required authentication, rate limits, output format (e.g., headers vs full content), and potential side effects.

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 with no wasted words. However, it omits important details that could be included without much expansion, slightly reducing its efficiency.

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 sibling tools (especially 'search_emails'), the description fails to clarify when to use this tool versus searching. It also lacks return value details, pagination, and recency definition, making it incomplete for a tool with no output schema.

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 both parameters described ('query' for filtering, 'maxResults' with default). The description adds no additional meaning beyond what the schema provides, 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 'List recent emails from Gmail inbox', specifying the verb and resource. However, the term 'recent' is vague, and there is no differentiation from the sibling tool 'search_emails' which likely supports similar queries.

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 listing recent emails but does not provide explicit guidance on when to use this tool versus alternatives like 'search_emails' or 'modify_email'. No context on prerequisites or limitations.

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

list_eventsC

List upcoming calendar events

ParametersJSON Schema

Name	Required	Description
`maxResults`	No	Maximum number of events to return (default: 10)
`timeMax`	No	End time in ISO format
`timeMin`	No	Start time in ISO format (default: now)

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 bears full responsibility for behavioral disclosure. It fails to mention sorting order, inclusion of canceled events, pagination behavior, or default time range behavior beyond implying 'upcoming'. The schema covers parameters but not runtime behavior.

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 sentence with no unnecessary words. However, it omits important behavioral context, so it is not perfectly concise for a helpful description. Still, it is efficiently brief.

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, the description could have explained the return format or common use cases. It also fails to mention that timeMin can be set in the past, contradicting 'upcoming'. The tool is simple but the description lacks completeness 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 description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema, but since the schema is sufficient, this score 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 'List upcoming calendar events' clearly states the action (list) and resource (calendar events). However, 'upcoming' may be misleading since the tool can list events in any time range via parameters. It distinguishes from siblings implicitly as there is no other event list tool.

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 like create_event, update_event, or delete_event. The description does not indicate that this is a read-only operation or that for email lists one should use list_emails.

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

meeting_suggestionC

Suggest available meeting slots within the next 30 days

ParametersJSON Schema

Name	Required	Description
`bankHolidays`	No	List of bank holiday dates in YYYY-MM-DD format
`calendarIds`	No	List of Google Calendar IDs (default: ["primary"])
`daysToSearch`	No	Number of days to find slots for (default: 3)
`meetingLengthMinutes`	No	Meeting length in minutes (default: 60)
`slotsPerDay`	No	Number of slots per day to suggest (default: 1)
`timezone`	No	Timezone for scheduling (default: America/Sao_Paulo)
`workingHoursEnd`	No	End of working hours (24h format, default: 17)
`workingHoursStart`	No	Start of working hours (24h format, default: 9)

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 full burden for behavioral disclosure. It mentions the 30-day constraint but doesn't explain what 'suggest' entails (e.g., how slots are determined, whether it considers existing events, authentication needs, rate limits, or what the output looks like). For a tool with 8 parameters and no annotation coverage, this leaves significant gaps.

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 a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized and front-loaded with the core functionality.

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?

For a tool with 8 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the suggestion algorithm, how parameters interact, what the return format is, or error conditions. The 30-day mention provides some context but doesn't compensate for the missing behavioral and output information.

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?

The description doesn't add any parameter-specific information beyond what's already in the schema (which has 100% coverage). It mentions 'within the next 30 days' which relates to the time scope but doesn't clarify how this interacts with parameters like 'daysToSearch'. Baseline 3 is appropriate since the schema does the heavy lifting.

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 tool's purpose: 'Suggest available meeting slots within the next 30 days' - a specific verb ('suggest') and resource ('meeting slots') with a time constraint. However, it doesn't differentiate from sibling tools like 'create_event' or 'list_events' which handle different calendar operations, so it doesn't fully distinguish itself.

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. It doesn't mention sibling tools like 'create_event' for scheduling meetings or 'list_events' for viewing existing ones, nor does it specify prerequisites or contextual constraints for slot suggestion.

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

modify_emailA

Modify email labels (archive, trash, mark read/unread)

ParametersJSON Schema

Name	Required	Description
`addLabels`	No	Labels to add
`id`	Yes	Email ID
`removeLabels`	No	Labels to remove

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states 'Modify email labels' without disclosing side effects, idempotency, exact label behavior (e.g., archive meaning removing INBOX), 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.

Conciseness5/5

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

Extremely concise single sentence, front-loaded with the action, no wasted words.

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?

Adequate for a simple mutation tool with 3 params and no output schema; covers the main purpose but lacks detail on error handling or return behavior.

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?

Schema coverage is 100%, and the description adds value by giving concrete label examples (archive, trash, mark read/unread) beyond the generic schema descriptions, though exact label names are not specified.

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 email labels, with concrete examples (archive, trash, mark read/unread), distinguishing it from sibling tools like list_emails or send_email.

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 siblings (e.g., list_emails or search_emails) or any prerequisites, leaving the agent to infer usage context without support.

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

search_emailsC

Search emails with advanced query

ParametersJSON Schema

Name	Required	Description	Default
`maxResults`	No	Maximum number of emails to return (default: 10)
`query`	Yes	Gmail search query (e.g., "from:example@gmail.com has:attachment")

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 full responsibility for disclosing behavioral traits. It only states the purpose, omitting details like read-only nature, pagination behavior, or rate limits. The tool name implies a read operation, but no explicit confirmation is given.

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, efficient sentence with no wasted words. It is front-loaded with the core purpose, but it could be slightly more structured (e.g., including output behavior) 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?

Given the absence of an output schema, the description should at least hint at what the tool returns (e.g., a list of email objects). It does not mention return format, pagination details, or error conditions, leaving the agent with incomplete information for a simple search 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?

The input schema already provides detailed descriptions for both parameters (query and maxResults) with examples and defaults, achieving 100% coverage. The tool description adds no further semantic value beyond the schema, meeting the baseline for adequate coverage.

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 'Search emails with advanced query' clearly states the action (search) and resource (emails), and the phrase 'advanced query' hints at the query parameter's capabilities. However, it does not explicitly differentiate from sibling tools like 'list_emails', leaving room for ambiguity.

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 such as 'list_emails' or 'modify_email'. The description lacks any context about appropriate scenarios, prerequisites, or exclusions, leaving the agent without decision support.

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

send_emailC

Send a new email

ParametersJSON Schema

Name	Required	Description
`bcc`	No	BCC recipients (comma-separated)
`body`	Yes	Email body (can include HTML)
`cc`	No	CC recipients (comma-separated)
`subject`	Yes	Email subject
`to`	Yes	Recipient email address

TDQS

C2.8/5.0

Behavior2/5

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

The description lacks disclosure of side effects (e.g., sending is a write operation) or other behaviors like authentication, rate limits, or delivery guarantees. Since no annotations are present, the description carries full burden but fails to inform beyond the obvious.

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 minimal (one sentence), which is concise but not well-structured. It lacks front-loading of key information and does not earn its brevity by covering essential details.

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?

With no output schema, the description does not explain return values or error states. For a tool with 5 parameters and no nested objects, more context about the sending process (e.g., confirmation, async) would improve completeness.

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 adds no additional meaning beyond what is already in the schema, so the baseline score of 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 'Send a new email' clearly identifies the action (send) and resource (email), distinguishing it from siblings like list_emails, modify_email, and search_emails. However, 'new' adds minor value; overall it is clear but not exceptionally specific.

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 such as modify_email (which might handle drafts or edits). There is no mention of prerequisites, limitations, or when not to use it.

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 updatesv1.0.0Apr 9, 2025
- First observedcreate_event
- First observedlist_emails
- First observedlist_events
- First observedmeeting_suggestion
- First observedmodify_email
- First observedsearch_emails
- First observedsend_email

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.6/5.0

Scored 2026-04-18 10:35 across 7 tools

Disambiguation2/5

The tool set mixes calendar and email operations without clear boundaries, causing potential misselection. For example, 'list_emails' and 'search_emails' overlap in purpose for email retrieval, while calendar tools like 'create_event' and 'list_events' are distinct but the server's dual-domain focus creates confusion.

Naming Consistency3/5

Naming conventions are mixed, with some tools using verb_noun patterns like 'create_event' and others using noun_verb like 'meeting_suggestion'. While readable, the inconsistency in structure (e.g., 'modify_email' vs. 'send_email') deviates from a predictable pattern.

Tool Count3/5

With 7 tools, the count is reasonable, but it feels borderline due to the server's split focus on both Google Calendar and Gmail. This scope might be too broad for the limited tool set, leading to a thin coverage in each domain.

Completeness2/5

For the implied dual-domain purpose, there are significant gaps. In calendar, tools lack update or delete event operations, and in email, there's no way to delete emails or manage drafts. The server name suggests calendar focus, but email tools are included without full lifecycle coverage.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

google-mcp
io.github.matiasbattocchia
Streamable HTTP MCP server for Google Calendar and Sheets with OAuth login.
Calendar Management Cloud Platforms Workplace & Productivity
25
gcal AOAuth
com.mintmcp
A MCP server that works with Google Calendar to manage event listing, reading, and updates.
Calendar Management App Automation
728
Cronofy MCP by usefulapi A
io.usefulapi
MCP server for Cronofy — read calendars, events and free/busy, and create, update or delete events.
Calendar Management Workplace & Productivity
82
CalendarMCP
ai.calendarmcp
Hosted Google Calendar MCP server for AI agents. No self-hosting or Google Cloud setup.
Calendar Management Workplace & Productivity
2

Related MCP Servers

Google Workspace MCP Server -
Cloud Platforms Developer Tools Workplace & Productivity
taylorwilsdon
A
license
B
quality
A
maintenance
Google Workspace MCP Server
Updated 4 days ago (2026-10-09 13:06 UTC)
120
59,049 PyPI
3,314
Python
MIT
google-workspace-mcp-server
Workplace & Productivity Email Calendar Management
EveryInc
A
license
A
quality
D
maintenance
MCP server for Google Workspace APIs - Docs, Sheets, Drive, Gmail, and Calendar. Enables reading, creating, and editing Google Docs and Sheets, managing comments, reading emails, and viewing calendar events.
Updated 7 months ago (2026-03-10 10:22 UTC)
34
20 npm
17
MIT
google-workspace-mcp-advanced
Workplace & Productivity Communication
Skeptomenos
A
license
B
quality
D
maintenance
Production-ready MCP server for Google Workspace providing broad coverage across Gmail, Drive, Calendar, Docs, Sheets, and more, with safe-by-default write operations and markdown-to-Google-Docs support.
Updated 4 months ago (2026-06-11 17:15 UTC)
100
MIT
GoogleCalendarMCP
Calendar Management Workplace & Productivity
umachandra-30
F
license
D
quality
D
maintenance
MCP server for interacting with Google Calendar, enabling reading events from public calendars and, with OAuth, creating, updating, and deleting events.
Updated 4 months ago (2026-06-19 06:07 UTC)
1
-

Appeared in Searches

A service for adding events to Google Calendar