Which integrations are available for this server?

Allows creating Gmail drafts and listing recent drafts. Allows creating, reading, appending text, and inserting at placeholders in Google Docs documents. Allows searching for Google Docs by name in Google Drive.

How do I use Google Docs & 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., "@Google Docs & Gmail MCP Server Create a new Google Doc titled 'Weekly Summary' and paste the meeting notes." 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.

Google Docs & Gmail MCP Server

by vaibhavsingh02001-cyber

Overview Schema Related Servers Score Discussions

TypeScript

Local

Google Docs & Gmail MCP Server

An MCP (Model Context Protocol) server that enables AI agents (e.g., Claude Desktop) to interact with Google Docs and Gmail — creating documents, appending content, replacing placeholders, and drafting emails.

Project Structure

MCP/
├── src/
│   ├── index.ts              # MCP server entry point (all tool handlers)
│   ├── auth.ts               # One-time OAuth 2.0 token generation script
│   ├── googleClient.ts       # Centralized authenticated Google API clients
│   └── tools/
│       ├── docsTools.ts      # Google Docs & Drive tool implementations
│       └── gmailTools.ts     # Gmail draft tool implementations
├── credentials.json          # ← You must download this from Google Cloud Console
├── token.json                # ← Generated automatically by: npm run auth
├── claude_desktop_config.json # Claude Desktop MCP server configuration
├── package.json
├── tsconfig.json
├── .env.example
└── .gitignore

Related MCP server: Google Workspace MCP Server

Getting Started

Prerequisites

Node.js v18+
A Google account with access to Google Workspace (Docs + Gmail)

Step 1: Google Cloud Console Setup

Go to https://console.cloud.google.com/
Create a new project (e.g., MCP-Server)
Enable the following APIs:
- Google Docs API
- Google Drive API
- Gmail API
Go to APIs & Services → Credentials
Click Create Credentials → OAuth 2.0 Client ID
- Application Type: Desktop App
- Name: MCP Server
Download the JSON file and rename it to credentials.json
Place credentials.json in the project root: C:\Users\Vaibhav Singh\Desktop\MCP\

Step 2: Authorize the Application (one-time)

powershell -ExecutionPolicy Bypass -Command "npm run auth"

This will:

Print a Google authorization URL
You open the URL, log in, and paste the authorization code back
token.json is saved automatically

Step 3: Test the MCP Server

# Start the server directly
powershell -ExecutionPolicy Bypass -Command "npm run dev"

# Or launch the MCP Inspector UI for testing
powershell -ExecutionPolicy Bypass -Command "npm run inspect"

Step 4: Connect to Claude Desktop (Phase 5)

Copy the contents of claude_desktop_config.json into your Claude Desktop configuration file, located at:

Windows: %APPDATA%\Claude\claude_desktop_config.json

Then restart Claude Desktop. You should see 7 tools available from this MCP server.

Available Tools

Tool	Description
`create_document`	Creates a new Google Doc and returns ID + URL
`search_documents`	Searches Google Drive for Docs by name
`append_text`	Appends text to the end of a document
`insert_at_placeholder`	Replaces `{{placeholder}}` text in a document
`read_document`	Returns the full text content of a document
`create_gmail_draft`	Creates a Gmail draft email (To, Subject, Body, CC)
`list_gmail_drafts`	Lists recent Gmail drafts

Example Prompts for Claude

"Create a new Google Doc titled 'Q3 Report' and append a summary of our meeting."

"Search for a document called 'Meeting Notes' and append today's agenda."

"Create a Gmail draft to john@example.com with subject 'Project Update' and a professional body."

"Find the document 'Email Log' and replace the placeholder {{latest_draft}} with the email I just dictated."

Available Tools

7 tools

append_textB

Appends text content to the end of an existing Google Document.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	The text content to append.
`document_id`	Yes	The ID of the Google Document to append to.

TDQS

B3.3/5.0

Behavior2/5

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

No annotations exist, so the description must fully disclose behavior. It states the core action but omits details about required permissions (e.g., write access), failure modes (e.g., non-existent document), or side effects (e.g., permanent modification). This is insufficient for a mutation 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?

A single sentence of eight words, front-loaded with the action and resource. No waste—every word provides value.

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's simplicity (2 required params, no output schema, no annotations), the description covers the core purpose. However, it lacks complementary details like what happens on success, error handling, or confirmation methods, which would improve completeness.

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 clear parameter descriptions. The tool description adds no extra meaning beyond the schema, so baseline score of 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 uses a specific verb 'Appends' and identifies the resource 'Google Document' with explicit scope 'to the end', clearly distinguishing it from sibling tools like insert_at_placeholder (which inserts at a placeholder) and create_document (which creates new files).

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. For instance, it does not mention that insert_at_placeholder should be used for non-end insertions, nor does it state prerequisites like the document must exist.

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

