Which integrations are available for this server?

Provides comprehensive Gmail functionality, allowing users to list, search, read, and delete emails, send messages with or without attachments, manage labels, handle conversation threads, and access account statistics.

How do I use Gmail MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Gmail MCP Server search for emails from john@example.com about the project" 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.

Gmail MCP Server

by ampcome-mcps

Overview Schema Related Servers Score Discussions

Python

Remote

Gmail MCP Server

A Model Context Protocol (MCP) server that provides comprehensive Gmail functionality through FastMCP. This server enables AI assistants like Claude to interact with Gmail accounts, manage emails, send messages, and perform various Gmail operations using OAuth2 authentication via Nango.

Features

Core Gmail Operations

Message Management: List, search, read, and delete emails
Send Emails: Send messages with or without attachments
Message Actions: Mark messages as read, manage labels
Advanced Search: Filter by sender, subject, date, attachments, read status
Account Statistics: Get Gmail account overview and metrics
Thread Support: Handle Gmail conversation threads
Attachment Support: Send emails with file attachments

Authentication & Security

OAuth2 Integration: Secure authentication via Nango
Token Management: Automatic token refresh and validation
Multi-account Support: Handle multiple Gmail accounts
Secure Credential Storage: Environment-based configuration

Related MCP server: Gmail MCP Server

Prerequisites

Python 3.13+
Gmail account with API access enabled
Google Cloud Project with Gmail API enabled
Nango account for OAuth2 management (optional but recommended)

Installation

Clone or create the project structure:

mkdir gmail-mcp-server
cd gmail-mcp-server

Create a virtual environment:

python -m venv .venv
source .venv/bin/activate  # On Windows: .venv\Scripts\activate

Install dependencies:

pip install -e .

Configuration

Environment Variables

Create a .env file in the project root:

# Nango Configuration (Recommended)
NANGO_BASE_URL=https://api.nango.dev
NANGO_SECRET_KEY=your_nango_secret_key
NANGO_CONNECTION_ID=your_NANGO_CONNECTION_ID
NANGO_INTEGRATION_ID=google

# Alternative: Direct Google OAuth (if not using Nango)
GOOGLE_CLIENT_ID=your_google_client_id
GOOGLE_CLIENT_SECRET=your_google_client_secret
GOOGLE_REFRESH_TOKEN=your_refresh_token

Google Cloud Setup

Create a Google Cloud Project:
- Go to Google Cloud Console
- Create a new project or select existing one
Enable Gmail API:
- Navigate to "APIs & Services" > "Library"
- Search for "Gmail API" and enable it
Create OAuth2 Credentials:
- Go to "APIs & Services" > "Credentials"
- Click "Create Credentials" > "OAuth 2.0 Client IDs"
- Choose "Desktop application" or "Web application"
- Note the Client ID and Client Secret
Configure OAuth Scopes:
- Add the following scopes:
  - https://www.googleapis.com/auth/gmail.readonly
  - https://www.googleapis.com/auth/gmail.send
  - https://www.googleapis.com/auth/gmail.modify

Nango Setup (Recommended)

Create Nango Account: Sign up at nango.dev
Create Google Integration: Set up Google OAuth2 integration
Configure Connection: Create a connection for your Gmail account
Get Credentials: Note your connection ID and provider config key

Claude Desktop Configuration

Add this configuration to your Claude Desktop config file:

Location:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

With Nango

{
  "mcpServers": {
    "gmail": {
      "command": "uvx",
      "args": ["git+https://github.com/ampcome-mcps/gmail-mcp.git"],
      "env": {
        "NANGO_BASE_URL": "https://api.nango.dev",
        "NANGO_SECRET_KEY": "your_nango_secret_key",
        "NANGO_CONNECTION_ID": "your_nango_connection_id",
        "NANGO_INTEGRATION_ID": "google-mail"
      }
    }
  }
}

Notes:

