Which integrations are available for this server?

Allows listing, reading, searching, and sending emails through the Gmail API. Allows listing calendars (including shared), listing events, and creating events with timezone support. Provides file management capabilities (coming soon).

How do I use mcp-server-google-workspace?

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

by iskifogl

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

MCP Server - Google Workspace

License: MIT

A Model Context Protocol (MCP) server for Google Workspace integration, providing tools for Gmail, Google Calendar, and Google Drive access.

Features

🔐 Simple Authentication: Environment variable based credentials
📧 Gmail: List, read, search, and send emails
📅 Calendar: List calendars (including shared), list and create events in any accessible calendar
📁 Drive: File management (coming soon)
🔄 Auto Token Refresh: Automatic OAuth token refresh
🏢 Multi-User Support: Host applications can decrypt and inject user-specific credentials
🤝 Shared Calendar Support: Access and manage events in calendars shared with you

Related MCP server: Google Workspace MCP Server

Installation

For Individual Use

npm install mcp-server-google-workspace
# or
pnpm add mcp-server-google-workspace

For Development

git clone <repo-url>
cd mcp-server-google-workspace
pnpm install
pnpm build

Authentication

The MCP server reads Google OAuth credentials from environment variables:

# .env
GOOGLE_CLIENT_ID=your_client_id
GOOGLE_CLIENT_SECRET=your_client_secret
GOOGLE_REFRESH_TOKEN=your_refresh_token
GOOGLE_ACCESS_TOKEN=your_access_token  # optional

Multi-User Platforms

For platforms serving multiple users, the host application should:

Fetch encrypted credentials from database
Decrypt credentials (e.g., using AWS KMS)
Pass decrypted credentials as environment variables when starting the MCP server

This keeps the MCP server simple and delegates credential management to the host application.

Available Tools

Gmail Tools

`gmail_list_emails`

List recent emails from Gmail inbox.

Parameters:

hours (number, optional): Hours to look back (default: 24)
maxResults (number, optional): Max emails to return (default: 50)
query (string, optional): Gmail search query

Example:

{
  "hours": 168,
  "maxResults": 50,
  "query": "from:boss@company.com"
}

`gmail_read_email`

Read full content of a specific email.

Parameters:

emailId (string, required): Gmail message ID

`gmail_search_emails`

Search emails with Gmail query syntax.

Parameters:

query (string, required): Search query
maxResults (number, optional): Max results (default: 50)

Query Examples:

"from:user@example.com subject:meeting"
"has:attachment after:2025/11/01"
"is:unread label:important"

Calendar Tools

`calendar_list_calendars`

List all accessible calendars, including shared calendars.

Parameters:

showHidden (boolean, optional): Include hidden calendars (default: false)
minAccessRole (string, optional): Minimum access role filter (freeBusyReader, reader, writer, owner)

Example:

{
  "showHidden": false,
  "minAccessRole": "reader"
}

Response: Returns a list of calendars with their IDs, names, access roles, and other metadata. Use the calendar id field for other calendar operations.

`calendar_list_events`

List calendar events for a date range. Returns events with timezone information.

Parameters:

calendarId (string, optional): Calendar ID (default: 'primary'). Use calendar_list_calendars to get IDs of shared calendars.
date (string, optional): Start date (YYYY-MM-DD), default: today
days (number, optional): Number of days (default: 1)
maxResults (number, optional): Max events (default: 50)

Response: Each event includes startTimeZone and endTimeZone fields, making it easy to handle events across different timezones (e.g., ET vs UTC).

`calendar_create_event`

Create a new calendar event with proper timezone support.

Parameters:

calendarId (string, optional): Calendar ID (default: 'primary'). Use calendar_list_calendars to get IDs of shared calendars.
summary (string, required): Event title
start (string, required): Start time (ISO 8601)
end (string, required): End time (ISO 8601)
timeZone (string, optional): IANA timezone (e.g., "America/New_York", "America/Los_Angeles", "UTC"). If not specified, uses the calendar's default timezone.
description (string, optional): Event description
location (string, optional): Event location
attendees (array, optional): Attendee emails