create_documentA

Creates a new Google Doc with the given title. Returns the document ID, title, and URL.

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes	Title for the new Google Document.

TDQS

A3.9/5.0

Behavior3/5

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

Returns document ID, title, and URL, but no annotations exist. Lacks details on authorization, rate limits, or side effects. The description adds value beyond schema but is not comprehensive.

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 key information (creation and return values), no wasted words.

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?

For a simple tool with one parameter and no output schema, the description fully covers purpose and return values, leaving no critical gaps.

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 the schema already describes the 'title' parameter. The description adds no additional semantic meaning beyond what the schema provides, meeting baseline.

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 'Creates a new Google Doc', a specific verb+resource, and distinguishes from siblings like append_text (modification) or read_document (reading).

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?

Implied usage: use when you want to create a new document. Does not provide explicit when-to-use vs alternatives or exclusions, but the purpose is clear enough.

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

create_gmail_draftA

Creates a Gmail draft email ready for review and sending. Returns the draft ID and a preview URL.

ParametersJSON Schema

Name	Required	Description
`cc`	No	Optional CC recipients (comma-separated email addresses).
`to`	Yes	Recipient email address.
`body`	Yes	Plain-text body of the email.
`subject`	Yes	Email subject line.

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 bear full burden. It mentions return values (draft ID and preview URL) but does not disclose authentication needs, rate limits, or side effects beyond creation.

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, zero waste, efficiently conveys purpose and output.

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 full schema coverage and no output schema, the description is adequate for basic understanding but lacks context about validation, authentication, or relationship with sibling tools.

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?

Input schema has 100% description coverage, so baseline is 3. The description adds no additional meaning beyond what the schema already provides for the 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 clearly states the action (creates), resource (Gmail draft), and context (ready for review and sending), distinguishing it from siblings like list_gmail_drafts.

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 (when a draft needs to be created) but lacks explicit guidance on when to use versus alternatives or prerequisites.

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

insert_at_placeholderA

Replaces every occurrence of a placeholder string (e.g. {{email_draft}}) in an existing Google Document with the provided text.

ParametersJSON Schema

Name	Required	Description
`text`	Yes	The replacement text to insert at each placeholder.
`document_id`	Yes	The ID of the Google Document.
`placeholder`	Yes	The exact placeholder string to search for, e.g. {{email_draft}}.

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that it replaces 'every occurrence' of the placeholder. However, it does not mention whether the replacement is in-place, what happens if the placeholder is missing, or any side effects like formatting preservation.

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 that is front-loaded with the action and clearly communicates the tool's purpose. No extraneous information.

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 description covers the main action and all parameters are explained in schema. However, without an output schema, it would be helpful to know the return value (e.g., success, count of replacements). But given the low complexity, it is mostly complete.

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%, but the description adds value by explaining how the parameters work together: 'replaces every occurrence' and provides an example placeholder format. This contextualizes the parameters beyond their individual schema descriptions.

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 'replaces', the resource 'placeholder string in a Google Document', and the action 'with provided text'. It specifies an example placeholder format ({{email_draft}}). This distinguishes it from siblings like append_text which appends to the end, and create_document which creates new documents.

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 when placeholders need replacement but does not explicitly state when to use this tool over siblings like append_text or read_document. No guidance on when not to use it or alternatives.

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

list_gmail_draftsA

Lists the most recent Gmail drafts in the authenticated user's account.

ParametersJSON Schema

Name	Required	Description	Default
`max_results`	No	Maximum number of drafts to return (default: 10).

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are provided, so the description must convey behavioral traits. It states 'most recent' but does not specify ordering direction (e.g., descending by date) or other behaviors like authentication requirements, rate limits, or whether drafts are modified by listing. It is moderately transparent for a simple 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.

Conciseness5/5

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

The description is a single clear sentence of 10 words, with the verb and resource upfront. No unnecessary information, earning its place without any fluff.

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?

Given the tool's simplicity (1 optional parameter, no output schema), the description is nearly complete. It could improve by explicitly noting that drafts are ordered by newest, but overall it provides sufficient context for an agent to understand the basic functionality.

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 a single parameter 'max_results' fully described in the schema. The description does not add any additional meaning beyond the schema. Baseline score of 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 that the tool lists the most recent Gmail drafts for the authenticated user. The verb 'Lists' and resource 'Gmail drafts' are specific, and the scope is well-defined. It distinguishes from sibling tools like create_gmail_draft and document tools by focusing on listing drafts.

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. It does not mention prerequisites, conditions, or situations where other tools might be more appropriate. The implied usage is for listing drafts, but no explicit context is provided.

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

read_documentA

Reads and returns the plain-text content of an existing Google Document.

ParametersJSON Schema

Name	Required	Description	Default
`document_id`	Yes	The ID of the Google Document to read.