On Windows, use backslashes in paths: C:\\path\\to\\your\\gmail-mcp-server\\main.py
For virtual environment on Windows: .venv\\Scripts\\python.exe
Replace placeholder values with your actual credentials

Available Tools

The MCP server provides the following tools for Claude:

Message Operations

gmail_list_messages - List Gmail messages with optional search query
gmail_get_message - Get details of a specific message
gmail_search_messages - Advanced search with multiple criteria
gmail_send_message - Send a new email message
gmail_send_message_with_attachment - Send email with file attachment

Message Management

gmail_mark_as_read - Mark messages as read
gmail_delete_messages - Delete messages permanently

Account Information

gmail_get_stats - Get Gmail account statistics and overview

Usage Examples

Once configured with Claude, you can use natural language commands like:

Basic Operations

"Show me my latest 10 emails"
"Search for emails from john@example.com sent this week"
"Get the full content of message ID xyz123"
"Send an email to sarah@example.com with subject 'Meeting Tomorrow'"

Advanced Operations

"Find all unread emails with attachments from the last 7 days"
"Mark all emails from newsletter@company.com as read"
"Delete the email with ID abc456"
"Send a report to my manager with the quarterly-report.pdf attachment"
"Show me my Gmail account statistics"

Search Capabilities

"Find emails about 'project alpha' from last month"
"Show unread emails from important@client.com"
"List emails with attachments sent after 2024/01/01"

Project Structure

gmail-mcp-server/
├── main.py                 # FastMCP server implementation
├── gmail_auth.py           # Gmail OAuth2 authentication
├── gmail_operations.py     # Gmail client operations
├── pyproject.toml         # Project configuration
├── .env                   # Environment variables (create from template)
├── .env.example          # Environment template
├── README.md             # This file
├── uv.lock              # Dependency lock file
└── .gitignore           # Git ignore rules

Running the Server

With Claude Desktop

The server automatically starts when Claude Desktop loads the configuration.

Standalone Testing

For development and testing:

python main.py

Tool Specifications

gmail_list_messages

# Parameters:
- query: str = ""              # Gmail search query
- max_results: int = 10        # Max messages (1-100)

# Returns:
{
  "success": bool,
  "count": int,
  "messages": [
    {
      "id": "message_id",
      "from": "sender@example.com",
      "subject": "Email subject",
      "date": "2024-01-01",
      "snippet": "Preview text...",
      "is_unread": bool
    }
  ]
}

gmail_search_messages

# Parameters:
- sender: str = None           # Filter by sender
- subject: str = None          # Filter by subject
- after_date: str = None       # After date (YYYY/MM/DD)
- before_date: str = None      # Before date (YYYY/MM/DD)
- has_attachment: bool = False # Filter with attachments
- is_unread: bool = False      # Filter unread only
- max_results: int = 20        # Max results (1-100)

gmail_send_message

# Parameters:
- to: str                      # Recipient email (required)
- subject: str                 # Email subject (required)
- body: str                    # Email content (required)
- cc: str = ""                # CC recipients
- bcc: str = ""               # BCC recipients

# Returns:
{
  "success": bool,
  "message_id": "sent_message_id",
  "to": "recipient@example.com",
  "subject": "Email subject"
}

Development

Key Components

main.py: FastMCP server with tool definitions
gmail_auth.py: OAuth2 authentication handling
gmail_operations.py: Gmail API client wrapper
Nango Integration: Secure credential management

Adding New Features

Add Gmail Operation: Extend GmailClient class in gmail_operations.py
Define MCP Tool: Add @mcp.tool() decorator in main.py
Add Validation: Include parameter validation and error handling
Update Documentation: Add usage examples and tool specifications

Dependencies

google-api-python-client - Official Google API client
google-auth - Google authentication library
mcp[cli] - Model Context Protocol framework
python-dotenv - Environment variable management
pydantic - Data validation
requests - HTTP client for Nango integration

Troubleshooting

Common Issues