Examples:

Creating event in EST timezone:

{
  "calendarId": "primary",
  "summary": "Team Meeting",
  "start": "2025-11-02T10:00:00",
  "end": "2025-11-02T11:00:00",
  "timeZone": "America/New_York",
  "description": "Quarterly review",
  "attendees": ["team@company.com"]
}

Creating event in UTC (default if not specified):

{
  "summary": "Team Meeting",
  "start": "2025-11-02T15:00:00Z",
  "end": "2025-11-02T16:00:00Z"
}

Usage

With Claude Desktop

Add to your Claude Desktop configuration:

{
  "mcpServers": {
    "google-workspace": {
      "command": "npx",
      "args": ["-y", "mcp-server-google-workspace"],
      "env": {
        "GOOGLE_CLIENT_ID": "your_client_id",
        "GOOGLE_CLIENT_SECRET": "your_client_secret",
        "GOOGLE_REFRESH_TOKEN": "your_refresh_token"
      }
    }
  }
}

Programmatic Usage (e.g., with Claude Agent SDK)

For multi-user platforms, decrypt credentials and inject them when starting the server:

import { Agent } from '@anthropic-ai/claude-agent-sdk';

// Your backend decrypts credentials from database
const credentials = await decryptUserCredentials(userId);

const agent = new Agent({
  mcpServers: [{
    command: 'node',
    args: ['path/to/mcp-server-google-workspace/dist/index.js'],
    env: {
      GOOGLE_CLIENT_ID: credentials.clientId,
      GOOGLE_CLIENT_SECRET: credentials.clientSecret,
      GOOGLE_REFRESH_TOKEN: credentials.refreshToken,
    }
  }]
});

Development

# Install dependencies
pnpm install

# Build
pnpm build

# Watch mode
pnpm watch

# Run locally
pnpm dev

Testing

With MCP Inspector

npx @modelcontextprotocol/inspector node dist/index.js

With Environment Variables

cp .env.example .env
# Edit .env with your credentials
pnpm dev

OAuth Setup

To get Google OAuth credentials:

Go to Google Cloud Console
Create a new project or select existing
Enable Gmail API and Google Calendar API
Create OAuth 2.0 credentials
Add authorized redirect URI
Get client ID and client secret
Use OAuth playground to get refresh token

Contributing

Contributions welcome! Please feel free to submit a Pull Request.

License

MIT

Author

iskifogl

Available Tools

8 tools

calendar_create_eventB

Create a new calendar event with title, time, and optional details. Can create events in any writable calendar.

ParametersJSON Schema

Name	Required	Description	Default
`calendarId`	No	Calendar ID (default: "primary" for your main calendar). Use calendar_list_calendars to get IDs of shared calendars.	primary
`summary`	Yes	Event title/summary
`start`	Yes	Start time in ISO 8601 format (e.g., "2025-11-02T10:00:00Z")
`end`	Yes	End time in ISO 8601 format (e.g., "2025-11-02T11:00:00Z")
`timeZone`	No	IANA timezone (e.g., "America/New_York", "America/Los_Angeles", "Europe/London", "UTC"). If not specified, uses the calendar's default timezone.
`description`	No	Event description (optional)
`location`	No	Event location (optional)
`attendees`	No	Array of attendee email addresses (optional)

TDQS

B3.2/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 disclose behavioral traits. It states the tool creates events (mutation) but does not discuss side effects, required permissions beyond 'writable', rate limits, or what happens on failure. The description is minimal for a creation tool.

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 two sentences, front-loaded with the main action, and contains no unnecessary words. Every sentence adds value.

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

Completeness2/5

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