TDQS

A3.9/5.0

Behavior3/5

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

The description indicates a read-only operation but does not disclose any further behavioral traits such as rate limits or response format details beyond returning plain text.

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, clear sentence with no unnecessary words; efficiently conveys the tool's purpose.

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?

For a simple read tool with one parameter and no output schema, the description adequately covers the essential information.

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%, and the description adds no additional meaning beyond the schema's description of the document_id parameter.

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 'Reads' and the resource 'plain-text content of an existing Google Document', distinguishing it from sibling tools like create_document or append_text.

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 reading document content but does not provide explicit guidance on when to use this tool versus alternatives like search_documents for finding document IDs.

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

search_documentsA

Searches the authenticated user's Google Drive for documents whose name contains the query string. Returns a list of matching files with ID, name, URL, and last modified time.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search term to match against document names.
`max_results`	No	Maximum number of results to return (default: 10).

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses the search scope (authenticated user's Drive) and return fields (ID, name, URL, last modified time). It does not mention rate limits, pagination, or error behavior, but for a read-only search tool, this is fairly transparent.

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 concise sentences: first states purpose and scope, second describes output. Every sentence carries essential information with no redundancy or fluff.

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?

Given the tool's simplicity (2 parameters, no output schema, no annotations), the description is mostly complete. It covers input, output fields, and scope. However, it could mention pagination behavior or default limit more explicitly.

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%, so baseline is 3. The description adds context about the search scope and explicitly states the output structure (list of matching files with specific fields), which is not in the schema. This adds meaningful value.

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 specifies the action (searches), resource (the authenticated user's Google Drive), and filter (name contains query). It distinguishes from siblings like 'read_document' which targets a specific document, and 'create_document' which creates new ones.

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 finding documents by name but does not explicitly state when to use or not use this tool versus alternatives like full-text search or list operations. No exclusion criteria or alternative tool mentions.

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.

7 tool updatesv1.0.0Jul 15, 2026
- First observedappend_text
- First observedcreate_document
- First observedcreate_gmail_draft
- First observedinsert_at_placeholder
- First observedlist_gmail_drafts
- First observedread_document
- First observedsearch_documents

Install Server

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

TDQS

A3.9/5.0

Disambiguation5/5

All tools have clear, distinct purposes. Google Docs tools (create, read, append, insert at placeholder, search) and Gmail tools (create draft, list drafts) are easily distinguishable with no overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case, e.g., create_document, list_gmail_drafts. Naming is predictable and clear.

Tool Count5/5

7 tools is well-scoped for covering core operations of two services. Each tool earns its place without being excessive or insufficient.

Completeness3/5

Missing key operations like sending a Gmail draft and deleting a document. While the set covers basic CRUD for Docs and draft creation for Gmail, the lack of send creates a workflow gap.

Maintenance

ActivitySlowing

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

Mila A
io.github.mila-gg
Create and manage documents, spreadsheets, and presentations from your AI assistant.
Workplace & Productivity App Automation Content Management Systems
232
Sheet Best MCP
io.github.sheetbest
Connect AI assistants to Google Sheets through controlled tools for reading and updating rows.
Workplace & Productivity App Automation
1
MetrifyrOAuth
cloud.metrifyr
SEO & marketing toolkit for AI agents: GA4, Search Console, AdSense, GTM, PageSpeed, Trends.
Monitoring Search Marketing
2
writespace-mcp
io.github.write-space
Persistent docs and memory for AI agents — read, write, organize & search a shared workspace.
Knowledge & Memory Note Taking
2

Related MCP Servers

Google Workspace MCP Server
Email Workplace & Productivity
sibaniacharya
F
license
Not graded
quality
C
maintenance
Enables AI agents to send emails and append content to Google Docs using Gmail and Google Docs APIs.
Updated 2 months ago (2026-07-08 14:58 UTC)
-
Google Workspace MCP Server
Communication Workplace & Productivity
aryaprashant23
A
license
Not graded
quality
B
maintenance
Enables AI agents to create Gmail drafts and append content to Google Docs, supporting automated review analysis and notification workflows.
Updated 2 months ago (2026-07-14 12:49 UTC)
1,895
MIT
Google Workspace MCP Server
Email Workplace & Productivity
anuj76913
A
license
Not graded
quality
C
maintenance
Enables AI agents to securely interact with Google Workspace services, including sending emails via Gmail and appending content to Google Docs.
Updated 2 months ago (2026-07-13 08:35 UTC)
225
MIT
Google Workspace MCP Server
Email Workplace & Productivity
anuj2001
A
license
Not graded
quality
B
maintenance
Enables AI agents to send emails via Gmail and append content to Google Docs.
Updated 2 months ago (2026-07-14 06:05 UTC)
225
MIT

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/vaibhavsingh02001-cyber/MCP_Server'

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