Skip to main content
Glama
tusharikaT

MCP Gmail Google Docs Integration

by tusharikaT
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Hybrid

Generic MCP Server for Gmail and Google Docs Integration

A generic Model Context Protocol (MCP) server that exposes Google Workspace capabilities as MCP tools. The server enables AI agents to interact with Gmail and Google Docs.

Features

  • Gmail: Send emails (To, CC, BCC, Subject, Body). Supports Plain Text and HTML.

  • Google Docs: Append plain text to an existing Google Document.

Related MCP server: MCP Google Workspace Server

Prerequisites

  1. Node.js 18+ (if running locally)

  2. Docker (if running via container)

  3. Google Cloud Console Project

    • Enable Gmail API

    • Enable Google Docs API

    • Configure OAuth Consent Screen (add yourself as a Test User)

    • Create OAuth 2.0 Client IDs (Application Type: Web Application or Desktop)

    • Add http://localhost:3000/oauth2callback as an Authorized redirect URI (if Web Application).

Local Setup & Generating the Refresh Token

To run this server (either locally or on a platform like Railway), you need an OAuth Refresh Token.

  1. Clone the repository and install dependencies:

    npm install

  2. Copy the example environment file:

    cp .env.example .env

  3. Open .env and add your GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET.

  4. Run the token generation script:

    npm run generate-tokens

  5. Follow the prompt, log in with your Google account, and grant permissions.

  6. The script will automatically save your tokens into a tokens.json file in the root of the project. This file is loaded by the server when it runs.

Deployment

If you deploy this to a cloud environment (like Railway or Docker):

  1. You must ensure the tokens.json file you generated locally is available to the container.

  2. If you are uploading code directly, DO NOT commit tokens.json to a public repository. If it's a private repository, you can commit it.

  3. If you want to change the file name, set the TOKEN_STORAGE_PATH environment variable.

Deployment (Railway)

This repository is optimized for deployment on Railway.

  1. Push this repository to GitHub.

  2. In Railway, create a new project from your GitHub repository.

  3. In the Railway project settings, go to Variables and add:

    • GOOGLE_CLIENT_ID

    • GOOGLE_CLIENT_SECRET

    • TOKEN_STORAGE_PATH (if you want to override the default 'tokens.json')

    • GOOGLE_REDIRECT_URI (optional, defaults to http://localhost:3000/oauth2callback)

  4. Railway will automatically detect the package.json, install dependencies, run the build script, and execute the start script using Nixpacks.

  5. Alternatively, Railway can build from the provided Dockerfile if you configure it to use Docker.

Connecting an MCP Client

Once deployed or running locally, you can connect an MCP Client (like Claude Desktop) to it.

If running locally:

{
  "mcpServers": {
    "gmail-gdoc": {
      "command": "node",
      "args": ["/path/to/your/project/dist/index.js"]
    }
  }
}

If deployed, you will likely connect via an SSE or HTTP transport (if you modify the transport layer) or through a remote execution bridge, depending on your agent's capabilities. Note: The current implementation uses standard input/output (stdio), which is ideal for local agent execution. For remote cloud execution, consider switching the transport to SSE in src/server.ts.

Available Tools

send_email

  • to: string[]

  • cc?: string[]

  • bcc?: string[]

  • subject: string

  • body: string

  • isHtml?: boolean

append_to_google_doc

  • documentId: string

  • content: string

Available Tools

2 tools
append_to_google_docA

Append plain text to a Google Document.

ParametersJSON Schema
NameRequiredDescriptionDefault
contentYesThe text content to append.
documentIdYesThe ID of the Google Document (found in the URL).

TDQS

A3.5/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 shoulder the burden. It only says 'append' without disclosing any behavioral traits such as permissions, error behavior, or whether formatting is supported. This is minimal transparency.

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 concise sentence that immediately conveys the tool's purpose with no unnecessary words or repetition.

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?

For a simple tool with two parameters and no output schema, the description is functional but lacks details on return values, error handling, or constraints. It is minimally adequate.

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%, with both parameters described. The description adds no extra meaning beyond the schema, 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 'Append plain text to a Google Document,' with a specific verb and resource, and it naturally distinguishes from the sibling tool 'send_email' which performs a completely different function.

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 provides no explicit guidance on when to use this tool versus alternatives. While the sibling tool is a different operation, no usage contexts or exclusions are mentioned.

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

send_emailA

Send an email using Gmail.

ParametersJSON Schema
NameRequiredDescriptionDefault
ccNoArray of email addresses to CC.
toYesArray of email addresses to send the email to.
bccNoArray of email addresses to BCC.
bodyYesThe body content of the email.
isHtmlNoWhether the body is HTML.
subjectYesSubject of the email.

TDQS

A3.5/5.0
Behavior2/5

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

No annotations exist, so description must carry burden. Only states action, no details on authentication, rate limits, side effects, or failure modes.

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, front-loaded, no wasted words. Efficient and clear.

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 tool but lacks context about authentication, attachments, or delivery confirmation. Could be improved with minimal additions.

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 schema already explains all parameters. Description adds no extra meaning 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?

Description clearly states verb ('Send') and resource ('email using Gmail'). Distinct from sibling tool 'append_to_google_doc'.

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 or alternatives provided, but usage is implied due to common tool purpose. Sibling is different, so no confusion.

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 updatesv1.0.0
    • First observedappend_to_google_doc
    • First observedsend_email
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have completely distinct purposes: one appends to a Google Doc, the other sends an email via Gmail. There is no ambiguity or overlap.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern: 'append_to_google_doc' and 'send_email'. The naming is clear and predictable.

Tool Count2/5

With only two tools for an integration involving two complex services, the tool count is too low. A typical integration would require 10-20 tools to cover basic operations.

Completeness1/5

The server lacks essential operations such as reading or listing Google Docs, creating documents, reading/searching emails, or managing drafts. The coverage is severely incomplete for the stated integration purpose.

Maintenance

ActivityStale
ResponsivenessNo issues

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

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/tusharikaT/MCP-gmail-gdoc'

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