Which integrations are available for this server?

Provides tools for sending emails and creating email drafts through the authenticated Gmail account. Provides tools for appending content to existing Google Documents and retrieving document metadata such as title, character count, and revision ID.

How do I use google-tools-mcp-server?

1. Click on "Deploy 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-tools-mcp-server Send an email to alex@example.com with subject 'Project Update' and body 'All tasks are done'." 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-tools-mcp-server

by vbj2pxgs4j-cmd

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Google Tools MCP Server (`google-tools-mcp-server`)

A Model Context Protocol (MCP) server that connects AI agent environments (such as Cursor, AntiGravity, Windsurf, and Claude Desktop) to Google Workspace services—specifically Gmail and Google Docs.

Features & Tools

The server registers 4 tools over standard MCP JSON-RPC:

Tool	Description	Input Parameters
`gmail_send_email`	Sends an email directly via the authenticated Gmail account.	`to` (required), `subject` (required), `body_text`, `body_html`, `cc`, `bcc`, `reply_to`
`gmail_create_draft`	Creates a draft in Gmail for user review before sending.	`to`, `subject`, `body_text`, `body_html`, `cc`, `bcc`
`gdocs_append_content`	Appends formatted or plain text to an existing Google Document.	`document_id` (required), `text_content` (required), `insert_line_break` (boolean), `formatting` (`PLAIN_TEXT`, `HEADING_1`, `HEADING_2`, `HEADING_3`, `BULLET_LIST`)
`gdocs_get_document_info`	Retrieves document title, character count, and revision ID.	`document_id` (required)

Related MCP server: Google Workspace MCP Server

1. Setup Google Cloud Credentials

To allow the MCP server to communicate with Gmail and Google Docs:

Go to the Google Cloud Console.
Create or select a Google Cloud Project.
Enable the following APIs in APIs & Services > Library:
- Gmail API
- Google Docs API
- Google Drive API
Configure your OAuth Consent Screen (APIs & Services > OAuth consent screen):
- Choose User Type: External (or Internal for Google Workspace domain).
- Add the scopes:
  - https://www.googleapis.com/auth/gmail.send
  - https://www.googleapis.com/auth/gmail.compose
  - https://www.googleapis.com/auth/documents
  - https://www.googleapis.com/auth/drive.readonly
- Add your own email as a Test User.
Create OAuth Credentials (APIs & Services > Credentials):
- Click Create Credentials > OAuth client ID.
- Application Type: Web application.
- Name: google-tools-mcp-server.
- Authorized redirect URIs: Add http://localhost:3000/oauth2callback.
- Click Create and copy your Client ID and Client Secret.

2. Installation & Token Generation

Step A: Clone & Install Dependencies

npm install

Step B: Configure Environment Variables

Copy .env.example to .env:

cp .env.example .env

Fill in your credentials:

GOOGLE_CLIENT_ID=your-client-id.apps.googleusercontent.com
GOOGLE_CLIENT_SECRET=your-client-secret

Step C: Generate Refresh Token

Run the interactive helper script:

npm run auth:token

Open the URL shown in your browser.
Sign in and grant the requested permissions.
Copy the output GOOGLE_REFRESH_TOKEN into your .env file.

Step D: Build the Server

npm run build

3. Host Integration

AntiGravity / Cursor Integration

Add the server definition to your mcp_config.json or .cursor/mcp.json:

{
  "mcpServers": {
    "google-tools": {
      "command": "node",
      "args": ["/absolute/path/to/google-tools-mcp-server/build/index.js"],
      "env": {
        "GOOGLE_CLIENT_ID": "your-client-id.apps.googleusercontent.com",
        "GOOGLE_CLIENT_SECRET": "your-client-secret",
        "GOOGLE_REFRESH_TOKEN": "your-refresh-token"
      }
    }
  }
}

Claude Desktop Integration

Add the following to your claude_desktop_config.json:

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

{
  "mcpServers": {
    "google-tools": {
      "command": "node",
      "args": ["/absolute/path/to/google-tools-mcp-server/build/index.js"],
      "env": {
        "GOOGLE_CLIENT_ID": "your-client-id.apps.googleusercontent.com",
        "GOOGLE_CLIENT_SECRET": "your-client-secret",
        "GOOGLE_REFRESH_TOKEN": "your-refresh-token"
      }
    }
  }
}

4. Testing with MCP Inspector

You can test and inspect tool calls locally using the official @modelcontextprotocol/inspector:

npx @modelcontextprotocol/inspector node build/index.js

5. Security & Architectural Invariants

Stdio Isolation: All logging, debug outputs, and errors are written exclusively to process.stderr. process.stdout is strictly reserved for JSON-RPC 2.0 protocol packets.
Automatic Token Refresh: The server automatically refreshes OAuth access tokens in the background when they expire without terminating the connection.
Safe Error Recovery: All tool invocations are wrapped in defensive boundaries; malformed requests or API errors return structured MCP error responses (isError: true) instead of crashing the server process.