Authentication Errors:
- Verify Nango credentials are correct
- Check Gmail API is enabled in Google Cloud
- Ensure OAuth scopes are properly configured
Permission Errors:
- Verify OAuth2 scopes include required permissions
- Check if Gmail account has necessary access
Message Not Found:
- Ensure message IDs are valid Gmail message IDs
- Check if messages haven't been deleted
Rate Limiting:
- Gmail API has quotas and rate limits
- Implement retry logic for production use

Debug Mode

Enable debug logging by setting environment variable:

export GMAIL_MCP_DEBUG=true

Testing Nango Connection

# Test script to verify Nango setup
from gmail_auth import get_connection_credentials

try:
    result = get_connection_credentials("your_connection_id", "google")
    print("Nango connection successful:", result.keys())
except Exception as e:
    print("Nango connection failed:", e)

Security Considerations

Environment Variables: Never commit .env files with credentials
Token Storage: Tokens are handled securely by Nango
API Quotas: Monitor Gmail API usage to avoid quota exhaustion
Scope Limitations: Use minimal required OAuth scopes
Access Control: Limit MCP server access to authorized clients

Performance Optimization

Batch Operations: Use batch requests when possible
Caching: Implement message caching for frequently accessed data
Pagination: Handle large result sets with proper pagination
Connection Pooling: Reuse HTTP connections for API calls

Error Handling

The server implements comprehensive error handling:

Validation Errors: Parameter validation with descriptive messages
API Errors: Gmail API error handling and retry logic
Authentication Errors: Token refresh and re-authentication
Network Errors: Connection timeout and retry mechanisms

