Skip to main content
Glama
VatsKan

MCP Gmail Server

by VatsKan
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

MCP Gmail Server

A server that uses model context protocol[https://modelcontextprotocol.io/] to read and create drafts of emails from Gmail.

Project setup

Create Oauth client and add secrets:

Create a Google Cloud Project

  1. Go to https://console.cloud.google.com/

  2. In the top-left, open the project dropdown and click New Project

  3. Give your project a name (e.g., Gmail API Demo)

  4. Click Create Your project is now created; make sure it’s selected in the project dropdown.

Enable the Gmail API

  1. Go to the API Library: https://console.cloud.google.com/apis/library

  2. Search for Gmail API

  3. Click it → Enable

Configure OAuth 2.0 Credentials

  1. Navigate to: APIs & Services → Credentials

  2. You’ll be prompted to configure the OAuth Consent Screen (if first time creating OAuth credentials)

  3. Choose External if users outside your Google Workspace will use it

  4. Fill in details

  5. Add test users (email addresses allowed to authorize during development)

  6. Save the configuration

  7. Click Create Credentials → OAuth client ID

  8. Choose the application type: Desktop app (for testing/dev)

  9. Name it

  10. Click Create

You will now receive:

  • Client ID

  • Client Secret Download them as JSON for use in your code.

Save the JSON as "client_secret_oauth_gcp.json" in the root of this project. (note this should be stored securely and not commited to github.)

Install and run app

Install uv: https://docs.astral.sh/uv/getting-started/installation/

Install dependencies with uv: uv sync

Start server: uv run -m src.mcp_server_gmail

Claude desktop

Install Claude Desktop

Set claude_desktop_config.json file to:

{
  "mcpServers": {
    "gmail": {
      "command": "/Users/myname/Documents/Coding/fac-mcp-gmail-server/.venv/bin/python",
      "args": [
        "-m",
        "mcp_server_gmail"
      ],
      "env": {
        "PYTHONPATH": "/Users/myname/Documents/Coding/fac-mcp-gmail-server/src"
      },
      "cwd": "/Users/myname/Documents/Coding/fac-mcp-gmail-server"
    }
  }
}

Ensuring the directory paths are replaced appropriately with your local directory paths.

Test (manual)

Go to claude desktop

Try the following: "Get last 3 unread emails" "Create draft emails for these"

See /docs/working_examples, for examples screenshots of the mcp server

Related MCP server: Gmail Assistant MCP

Features

  • Gmail Oauth set up

  • MCP server for read and drafting emails on gmail

Available Tools

2 tools
create_draft_replyC

Create a draft reply to an email

ParametersJSON Schema
NameRequiredDescriptionDefault
message_contentYes
message_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.8/5.0
Behavior2/5

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the action without explaining side effects, permissions required, or whether the draft is saved automatically. The agent lacks information about the tool's mutability or safety profile.

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

Conciseness4/5

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

The description is a single short sentence, which is concise and front-loaded. However, it may be too terse for the agent to understand context. It earns its place but could benefit from slight expansion.

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 tool's simplicity and the presence of an output schema, the description is minimal but lacks essential context about usage, parameter details, and behavioral traits. It does not fully enable correct selection and invocation.

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 description coverage is 0%, and the description adds no meaning to the parameters 'message_content' and 'message_id'. It does not clarify what format or content is expected, or how to obtain the message_id. The schema already provides minimal info, but the description should compensate.

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 'Create a draft reply to an email' uses a specific verb and resource, clearly indicating the action and the type of email operation. It distinguishes well from the sibling tool 'get_unread_emails', which is a read operation.

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. The description does not mention prerequisites, context, or when not to use it. There is no mention of the sibling tool or alternative scenarios.

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

get_unread_emailsA

Get a list of unread emails

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior2/5

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

With no annotations provided, the description bears the full burden of behavioral disclosure, but it fails to mention any behavioral traits such as authentication requirements, rate limits, or what happens when no unread emails exist. The output schema exists but the description does not leverage it to clarify return behavior.

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

Conciseness5/5

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

The description is a single front-loaded sentence containing no extraneous words. It is concise and immediately communicates the core purpose.

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 the tool has zero parameters and an output schema likely describing the return format, the description is minimally adequate but lacks important context such as whether it returns all unread emails or a subset, and whether pagination is involved. The description could be more complete, e.g., mentioning the scope or ordering.

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 tool has zero parameters, and the input schema coverage is 100% (empty). Baseline for zero parameters is 4, and the description adds no additional parameter details. It is adequate given the lack of parameters.

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 'Get a list of unread emails' uses a specific verb 'Get' and clearly identifies the resource 'unread emails', leaving no ambiguity about the tool's function. It is distinct from the sibling tool 'create_draft_reply', which is a write operation.

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 are provided. The description does not state when to use this tool versus alternatives, nor does it offer any context about prerequisites or contraindications. The sibling tool 'create_draft_reply' is mentioned in context but not in the description itself.

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.

  1. 2 tool updatesv0.1.0
    • First observedcreate_draft_reply
    • First observedget_unread_emails
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: one retrieves unread emails, the other creates draft replies. No overlap or ambiguity.

Naming Consistency5/5

Both tools follow the verb_noun pattern with snake_case, consistent and predictable naming.

Tool Count2/5

With only 2 tools for a Gmail server, the surface is too thin. A typical Gmail integration would require many more operations.

Completeness1/5

The tool set is severely incomplete for email management: missing send, search, archive, delete, label management, and other essential operations.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • Gmail Assistant MCP

    thejoefriel
    F
    license
    Not graded
    quality
    D
    maintenance
    Integrates Gmail with Claude to fetch unread emails and generate draft replies based on user context and writing style guidelines stored in Google Docs. It enables automated email management and drafting through natural language interactions within the Model Context Protocol framework.
    -

  • Gmail MCP Server

    AlexHramovich
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol (MCP) server that enables Claude Desktop to interact with Gmail through secure OAuth 2.0 authentication. Send emails, search messages, read emails, and manage multiple Gmail accounts directly from Claude Desktop.
    215
    MIT

Latest Blog Posts

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/VatsKan/mcp-gmail-server'

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