Available Tools

4 tools

gdocs_append_contentB

Appends formatted or plain text content to the end of a specified Google Document.

ParametersJSON Schema

Name	Required	Description	Default
`formatting`	No	Structural styling to apply: 'PLAIN_TEXT', 'HEADING_1', 'HEADING_2', 'HEADING_3', 'BULLET_LIST'	PLAIN_TEXT
`document_id`	Yes	Google Doc ID extracted from URL ('https://docs.google.com/document/d/<document_id>/edit')
`text_content`	Yes	The text/markdown content to append to the document
`insert_line_break`	No	Whether to start content insertion on a new line (default: true)

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 carries the full burden of behavioral disclosure. It implies a mutating operation (appends to the doc) but does not state whether write access is required, whether existing content is preserved beyond 'end', how formatting is interpreted, or any side effects. The insert_line_break default behavior is left entirely to the schema.

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 that front-loads the action and resource, with zero superfluous words. 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.

Completeness3/5

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

For a simple append operation, the description covers the core action and the schema handles parameter detail. However, it lacks usage context (when to choose this over alternatives), prerequisites (valid document ID, write permissions), and any behavioral caveats. It is adequate but not fully complete.

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 description coverage is 100%, so the schema already documents all four parameters and their defaults. The description adds only minimal semantic value ('formatted or plain text' hints at formatting, 'end' mirrors the append concept) but does not explain nuances like how formatting interacts with document styles or how insert_line_break affects output. 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 states a specific verb ('Appends'), a specific resource ('Google Document'), a location ('to the end'), and content types ('formatted or plain text'). This distinguishes it clearly from sibling tools like gmail_send_email and gdocs_get_document_info, and goes beyond the tool name by specifying the positioning.

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, no prerequisites, and no exclusions. Although the siblings are in different domains, an agent deciding between append and other document operations (e.g., replace or create) receives no direction.

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

gdocs_get_document_infoA

Retrieves document title, character count, and revision metadata to confirm access before modifying.

ParametersJSON Schema

Name	Required	Description	Default
`document_id`	Yes	The unique Google Document identifier

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly implies a read-only operation and states exactly what is retrieved, which gives basic transparency. However, it does not explicitly state that it is non-destructive, mention any authentication requirements, or describe potential failure modes (e.g., what happens if document_id is invalid or access is denied). This is adequate but not rich.

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, information-dense sentence that is front-loaded with the action and result. Every clause earns its place: it specifies the verb, the resource, the specific metadata retrieved, and the purpose. There is no redundancy or filler.

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?

Given the tool's low complexity (single parameter, simple read operation) and the absence of an output schema, the description is remarkably complete. It tells the agent exactly what the tool returns (title, character count, revision metadata) and why to use it (confirm access). Nothing essential is missing for an agent to decide to call it.

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 description coverage is 100%, and the schema already adequately describes document_id as 'The unique Google Document identifier'. The description adds no extra meaning or usage guidance for the parameter beyond what the schema provides, so it meets the baseline of 3 but does not exceed it.

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 states a specific verb ('retrieves'), a resource ('document'), and enumerates the exact data returned (title, character count, revision metadata). It also signals its purpose (confirm access before modifying), which clearly differentiates it from sibling tools like gdocs_append_content that perform modifications.

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

Usage Guidelines4/5

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

The phrase 'to confirm access before modifying' provides clear context for when this tool should be used. However, it does not explicitly name alternatives or state when NOT to use it. Since the sibling tools are mostly write operations (append, send, draft), the intended use as a pre-modification check is implied but not directly articulated as an exclusion.

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

gmail_create_draftA

Creates an email draft in the user's Gmail account without sending it immediately. Allows human review before dispatch.

ParametersJSON Schema