Contributing

Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Make your changes and add tests
Commit your changes (git commit -m 'Add amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request

License

This project is licensed under the MIT License - see the LICENSE file for details.

Support

For support and questions:

Check the troubleshooting section
Review Gmail API documentation: Gmail API Guide
Open an issue in the project repository
Check Nango documentation: Nango Docs

Acknowledgments

FastMCP: Simplified MCP server implementation
Google API Python Client: Official Gmail API integration
Nango: OAuth2 authentication management
Model Context Protocol: Standard for AI tool integration

Available Tools

8 tools

gmail_delete_messagesC

Delete Gmail messages.

Args: message_ids: List of message IDs to delete

Returns: Dictionary with operation result

ParametersJSON Schema

Name	Required	Description	Default
`message_ids`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, description fails to disclose whether deletion is permanent, moves to trash, requires specific scopes, or affects conversations; only states 'delete' without added detail.

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?

Very brief but under-specified; the args/returns structure is clean, but the conciseness comes at the cost of missing critical information.

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

Completeness1/5

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

No annotations or output schema, and the description omits essential details like permanence, batching limits, error handling, and return value interpretation, leaving the agent underinformed.

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

Parameters1/5

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

Schema coverage is 0%; description merely restates the parameter type (list of message IDs) with no explanation of how to obtain IDs, format, or constraints, providing no value beyond the schema.

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 'Delete Gmail messages', specific verb+resource, and distinct from sibling tools like gmail_list_messages or gmail_mark_as_read.

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 like marking as read or moving to trash; lacks context on prerequisites or irreversibility.

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

gmail_get_messageC

Get details of a specific Gmail message.

Args: message_id: Gmail message ID

Returns: Dictionary with message details or error

ParametersJSON Schema

Name	Required	Description	Default
`message_id`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

No annotations exist, so the description bears full burden. It mentions returning a dictionary with details or error but omits authentication needs, rate limits, or that it is a read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The description is short and structured with Args and Returns, but it is too brief given the lack of annotations and schema descriptions; each sentence could convey more.

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 no output schema and no annotations, the description lacks details on return format, error cases, or practical usage context like required scopes.

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

Parameters2/5

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

With 0% schema coverage, the description only restates 'message_id: Gmail message ID', adding no extra semantics about format, constraints, or how to obtain the ID.

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 gets details of a specific Gmail message, distinguishing it from siblings like list, search, or delete. However, it does not specify what 'details' include.

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 usage guidelines provided. The description does not mention when to use this tool over alternatives (e.g., search) or any prerequisites like having a valid message ID.

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

gmail_get_statsC

Get Gmail account statistics.

Args: include_unread: Include unread message count

Returns: Dictionary with account statistics

ParametersJSON Schema

Name	Required	Description	Default
`include_unread`	No

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authentication needs, or rate limits. It only states the return type as a dictionary.

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 very concise with two sentences, but it lacks depth. It front-loads the purpose but could be more informative 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?

The description omits key details such as which specific statistics are returned, the format of the dictionary, and any prerequisites. This leaves the agent with incomplete information for correct invocation.

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

Parameters2/5

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

The description adds minimal value over the input schema; 'Include unread message count' is nearly identical to the schema title 'Include Unread'. No additional details on default behavior or impact on output are given.

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 name and description clearly state 'Get Gmail account statistics', which is a specific verb and resource. It distinguishes itself from sibling tools that deal with individual messages.

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 gmail_list_messages or gmail_search_messages. The description merely states what it does without context.

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

gmail_list_messagesB

List Gmail messages with optional search query.

Args: query: Gmail search query (e.g., 'from:sender@example.com', 'is:unread') max_results: Maximum number of messages to return (1-100)

Returns: Dictionary with success status and message data

ParametersJSON Schema

Name	Required	Description	Default
`query`	No
`max_results`	No

TDQS

B3.1/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 carry the full burden of behavioral disclosure. It states the return format but does not disclose that the operation is read-only, idempotent, or safe. It lacks details on side effects, rate limits, or resource consumption. For a list operation, basic safety traits are expected.

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 extremely concise: one sentence explaining purpose, followed by a compact parameter list and return format. Every element is necessary and contributes meaning. There is no redundant or filler content.

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 low complexity (2 parameters, no output schema), the description is incomplete. It does not explain default behavior (e.g., what messages are returned when no query is given), pagination, ordering, or limitations. The mention of 'message data' in returns is vague, and the sibling tools suggest potential overlap that is not disambiguated.

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?

The input schema has no property descriptions (0% coverage), so the description adds significant value by providing concrete examples for the 'query' parameter (e.g., 'from:sender@example.com') and specifying the valid range for 'max_results' (1-100). This helps the agent form correct queries.

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 lists Gmail messages and allows an optional search query. However, it does not differentiate from the sibling 'gmail_search_messages' tool, which may have similar functionality. The verb 'List' and resource 'Gmail messages' are 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?

The description provides no guidance on when to use this tool versus alternatives like 'gmail_search_messages'. It does not specify prerequisites (e.g., authentication, mailbox) or exclusions. The agent is left 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.

gmail_mark_as_readB

Mark Gmail messages as read.

Args: message_ids: List of message IDs to mark as read

Returns: Dictionary with operation result

ParametersJSON Schema

Name	Required	Description	Default
`message_ids`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided; the description does not disclose idempotency, permissions, side effects, or behavior for invalid message IDs.

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?

Short description with Args and Returns sections, but the Args section is redundant with the schema; overall no unnecessary content.

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?

Adequate for a simple operation given no output schema, but lacks details on error handling, idempotency, or confirmation of success.

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

Parameters2/5

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

Schema coverage is 0%; the description merely restates the parameter name ('message_ids') without adding format, constraints, or usage details beyond the schema.

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 ('Mark'), resource ('Gmail messages'), and state ('as read'), distinguishing it from sibling tools like gmail_delete_messages.

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; no prerequisites or exclusions mentioned.

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

gmail_search_messagesB

Search Gmail messages with specific criteria.

Args: sender: Filter by sender email subject: Filter by subject keywords after_date: Filter messages after date (YYYY/MM/DD format) before_date: Filter messages before date (YYYY/MM/DD format) has_attachment: Filter messages with attachments is_unread: Filter unread messages max_results: Maximum number of messages to return (1-100)

Returns: Dictionary with search results

ParametersJSON Schema

Name	Required	Description	Default
`sender`	No
`subject`	No
`is_unread`	No
`after_date`	No
`before_date`	No
`max_results`	No
`has_attachment`	No

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavior. It only states 'Returns: Dictionary with search results', lacking details on return structure, pagination, rate limits, or authorization requirements. This is insufficient for a search 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 efficiently structured with a short intro, a bulleted Args list, and a Returns line. Every sentence adds value, and the format is easy to parse. No redundant or misleading content.

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 7 parameters and no output schema, the description does not fully describe the return value (vague 'Dictionary with search results'), no mention of error handling, pagination, or result limits beyond max_results. Missing critical context for a robust search tool.

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?

The schema has 0% description coverage, so the description's Args section provides essential meaning for all 7 parameters. Each parameter gets a brief but clear explanation (e.g., 'Filter by sender email', 'YYYY/MM/DD format'). While more detail could be provided, it compensates well for the schema gap.

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 searches Gmail messages with specific criteria. This verb+resource combination is distinct from sibling tools like gmail_list_messages (likely listing without advanced filters) and gmail_get_message (retrieving by ID).

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 gmail_list_messages or gmail_get_stats. The description does not mention any prerequisites, exclusions, or comparison with sibling tools.

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

gmail_send_messageB

Send a Gmail message.

Args: to: Recipient email address subject: Email subject body: Email body content cc: CC recipients (comma-separated) bcc: BCC recipients (comma-separated)

Returns: Dictionary with send result

ParametersJSON Schema

Name	Required	Description	Default
`cc`	No
`to`	Yes
`bcc`	No
`body`	Yes
`subject`	Yes

TDQS

B3/5.0

Behavior2/5

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

No annotations provided; the description does not disclose behavioral traits such as rate limits, size limits, asynchronous behavior, or error handling. For a mutation tool, this 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.

Conciseness4/5

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

The description is concise with a clear structure: one-liner verb, then args list, then return value. The first sentence is informative. No wasted words, though the 'Returns' line is vague.

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 5 parameters, no output schema, and no annotations, the description should provide more context about the return dictionary, error handling, and usage scenarios. The sibling tool with attachment is mentioned but not differentiated. The description feels like a basic doc rather than comprehensive guidance.

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?

The description adds meaning beyond the schema by describing each parameter (to, subject, body, cc, bcc) and noting that cc/bcc are comma-separated. With 0% schema description coverage, this is valuable, though it doesn't specify format for 'to' (single email vs multiple) or body content type.

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 'Send a Gmail message' with a clear verb+resource. It distinguishes from sibling tools like gmail_send_message_with_attachment by omission, implying it sends without attachments. However, it could be more specific about supported body formats (plain text vs HTML).

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives (e.g., gmail_send_message_with_attachment). No prerequisites (e.g., authentication, sending limits) are mentioned. The description only lists parameters without context.

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

gmail_send_message_with_attachmentB

Send Gmail message with attachment.

Args: to: Recipient email address subject: Email subject body: Email body content file_path: Path to file to attach cc: CC recipients (comma-separated)

Returns: Dictionary with send result

ParametersJSON Schema

Name	Required	Description	Default
`cc`	No
`to`	Yes
`body`	Yes
`subject`	Yes
`file_path`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description must disclose behavioral traits. It only states the action and arguments, lacking details on authentication, attachment size limits, error handling, or side effects. This is insufficient for an AI agent to understand the full 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 concise with a front-loaded purpose sentence followed by a brief argument list. Every sentence is necessary, though the argument list could be integrated more succinctly. Still, it is well-structured for quick comprehension.

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 that sends emails with attachments, the description is incomplete. It lacks details on return value format (only 'Dictionary with send result'), attachment handling specifics, or potential constraints (e.g., file size limits, supported file types). Given no output schema and 0% parameter schema coverage, more context is needed.

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?

Given 0% schema description coverage, the tool description adds basic semantics for each parameter (e.g., 'to: Recipient email address'). However, it omits validation rules, formatting requirements, or edge cases, providing only minimal meaning beyond the parameter names.

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 'Send Gmail message with attachment,' specifying the verb (send) and resource (Gmail message) with a distinguishing feature (attachment). This effectively differentiates it from the sibling tool 'gmail_send_message' which presumably sends without attachment.

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 when to use the tool (when an attachment is needed) but does not explicitly state conditions or exclusions compared to alternatives like gmail_send_message. No guidance on prerequisites or context is provided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

8 tool updatesv0.1.0Jul 30, 2026
- First observedgmail_delete_messages
- First observedgmail_get_message
- First observedgmail_get_stats
- First observedgmail_list_messages
- First observedgmail_mark_as_read
- First observedgmail_search_messages
- First observedgmail_send_message
- First observedgmail_send_message_with_attachment

Install Server

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

TDQS

B3.2/5.0

Disambiguation3/5

There is overlap between gmail_list_messages and gmail_search_messages, as both retrieve messages with filtering, though search offers more specific criteria. Similarly, gmail_send_message and gmail_send_message_with_attachment are nearly identical except for the attachment parameter. This could cause agent confusion.

Naming Consistency5/5

All tool names follow a consistent 'gmail_verb_noun' pattern in snake_case. Every name clearly indicates the action and resource, e.g., gmail_list_messages, gmail_get_message, gmail_send_message.

Tool Count5/5

With 8 tools, the server covers essential Gmail operations without being overwhelming. The count is well-scoped for a focused MCP server, providing a balanced set of capabilities.

Completeness4/5

The tool set covers core email operations: send, receive, list, search, mark read, delete, and stats. Missing features like label management and draft handling are minor gaps, but the current surface supports primary workflows effectively.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

email A
dev.primitive
Email infrastructure for AI agents — send, receive, search, and reply to email over MCP.
Email Communication
302
sebastianall1977-gmail-mcpOAuth
ai.smithery
Manage Gmail end-to-end: search, read, send, draft, label, and organize threads. Automate workflow…
Communication App Automation Workplace & Productivity
2
AgentMailOAuth
to.agentmail
Email inboxes for AI agents: send, receive, reply, search, and manage threaded email over MCP.
Email Communication
2
faithk7-gmail-mcpOAuth
ai.smithery
Manage Gmail messages, threads, labels, drafts, and settings from your workflows. Send and organiz…
Communication App Automation Workplace & Productivity
2

Related MCP Servers

Gmail MCP Server
Communication App Automation Workplace & Productivity
shcallaway
A
license
Not graded
quality
D
maintenance
Enables AI assistants to read, search, organize, and draft emails in Gmail inboxes with support for multiple accounts, OAuth authentication, and 26 comprehensive tools for email management.
Updated 8 months ago (2026-01-12 00:36 UTC)
205
3
MIT
Gmail MCP Server
Communication App Automation Workplace & Productivity
XEW25
A
license
Not graded
quality
D
maintenance
Enables AI assistants to manage Gmail accounts through natural language for tasks like sending, reading, searching, and organizing emails. It supports advanced features including draft management, label operations, and batch actions via secure OAuth 2.0 authentication.
Updated 7 months ago (2026-02-18 07:34 UTC)
MIT
Gmail MCP Server
Email Communication
neutral-Stage
A
license
A
quality
D
maintenance
Enables AI agents to search, read, send, and organize Gmail emails via MCP protocol.
Updated 5 months ago (2026-04-08 10:38 UTC)
22
215
2
MIT
gmail-mcp
Email Workplace & Productivity
ensismoebius
F
license
Not graded
quality
C
maintenance
Full Gmail control for any MCP-compatible AI agent. Exposes ~40 tools for reading, composing, labeling, filtering, threading, and account management.
Updated 2 months ago (2026-06-23 08:47 UTC)
-

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ampcome-mcps/gmail-mcp'

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