Allows sending emails and creating drafts through the Gmail API.
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., "@Gmail Sender MCP Server send an email to john@example.com with subject 'Meeting' and body 'See you 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.
An MCP (Model Context Protocol) server that enables sending emails and creating drafts through the Gmail API.
sendEmail: Send emails through your Gmail account with optional file attachments
createDraft: Create email drafts with optional file attachments
OAuth 2.0 authentication with Google
Support for file attachments of various types (PDF, DOC, images, etc.)
Run anywhere with npx - no local installation required
Related MCP server: Gmail MCP Server
Node.js v18 or higher
A Google Cloud project with Gmail API enabled
OAuth 2.0 credentials (Client ID and Client Secret)
Go to the Google Cloud Console
Create a new project or select an existing one
Enable the Gmail API for your project
Go to Credentials and create an OAuth 2.0 Client ID
Set the application type to Web application
Add http://localhost:3500/oauth2callback as an authorized redirect URI
Save your Client ID and Client Secret
The easiest way to use this server is with npx. No installation required:
GMAIL_CLIENT_ID=your_client_id GMAIL_CLIENT_SECRET=your_client_secret npx gmail-sender-mcp-servernpm install -g gmail-sender-mcp-serverThen run:
GMAIL_CLIENT_ID=your_client_id GMAIL_CLIENT_SECRET=your_client_secret gmail-sender-mcp-servergit clone <repository-url>
cd Gmail_MCP_server
npm install
GMAIL_CLIENT_ID=your_client_id GMAIL_CLIENT_SECRET=your_client_secret npm startOn first run, the server will start an OAuth server on port 3500:
Visit http://localhost:3500/auth in your browser
Sign in with your Google account and grant permissions
The authentication token will be saved to ~/.config/gmail-sender-mcp-server/token.json
The token is stored in your home directory, so it persists across npx runs and works across different machines once authenticated.
Variable | Required | Description |
| Yes | Your Google OAuth 2.0 Client ID |
| Yes | Your Google OAuth 2.0 Client Secret |
To use this server with an MCP client (like Claude Desktop), add it to your MCP configuration:
{
"mcpServers": {
"gmail-sender": {
"type": "stdio",
"command": "npx",
"args": ["gmail-sender-mcp-server"],
"env": {
"GMAIL_CLIENT_ID": "your_client_id",
"GMAIL_CLIENT_SECRET": "your_client_secret"
}
}
}
}Send an email immediately through Gmail.
Parameters:
recipient (required): Email address of the recipient
subject (required): Subject line of the email
body (required): Body content of the email (plain text)
attachmentPath (optional): Absolute path to a file to attach
Example:
{
"recipient": "example@email.com",
"subject": "Hello from MCP",
"body": "This is a test email sent via the Gmail MCP server.",
"attachmentPath": "/path/to/document.pdf"
}Create an email draft in Gmail (not sent automatically).
Parameters:
recipient (required): Email address of the recipient
subject (required): Subject line of the email
body (required): Body content of the email (plain text)
attachmentPath (optional): Absolute path to a file to attach
Example:
{
"recipient": "example@email.com",
"subject": "Draft Email",
"body": "This is a draft that can be reviewed and sent later.",
"attachmentPath": "/path/to/image.png"
}The server automatically detects file types based on extension:
Documents: PDF, DOC, DOCX, TXT
Images: JPG, JPEG, PNG, GIF
Archives: ZIP
Other files are sent as application/octet-stream
The server uses the https://www.googleapis.com/auth/gmail.compose scope, which allows:
Creating and sending emails
Creating drafts
Modifying drafts
gmail-sender-mcp-server/
├── src/
│ └── index.js # Main server implementation
├── package.json # Dependencies and scripts
└── README.md # This file
~/.config/gmail-sender-mcp-server/
└── token.json # OAuth tokens (created after authentication)OAuth tokens are stored in ~/.config/gmail-sender-mcp-server/token.json and should be kept secure
Client ID and Secret should be passed via environment variables, not committed to version control
The OAuth server only runs on localhost (port 3500)
Consider using a secrets manager for production deployments
Ensure your OAuth client is configured with http://localhost:3500/oauth2callback as a redirect URI
Check that the Gmail API is enabled in your Google Cloud project
Verify your GMAIL_CLIENT_ID and GMAIL_CLIENT_SECRET environment variables are set correctly
If authentication fails, delete ~/.config/gmail-sender-mcp-server/token.json and re-authenticate
Tokens may expire; re-authenticate if you get authorization errors
Use absolute paths for attachments
Ensure the file exists and is readable
Check that the file size is within Gmail's limits (25MB for attachments)
MIT
Create an email draft in Gmail. Requires OAuth authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Body content of the email | |
| subject | Yes | Subject line of the email | |
| recipient | Yes | Email address of the recipient | |
| attachmentPath | No | Optional: Absolute path to a file to attach |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the OAuth requirement but lacks details on whether the draft is saved automatically, what happens on success/failure, or how attachments are handled beyond the parameter.
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 with one sentence, containing only essential information and no 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?
No output schema exists, and the description omits return value (e.g., draft ID), error handling, or behavioral context like whether drafts are stored locally or synced. For a 4-parameter tool, more detail would improve completeness.
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%, providing adequate parameter meaning. The description adds no extra parameter-specific information beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create an email draft in Gmail' clearly states the verb (create) and resource (email draft), distinguishing it from the sibling tool 'sendEmail' which sends the email rather than drafts it.
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 mentions 'Requires OAuth authentication', providing a clear prerequisite. However, it does not explicitly state when to use this tool versus alternatives like sendEmail, though the verb 'draft' implies the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an email through Gmail. Requires OAuth authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Body content of the email | |
| subject | Yes | Subject line of the email | |
| recipient | Yes | Email address of the recipient | |
| attachmentPath | No | Optional: Absolute path to a file to attach |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only mentions OAuth requirement but omits important details like synchronous/asynchronous behavior, size limits, error handling, or side effects beyond sending.
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 two sentences with zero waste, front-loading the primary action and a key prerequisite. It is appropriately sized for the tool's simplicity.
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?
Despite minimal complexity, the description lacks information about return values, success/failure indicators, and behavior beyond the high-level action. With no output schema or annotations, more context would be beneficial.
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?
All parameters have descriptions in the schema, so the baseline is 3. The description adds no additional meaning beyond what the schema provides, aside from the global OAuth requirement which is not parameter-specific.
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 'send an email' and specifies the platform 'through Gmail', which distinguishes it from the sibling tool 'createDraft' (drafting vs sending).
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 includes a prerequisite (OAuth authentication) but does not provide explicit guidance on when to use this tool vs alternatives or when not to use it. The usage context is implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have clearly distinct purposes: creating a draft vs sending an email. An agent can easily differentiate between them.
Both tool names follow a consistent verb_noun pattern using camelCase (createDraft, sendEmail), demonstrating strong naming consistency.
With only 2 tools, the server is tightly scoped to its purpose of sending emails and creating drafts. Each tool earns its place.
The server covers core email sending and draft creation but lacks common operations like listing, deleting drafts, or managing attachments. There are notable gaps for a full workflow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage Gmail messages, threads, labels, drafts, and settings from your workflows. Send and organiz…
Manage Gmail end-to-end: search, read, send, draft, label, and organize threads. Automate workflow…
Permissioned access to Gmail, Drive and Calendar via the user's own Google account
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/TheMossConcept/Gmail_MCP_server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server