Name	Required	Description
`cc`	No	Optional CC recipient(s)
`to`	No	Optional recipient email address(es)
`bcc`	No	Optional BCC recipient(s)
`subject`	No	Optional subject line for the draft
`body_html`	No	HTML formatted content of the draft
`body_text`	No	Plain text content of the draft

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It explicitly discloses the most important behavioral trait: the draft is not sent immediately and allows human review. This is valuable and non-obvious. It does not mention the draft being stored in the Gmail drafts folder or other side effects, but the core behavior is clearly disclosed.

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, purposeful sentences. The primary behavior (create draft, no immediate sending) is front-loaded, and every word adds meaning. No filler or redundant phrasing.

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 tool is simple, all parameters are documented in the schema, and there is no output schema. The description covers the purpose and the key distinction from sending. It does not explain the Gmail drafts folder or follow-up steps, but those are not essential for correct invocation. A 4 is appropriate.

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 description coverage is 100%, so the schema already documents all six parameters. The description adds no parameter-specific meaning or examples, so the 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 states a specific verb (creates), a resource (an email draft in the user's Gmail account), and a key restriction (without sending it immediately). This clearly distinguishes it from the sibling tool gmail_send_email, and the action is not vague or tautological.

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

Usage Guidelines4/5

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

The description implies the appropriate context: use this tool when an email should be prepared for human review before dispatch, versus sending immediately. It does not explicitly name gmail_send_email as the alternative or state exclusions, but the contrast between 'draft' and 'send' is evident from the phrasing.

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

gmail_send_emailA

Sends an email directly to specified recipients via the user's Gmail account.

ParametersJSON Schema

Name	Required	Description
`cc`	No	Carbon copy recipient email address(es), comma-separated
`to`	Yes	Recipient email address or comma-separated list of addresses (e.g., 'lead@example.com, team@example.com')
`bcc`	No	Blind carbon copy recipient email address(es), comma-separated
`subject`	Yes	Subject line of the email
`reply_to`	No	Custom Reply-To email address
`body_html`	No	HTML formatted body of the email for rich formatting (optional)
`body_text`	No	Plain text body of the email (optional if body_html provided)

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 carries the full disclosure burden. It confirms that an email is actually sent through the user's Gmail account, but it does not mention irreversibility, permission requirements, sending limits, or failure 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 one short sentence with no filler. 'Directly' adds differentiation value, and 'via the user's Gmail account' provides useful scoping without unnecessary detail.

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?

The tool is simple and all parameters are documented, but with no output schema and no annotations, the description is only minimally complete. It omits side-effect notes, alternative-tool context, and any indication of what is returned after sending.

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?

All seven parameters are already described in the input schema, so the description does not add parameter-level meaning. This is acceptable because schema coverage is 100%, and the fields are straightforward.

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 states a clear verb ('sends'), a resource ('email'), and a scope ('via the user's Gmail account'). The word 'directly' signals immediate delivery and helps distinguish this tool from the sibling gmail_create_draft.

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?

Implicitly, 'directly' suggests use when an immediate send is wanted rather than creating a draft. However, there is no explicit when-to-use or when-not-to-use guidance, and the draft alternative is not named.

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.

4 tool updatesv1.0.0Sep 15, 2026
- First observedgdocs_append_content
- First observedgdocs_get_document_info
- First observedgmail_create_draft
- First observedgmail_send_email

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-09-15 17:57 across 4 tools

Disambiguation4/5

Each tool targets a distinct resource (Gmail vs Google Docs) and action (send, draft, append, get info). There is minor potential confusion between sending and drafting an email, but their descriptions clearly differentiate immediate dispatch from human review.

Naming Consistency4/5

Tool names follow a consistent pattern of <service>_<verb>_<object>, such as gmail_send_email and gdocs_append_content. Minor inconsistency: gdocs_get_document_info uses 'get_document_info' instead of a clearer 'get_info', but overall the pattern is predictable.

Tool Count4/5

With only 4 tools, the count feels slightly thin for a server covering two major Google services (Gmail and Docs). However, the tools are focused on essential workflows and each serves a distinct purpose, justifying its inclusion.

Completeness3/5

The server covers basic email creation (send and draft) and document interaction (append and get info). Notably missing are operations like reading emails, searching documents, or creating documents, which are common in such workflows and may cause agents to hit dead ends.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

FGAC.ai: Multiple Gmail Accounts, Google Sheets & DocsOAuth
ai.fgac
Multiple Gmail accounts, editable Google Sheets & Docs for AI agents. Deny-by-default access rules.
Email Workplace & Productivity Security
1
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
google-workspaceOAuth
com.proscendia
Permissioned access to Gmail, Drive and Calendar via the user's own Google account
Email Cloud Storage Calendar Management
1
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

Related MCP Servers

Gmail & Google Docs MCP Server
Email Workplace & Productivity
Aparana-tech
F
license
Not graded
quality
D
maintenance
Enables AI assistants to send emails via Gmail and append text to Google Docs or local files.
Updated 3 months ago (2026-06-17 08:58 UTC)
-
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
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)
205 npm
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)
205 npm
MIT

Google Tools MCP Server (google-tools-mcp-server)

Features & Tools

1. Setup Google Cloud Credentials

2. Installation & Token Generation

Step A: Clone & Install Dependencies

Step B: Configure Environment Variables

Step C: Generate Refresh Token

Step D: Build the Server

3. Host Integration

AntiGravity / Cursor Integration

Claude Desktop Integration

4. Testing with MCP Inspector

5. Security & Architectural Invariants

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Google Tools MCP Server (`google-tools-mcp-server`)