Despite full schema coverage, the description lacks context on return values, error handling, or default behaviors for optional fields. For a tool with 8 parameters and no output schema, more completeness is needed to fully guide 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 description coverage is 100%, so the baseline is 3. The description summarizes parameters as 'title, time, and optional details' but does not add new meaning beyond the schema. It is adequate but not enhancing.

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 creates a new calendar event, with title, time, and optional details. It explicitly mentions it can create events in any writable calendar, which differentiates it from sibling tools like calendar_list_events (list) or gmail_send_email (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?

The description does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites like write access or conflict handling. The phrase 'any writable calendar' implies a permission requirement but lacks explicit when-to-use or when-not-to-use instructions.

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

calendar_list_calendarsA

List all accessible calendars including shared calendars. Use this to get calendar IDs for other calendar operations.

ParametersJSON Schema

Name	Required	Description	Default
`showHidden`	No	Include hidden calendars (default: false)
`minAccessRole`	No	Minimum access role filter (freeBusyReader, reader, writer, owner)

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It only mentions that the tool lists 'accessible calendars including shared calendars,' which implies a read operation. However, it does not disclose any behavioral traits like permissions required, pagination, or rate limits.

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 two sentences, front-loading the purpose and usage intention. Every sentence adds value with 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?

The tool has no output schema, but the description gives a clear idea of what the tool returns (a list of calendars with IDs). It could be more complete by mentioning typical fields in the response, but the current description is mostly sufficient for a straightforward list 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 parameters are already well-documented in the schema. The description does not add additional meaning beyond what the schema provides.

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 action 'list all accessible calendars including shared calendars' and specifies the use case: 'get calendar IDs for other calendar operations.' This distinguishes it from sibling tools like calendar_list_events.

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

Usage Guidelines4/5

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

The description explicitly states when to use the tool ('to get calendar IDs for other calendar operations'), but does not mention scenarios where it should not be used or alternatives.

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

calendar_list_eventsA

List calendar events for a specific date range. Can list events from any accessible calendar. Returns event times with their timezone information.

ParametersJSON Schema

Name	Required	Description	Default
`calendarId`	No	Calendar ID (default: "primary" for your main calendar). Use calendar_list_calendars to get IDs of shared calendars.	primary
`date`	No	Start date in YYYY-MM-DD format (default: today)
`days`	No	Number of days from start date (default: 1)
`maxResults`	No	Maximum number of events (default: 50)

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description bears the full burden of behavioral disclosure. It adds that the tool 'can list events from any accessible calendar' and 'returns event times with their timezone information', but it omits details on pagination, ordering, returned fields beyond times, and behavior on invalid inputs.

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 two sentences long, front-loaded with the core purpose, and contains no redundant information. Every sentence earns its place.

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, the should mention return value details. It partially does by noting timezone information but does not specify the full return structure (e.g., event fields, ordering, pagination). This leaves gaps for an agent.

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?

All 4 parameters have schema descriptions at 100% coverage. The description adds 'date range' context but does not provide additional meaning beyond what the schema already offers, so baseline 3 is appropriate.

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 verb 'list', the resource 'calendar events', and the scope 'for a specific date range' and 'any accessible calendar'. It effectively distinguishes itself from siblings like calendar_create_event (create) and calendar_list_calendars (list calendars).

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 explicit guidance on when to use this tool versus its siblings or alternatives. It does not mention when not to use it or compare it to other tools, leaving the agent to infer usage context.

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

get_user_emailA

Get the authenticated user's email address

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

No annotations are provided. The description uses 'Get', indicating a read operation with no side effects. For a simple tool, this is adequate transparency, though no extra behavioral details (e.g., auth needs) are given.

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?

A single, concise sentence with no wasted words. Perfectly front-loaded.

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

Completeness5/5

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

The tool is very simple with no parameters, no output schema, and no nested objects. The description completely captures its functionality.

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?

There are zero parameters, so the schema coverage is 100%. The description adds no parameter info since none exist. Baseline for zero params is 4.

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 verb 'get' and the specific resource 'authenticated user's email address'. It distinguishes itself from sibling tools that are all calendar/gmail actions.

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?

No explicit when-to-use guidance is given, but the tool's simplicity and uniqueness among siblings make its purpose self-explanatory. A score of 3 reflects the lack of explicit alternatives or exclusions.

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

gmail_list_emailsB

List recent emails from Gmail inbox with optional filtering. Returns email metadata and content.

ParametersJSON Schema

Name	Required	Description
`hours`	No	Number of hours to look back (default: 24)
`maxResults`	No	Maximum number of emails to return (default: 50, max: 100)
`query`	No	Gmail search query (e.g., "from:user@example.com", "has:attachment", "is:unread")

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so description must fully disclose behavior. It states 'Returns email metadata and content' but is vague on what that includes (e.g., body, attachments). No mention of auth, rate limits, or non-destructive nature.

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?

Two efficient sentences, front-loaded with key action. Could include a brief example or more structure, but overall concise.

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?

No output schema, so description should explain return format. It does not specify whether 'content' includes full body or snippet, nor pagination or default ordering. Incomplete for a 3-parameter tool with no annotations.

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. Description adds no extra detail beyond the schema's parameter descriptions, merely summarizing 'optional filtering'.

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?

Clearly states verb 'List' and resource 'emails from Gmail inbox'. Mentions optional filtering and return content, distinguishing it from gmail_read_email (specific email) and gmail_search_emails (broader search).

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 explicit guidance on when to use this tool versus siblings like gmail_search_emails or gmail_read_email. The description implies for recent inbox emails but does not set boundaries or alternatives.

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

gmail_read_emailA

Read the full content of a specific email by ID

ParametersJSON Schema

Name	Required	Description	Default
`emailId`	Yes	The Gmail message ID

TDQS

A3.5/5.0

Behavior2/5

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

Without annotations, description only hints at read-only behavior. Does not specify what 'full content' includes (headers, body, attachments) or any quota/rate limit considerations.

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 of 10 words directly conveys purpose with no redundancy.

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?

Simple tool with one parameter, but description lacks details on output structure or what 'full content' entails; no output schema to compensate.

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 covers 100% of parameters and description adds no new meaning beyond 'The Gmail message ID'—meets baseline but does not enhance understanding.

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?

Description clearly states verb 'Read' and resource 'email', with specific identifier 'by ID', distinguishing it from listing or searching sibling tools.

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?

Implies usage when email ID is known but no explicit context about when not to use or comparison to alternatives like gmail_search_emails or gmail_list_emails.

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

gmail_search_emailsA

Search emails using Gmail query syntax. Supports complex queries with operators like from:, to:, subject:, has:, is:, after:, before:

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Gmail search query (e.g., "from:boss@company.com subject:urgent", "has:attachment after:2025/11/01")
`maxResults`	No	Maximum number of results (default: 50)

TDQS

A3.6/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 cover behavior. It explains query syntax but fails to disclose that this is a read-only operation, what the output format is, or any pagination details. This lack of behavioral context is a significant gap.

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?

Two sentences, front-loaded with the core purpose. No redundant or vague statements. Every word contributes to clarity.

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

Completeness2/5

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

Despite having only two parameters and no output schema, the description omits essential context such as what the tool returns (e.g., list of message IDs or full emails) and how to handle pagination. The lack of output description hurts completeness 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?

Schema coverage is 100%, and the description adds value by listing example operators (from:, to:, etc.) that go beyond the schema's single example. The maxResults parameter is not elaborated further, but the query description enhances understanding.

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 'Search emails using Gmail query syntax' with specific operators, making the tool's purpose obvious and distinguishing it from sibling tools like gmail_list_emails or gmail_read_email.

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 complex searches via query syntax but does not explicitly state when to use this tool over alternatives like gmail_list_emails. No when-not or alternative guidance is provided.

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

gmail_send_emailB

Send an email via Gmail with subject, body, and recipients

ParametersJSON Schema

Name	Required	Description
`to`	Yes	Recipient email address(es). Can be a single email or array of emails. Use "me" to send to yourself.
`subject`	Yes	Email subject line
`body`	Yes	Email body content (plain text or HTML)
`cc`	No	CC recipient(s) (optional)
`bcc`	No	BCC recipient(s) (optional)
`isHtml`	No	Whether the body is HTML formatted (default: false)

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description must fully convey behavioral traits. It only says 'send an email' with no details on whether it creates drafts, sends immediately, supports attachments, or has rate limits. The minimal description adds little beyond the name.

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?

A single sentence efficiently conveys the core purpose without any fluff. It is appropriately sized and front-loaded with the key action.

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 of sending email (6 parameters, no output schema, no annotations), the description is insufficient. It does not explain whether the email is sent immediately, if it uses the authenticated user's account, or any side effects. More context is needed for an AI agent to use it correctly.

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 each parameter has a description in the schema. The tool description adds no extra meaning beyond that, which meets the baseline of 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 clearly states the action ('Send an email'), the service ('via Gmail'), and the key components ('subject, body, and recipients'). It distinguishes from sibling tools like gmail_list_emails and gmail_read_email which are for reading, not sending.

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 is provided. There is no mention of prerequisites (e.g., authentication), limitations (e.g., attachment support), or when to prefer other sending methods. Sibling tools exist but no differentiation is offered.

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.

8 tool updatesv0.1.5Jun 9, 2026
- First observedcalendar_create_event
- First observedcalendar_list_calendars
- First observedcalendar_list_events
- First observedget_user_email
- First observedgmail_list_emails
- First observedgmail_read_email
- First observedgmail_search_emails
- First observedgmail_send_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

A3.7/5.0

Scored 2026-06-09 20:25 across 8 tools

Disambiguation5/5

The tools are cleanly separated by domain (calendar vs. Gmail) and within each domain, each tool has a distinct purpose (e.g., list vs. create vs. read). No overlapping functionality between tools.

Naming Consistency4/5

Most tools follow a consistent 'domain_action' pattern in snake_case (e.g., calendar_create_event, gmail_send_email). However, 'get_user_email' lacks a domain prefix and is an exception.

Tool Count5/5

8 tools is a well-scoped set for a Google Workspace server covering calendar and Gmail operations. It provides essential functionality without being overwhelming.

Completeness4/5

The toolset covers core operations for both calendar (create, list) and Gmail (list, read, search, send). Missing update/delete for events and messages, but these are minor gaps for common workflows.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Related MCP Connectors

google-workspaceOAuth
com.proscendia
Permissioned access to Gmail, Drive and Calendar via the user's own Google account
Email Cloud Storage Calendar Management
1
FGAC.ai: Multiple Gmail Accounts, Google Sheets & DocsOAuth
ai.fgac
Multiple Gmail accounts, editable Google Sheets & Docs for AI agents. Deny-by-default access rules.
Email Workplace & Productivity Security
1
Grounders MCPOAuth
io.github.ItsBreeze
Multiple Google accounts (Gmail, Calendar, Drive, Contacts, Tasks) in one Claude connector.
Email Calendar Management Cloud Storage
1
MyAgentMailOAuth
com.myagentmail
Email inboxes and calendars for AI agents: send, receive, search, draft and schedule.
Email Calendar Management
1

Related MCP Servers

Gmail MCP
Email Communication
ykuchiki
A
license
Not graded
quality
C
maintenance
Enables AI assistants to send, read, search, and manage Gmail emails, drafts, and labels via the Model Context Protocol.
Updated a year ago (2025-10-08 09:29 UTC)
5
MIT
Google Workspace MCP Server
Email Workplace & Productivity
Shubham-vvn
A
license
Not graded
quality
B
maintenance
Enables AI agents to compose and send Gmail emails and append text to Google Docs using the Model Context Protocol.
Updated 2 months ago (2026-07-10 10:46 UTC)
1,084 npm
MIT
Google Workspace MCP Server
Email Workplace & Productivity
mrigank-raj
A
license
Not graded
quality
C
maintenance
Enables sending and drafting emails via Gmail and appending content to Google Docs through the Model Context Protocol.
Updated 2 months ago (2026-07-10 18:41 UTC)
27 npm
MIT
Google Workspace MCP Server
Email Workplace & Productivity
rparvathysuresh
A
license
Not graded
quality
C
maintenance
Enables AI agents to send emails via Gmail and append text to Google Docs through the Model Context Protocol.
Updated 2 months ago (2026-07-12 15:07 UTC)
261 npm
MIT