This Google Workspace MCP Server enables programmatic management of Gmail and Calendar through the Model Context Protocol (MCP).
Gmail capabilities:
List recent emails with optional filtering
Search emails using advanced Gmail query syntax
Send emails with support for CC and BCC recipients
Modify email labels (e.g., archive, trash, mark read/unread)
Calendar capabilities:
List upcoming calendar events with date range filtering
Create new calendar events with attendees
Update existing calendar events
Delete calendar events
Provides tools for listing, searching, sending, and modifying emails, including support for managing labels, attachments, and email filtering
Enables creating, listing, updating, and deleting calendar events with support for attendees, date range filtering, and event management
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Google Workspace MCP Server list my upcoming meetings for today"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides tools for interacting with Gmail and Calendar APIs. This server enables you to manage your emails and calendar events programmatically through the MCP interface.
list_emails: List recent emails from your inbox with optional filtering
search_emails: Advanced email search with Gmail query syntax
send_email: Send new emails with support for CC and BCC
modify_email: Modify email labels (archive, trash, mark read/unread)
list_events: List upcoming calendar events with date range filtering
create_event: Create new calendar events with attendees
update_event: Update existing calendar events
delete_event: Delete calendar events
Related MCP server: Gmail AutoAuth MCP Server
Node.js: Install Node.js version 14 or higher
Google Cloud Console Setup:
Go to Google Cloud Console
Create a new project or select an existing one
Enable the Gmail API and Google Calendar API:
Go to "APIs & Services" > "Library"
Search for and enable "Gmail API"
Search for and enable "Google Calendar API"
Set up OAuth 2.0 credentials:
Go to "APIs & Services" > "Credentials"
Click "Create Credentials" > "OAuth client ID"
Choose "Web application"
Set "Authorized redirect URIs" to include: http://localhost:4100/code
Note down the Client ID and Client Secret
To install gsuite-mcp for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @rishipradeep-think41/gsuite-mcp --client claudeClone and Install:
git clone https://github.com/epaproditus/google-workspace-mcp-server.git
cd google-workspace-mcp-server
npm installCreate OAuth Credentials:
Create a credentials.json file in the root directory:
{
"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"
}
}Get Refresh Token:
node get-refresh-token.jsThis will:
Open your browser for Google OAuth authentication
Request the following permissions:
https://www.googleapis.com/auth/gmail.modify
https://www.googleapis.com/auth/calendar
https://www.googleapis.com/auth/gmail.send
Save the credentials to token.json
Display the refresh token in the console
Configure MCP Settings: Add the server configuration to your MCP settings file:
For VSCode Claude extension: ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
For Claude desktop app: ~/Library/Application Support/Claude/claude_desktop_config.json
Add this to the mcpServers object:
{
"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"
}
}
}
}Build and Run:
npm run buildList Recent Emails:
{
"maxResults": 5,
"query": "is:unread"
}Search Emails:
{
"query": "from:example@gmail.com has:attachment",
"maxResults": 10
}Send Email:
{
"to": "recipient@example.com",
"subject": "Hello",
"body": "Message content",
"cc": "cc@example.com",
"bcc": "bcc@example.com"
}Modify Email:
{
"id": "message_id",
"addLabels": ["UNREAD"],
"removeLabels": ["INBOX"]
}List Events:
{
"maxResults": 10,
"timeMin": "2024-01-01T00:00:00Z",
"timeMax": "2024-12-31T23:59:59Z"
}Create Event:
{
"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"]
}Update Event:
{
"eventId": "event_id",
"summary": "Updated Meeting Title",
"location": "Virtual",
"start": "2024-01-24T11:00:00Z",
"end": "2024-01-24T12:00:00Z"
}Delete Event:
{
"eventId": "event_id"
}Authentication Issues:
Ensure all required OAuth scopes are granted
Verify client ID and secret are correct
Check if refresh token is valid
API Errors:
Check Google Cloud Console for API quotas and limits
Ensure APIs are enabled for your project
Verify request parameters match the required format
This project is licensed under the MIT License.
Create a new calendar event
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
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. While 'Create' implies a write operation, it doesn't mention permission requirements, whether the event becomes immediately visible to attendees, if notifications are sent, or what happens on validation errors. This leaves significant behavioral gaps 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - a single sentence that states the core purpose without any wasted words. It's front-loaded with the essential information and doesn't include unnecessary elaboration.
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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after creation, what the return value might be, error conditions, or how this tool relates to its siblings. The agent would need to guess about important behavioral aspects.
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?
The schema description coverage is 100%, with all parameters well-documented in the schema itself. The description adds no additional parameter information beyond what's already in the structured schema, so it meets the baseline expectation but doesn't provide extra value.
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 action ('Create') and resource ('calendar event'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'update_event' or explain what distinguishes creation from modification in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool versus alternatives like 'update_event' or 'list_events'. There's no mention of prerequisites, constraints, or typical use cases for creating versus modifying calendar events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a calendar event
| Name | Required | Description | Default |
|---|---|---|---|
| eventId | Yes | Event ID to delete |
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 states the action ('Delete') but lacks critical details: it doesn't specify if deletion is permanent or reversible, mention authentication requirements, warn about side effects, or describe error handling. This is inadequate for a destructive operation with zero annotation coverage.
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 a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential information without redundancy.
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 destructive tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permanence or permissions, return values, or error cases. Given the complexity of deletion operations and lack of structured data, more context is needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'eventId' documented as 'Event ID to delete'. The description adds no additional meaning beyond this, such as format examples or sourcing instructions. Baseline 3 is appropriate since the schema already fully describes the parameter.
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 'Delete a calendar event' clearly states the verb ('Delete') and resource ('calendar event'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'update_event' or 'create_event' beyond the basic action, missing specific scope details that would distinguish it more clearly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing event ID), exclusions (e.g., not for modifying events), or refer to sibling tools like 'update_event' for non-destructive changes, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent emails from Gmail inbox
| Name | Required | Description | Default |
|---|---|---|---|
| maxResults | No | Maximum number of emails to return (default: 10) | |
| query | No | Search query to filter emails |
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 states the tool lists emails but doesn't describe what 'recent' means (e.g., time frame), whether it requires authentication, how results are ordered, or any rate limits. This leaves significant gaps in understanding 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.
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?
Given the lack of annotations and output schema, the description is incomplete for a tool with parameters and behavioral implications. It doesn't explain what 'recent' entails, the format of returned emails, or error conditions, leaving the agent with insufficient context for reliable use.
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?
The schema description coverage is 100%, with clear documentation for both parameters ('maxResults' and 'query'). The description doesn't add any parameter-specific details beyond what the schema provides, so it meets the baseline for high schema coverage without compensating value.
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 action ('List') and resource ('recent emails from Gmail inbox'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_emails' or 'modify_email', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_emails' or 'modify_email'. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List upcoming calendar events
| Name | Required | Description | Default |
|---|---|---|---|
| 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) |
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. 'List upcoming calendar events' implies a read-only operation but doesn't specify authentication requirements, rate limits, pagination behavior, or what happens when no events match criteria. For a tool with 3 parameters and no output schema, this leaves significant behavioral gaps.
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 a single, efficient sentence with zero wasted words. It's appropriately sized for a straightforward list operation and front-loads the essential information without unnecessary elaboration.
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 tool with 3 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain return format, error conditions, or how the 'upcoming' scope relates to the time parameters. The agent would need to guess about important behavioral aspects despite having a clear but minimal purpose statement.
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?
The description mentions 'upcoming' which implies future events, but doesn't explicitly connect this to the timeMin/timeMax parameters. With 100% schema description coverage, the schema already documents all 3 parameters thoroughly, so the description adds minimal value beyond what's in the structured fields. The baseline of 3 is appropriate when schema does the heavy lifting.
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 'List upcoming calendar events' clearly states the verb ('List') and resource ('upcoming calendar events'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'update_event' or other event-related tools, which would require mentioning specific scope or filtering characteristics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'create_event', 'delete_event', or 'update_event'. There's no mention of prerequisites, appropriate contexts, or exclusions, leaving the agent with minimal usage direction beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modify email labels (archive, trash, mark read/unread)
| Name | Required | Description | Default |
|---|---|---|---|
| addLabels | No | Labels to add | |
| id | Yes | Email ID | |
| removeLabels | No | Labels to remove |
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 mentions modifying labels but doesn't specify whether this is a destructive operation (e.g., archiving or trashing emails), what permissions are required, rate limits, or the response format. The examples (archive, trash) hint at potential destructive actions, but this isn't clearly stated, leaving gaps in transparency 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action (modify email labels) with illustrative examples. There's no wasted verbiage, and it directly communicates the tool's function without unnecessary elaboration.
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?
Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It lacks details on behavioral traits (e.g., destructiveness, auth needs), response expectations, and usage context. While the schema covers parameters well, the overall context for safe and effective use is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (id, addLabels, removeLabels) with clear descriptions. The description adds minimal value by implying label types (e.g., archive, trash) but doesn't provide additional syntax, format details, or constraints beyond what the schema offers. This meets the baseline for high schema coverage.
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's purpose as modifying email labels with specific examples (archive, trash, mark read/unread). It distinguishes from siblings like list_emails or send_email by focusing on label modification rather than listing, searching, or sending. However, it doesn't explicitly differentiate from potential label-specific siblings that might not exist in the current set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an email ID from list_emails), exclusions (e.g., not for modifying email content), or comparisons with other tools like search_emails for finding emails first. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search emails with advanced query
| 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"). Examples: - "from:alice@example.com" (Emails from Alice) - "to:bob@example.com" (Emails sent to Bob) - "subject:Meeting Update" (Emails with "Meeting Update" in the subject) - "has:attachment filename:pdf" (Emails with PDF attachments) - "after:2024/01/01 before:2024/02/01" (Emails between specific dates) - "is:unread" (Unread emails) - "from:@company.com has:attachment" (Emails from a company domain with attachments) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool searches emails but doesn't mention whether this is a read-only operation, if it requires specific permissions, how results are returned (e.g., pagination), or any rate limits. The description adds minimal behavioral context beyond the basic action.
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 a single, efficient sentence that front-loads the core purpose ('Search emails with advanced query'). It avoids redundancy and wastes no words, making it highly concise and well-structured for quick understanding.
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?
Given the tool's moderate complexity (search with query parameters), no annotations, and no output schema, the description is minimally adequate. It covers the basic action but lacks details on behavioral traits, usage context, and return values, leaving gaps that could hinder an agent's effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed examples for the 'query' parameter and a clear description for 'maxResults'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for adequate coverage without extra value.
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's purpose as 'Search emails with advanced query', which specifies the verb (search) and resource (emails). It distinguishes from siblings like 'list_emails' by emphasizing 'advanced query' capabilities, though it doesn't explicitly contrast with 'list_emails' which might be a simpler listing 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?
The description provides no guidance on when to use this tool versus alternatives like 'list_emails' or 'modify_email'. It mentions 'advanced query' but doesn't specify scenarios where this is preferred over simpler tools or when not to use it, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a new email
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
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. 'Send a new email' implies a write operation but doesn't specify critical behaviors: whether it requires authentication, has rate limits, supports attachments, confirms delivery, or handles errors. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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 extremely concise at three words, with no wasted language. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place by conveying essential purpose without redundancy.
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?
Given the tool's complexity (a write operation with 5 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like side effects, error handling, or return values, which are crucial for an agent to use the tool effectively. The high schema coverage helps with inputs but doesn't compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all parameters (to, subject, body, cc, bcc) are documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. This meets the baseline of 3 for high schema coverage, but doesn't compensate with extra value.
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 'Send a new email' clearly states the action (send) and resource (email), with 'new' distinguishing it from modifying existing emails. However, it doesn't explicitly differentiate from sibling tools like 'modify_email' or 'list_emails', which would require more specific language about creating versus updating versus reading emails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing recipient addresses), exclusions (e.g., not for bulk sends), or comparisons to siblings like 'modify_email' for editing existing emails or 'list_emails' for viewing emails. This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing calendar event
| Name | Required | Description | Default |
|---|---|---|---|
| attendees | No | New list of attendee email addresses | |
| description | No | New event description | |
| end | No | New end time in ISO format | |
| eventId | Yes | Event ID to update | |
| location | No | New event location | |
| start | No | New start time in ISO format | |
| summary | No | New event title |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's an update operation without disclosing behavioral traits. It doesn't mention permission requirements, whether changes are reversible, rate limits, or what happens to unspecified fields (partial vs. full updates). This is inadequate for a mutation tool with zero annotation coverage.
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 a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.
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 mutation tool with 7 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral nuances, leaving significant gaps despite the good schema coverage. More context is needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond implying an 'eventId' is needed (implied by 'existing'), which is already covered in the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
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 verb ('Update') and resource ('an existing calendar event'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'modify_email' or specify what aspects of the event can be updated beyond the generic term.
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 is provided on when to use this tool versus alternatives like 'create_event' or 'delete_event'. The description lacks context about prerequisites (e.g., needing an existing event ID) or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every tool has a clearly distinct purpose with no ambiguity. Calendar tools (create_event, delete_event, list_events, update_event) and email tools (list_emails, modify_email, search_emails, send_email) are cleanly separated by resource type and action, making misselection unlikely.
All tools follow a consistent verb_noun pattern with snake_case throughout. The naming is predictable and readable, with clear action verbs (create, delete, list, modify, search, send, update) paired with appropriate nouns (event, emails).
With 8 tools, this server is well-scoped for Google Workspace functionality. The count is appropriate, covering core calendar and email operations without being overwhelming or too sparse, with each tool earning its place.
The tool surface provides good coverage for calendar and email workflows, with CRUD operations for events and key email actions. Minor gaps exist, such as no direct email deletion tool (though modify_email handles archiving/trashing) and no calendar search, but agents can work around these.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Hosted Google Calendar MCP server for AI agents. No self-hosting or Google Cloud setup.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Email infrastructure for AI agents — send, receive, search, and reply to email over MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rishipradeep-think41/gsuite-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
