Which integrations are available for this server?

Search and read emails with filters by sender, subject, keyword, date range, or unread status. Provides compact plain-text output. Search files by name, full-text content, and type across My Drive and shared drives. Read text from Google Docs, Sheets, Slides, PDF, Word, Excel, and PowerPoint files.

How do I use google-nice-mcp?

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-nice-mcp Find emails from John about project updates since 01.01.2025" 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-nice-mcp

by Schneckenhausmann

Overview Schema Source Related Servers Discussions Admin

Python

Remote

google-nice-mcp

The Google Workspace MCP server that's actually nice to small local LLMs.

Why this exists

Most Google Workspace MCP servers expose 30+ tools across a dozen services (Gmail, Calendar, Docs, Sheets, Slides, Tasks, Chat, Forms…). That floods a small model's context window and wrecks tool selection — a 7B local model staring at 30 tools will pick the wrong one.

This server does the opposite. It's a focused, read-only context-gatherer: just Gmail and Drive, just 5 tools, with plain typed parameters (no Gmail/Drive query DSL to memorize) and compact plain-text output instead of raw API JSON. The point is to let your local LLM learn about your project from your mail and files — not to manage your account.

Related MCP server: google-workspace-mcp

Features

🎯 Just 5 tools — small enough that a local model reliably picks the right one.
🧰 Gmail + Drive read — search and read email; search Drive by name or file content; read Docs, Sheets, Slides, PDF, Word, Excel and PowerPoint as text.
🗂️ Shared drives included — searches My Drive and shared/team drives together.
🗓️ Forgiving inputs — filter by sender / subject / keyword / file_type instead of query syntax, and write dates as dd.mm.yyyy.
📉 Token-cheap output — compact plain text, truncation, self-explaining errors.
🔒 Read-only by scope — gmail.readonly + drive.readonly. It physically cannot send, delete, or modify anything.

Tools

Tool	Purpose
`gmail_search`	Find emails by keyword, sender, subject, date range, or unread.
`gmail_read_email`	Read one full email — headers, plain-text body, attachment names.
`drive_search`	Find files by name, full-text content, and type, across My Drive and shared drives.
`drive_read_file`	Read a file's text: Google Docs/Sheets/Slides, PDF, Word (`.docx`), Excel (`.xlsx`), PowerPoint (`.pptx`).
`drive_list_shared_drives`	Discover which shared drives you can access.

Friendly inputs everywhere

Dates (gmail_search) use dd.mm.yyyy — e.g. 31.12.2026. Normalized internally to what the Gmail API requires; YYYY-MM-DD is also accepted.
File types (drive_search) are simple aliases: doc, sheet, slides, pdf, folder.
Bad input gets a self-explaining error, not an empty result.

1. Set up Google Cloud OAuth (one time)

Open the Google Cloud Console and create a project (or pick one).
Enable the APIs: APIs & Services → Library → enable Gmail API and Google Drive API.
Configure the consent screen: APIs & Services → OAuth consent screen.
- User type External is fine for a personal account.
- Add your Google account under Test users (so you don't need app verification).
Create credentials: APIs & Services → Credentials → Create Credentials → OAuth client ID.
- Application type: Desktop app.
- Download the JSON.
Save that JSON as ~/.config/google-nice-mcp/credentials.json (or set GOOGLE_NICE_CREDENTIALS to point at it).

2. Install & authenticate

git clone https://github.com/Schneckenhausmann/google-nice-mcp.git
cd google-nice-mcp
uv sync                       # installs into .venv
uv run google-nice-mcp-login  # opens a browser; approve read-only access

The token is cached at ~/.config/google-nice-mcp/token.json and refreshed automatically. Re-run the login only if you revoke access or change scopes.

3. Configure

Environment variables (all optional):

Variable	Default	Purpose
`GOOGLE_NICE_CONFIG_DIR`	`~/.config/google-nice-mcp`	Where credentials/token live.
`GOOGLE_NICE_CREDENTIALS`	`<config>/credentials.json`	OAuth client file path.
`GOOGLE_NICE_TOKEN`	`<config>/token.json`	Cached token path.

Claude Desktop / Claude Code

{
  "mcpServers": {
    "google-nice": {
      "command": "uv",
      "args": [
        "--directory",
        "/absolute/path/to/google-nice-mcp",
        "run",
        "google-nice-mcp"
      ]
    }
  }
}

Local LLM clients (Ollama, LM Studio, …)

Use the same command / args in whatever MCP config your client supports. The server speaks MCP over stdio, so anything that can launch a stdio MCP server works.

Example prompts

"Find emails from anna@acme.com about the Q3 budget since 01.01.2026 and summarize them."
"Search my Drive for files containing 'onboarding checklist' and read the most recent one."
"What shared drives do I have access to, and which contain a file named 'roadmap'?"
"Read the PDF spec in Drive (file id …) and list its requirements."

Develop

uv sync               # install deps
uv run google-nice-mcp  # run the server over stdio

Source layout: tools in server.py; Gmail/Drive API helpers in gmail.py / drive.py; file-text extraction in extract.py; OAuth in auth.py.

Notes

Read-only. Nothing can be sent, deleted, or modified.
Long files are truncated by drive_read_file's max_chars (default 20k); raise it to read more.
Scanned/image-only PDFs have no extractable text and will say so (no OCR).

Acknowledgments

Built fresh, but inspired by excellent prior work in the Google Workspace MCP ecosystem — thank you to their authors:

taylorwilsdon/google_workspace_mcp by Taylor Wilsdon — the most feature-complete Workspace MCP server; we drew on its Drive export-MIME mappings and native-vs-binary file handling.
aaronsb/google-workspace-mcp by Aaron Bushnell — clean read-focused Gmail/Drive tool surface.

Full third-party license notices are in CREDITS.md.

License

Available Tools

5 tools

drive_list_shared_drivesA

List the shared drives you can access (id and name).

Useful for discovering where project files live before searching.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

Without annotations, the description carries full transparency burden. It correctly implies a read-only listing operation, but it does not disclose potential pagination, rate limits, or permission requirements. The description is minimal but not misleading.

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 with no wasted words. The primary action is front-loaded, and the second sentence adds valuable usage context. Every sentence earns its place.

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 parameterless listing tool with an output schema, the description is complete. It explains the purpose and suggests when to use it, while the output schema presumably covers return value details.

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?

There are no parameters, so the description adds value by specifying output fields (id and name). With 100% schema coverage and zero params, the baseline is 4, and the description meets expectations.

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 it lists shared drives with id and name, and the verb 'list' precisely indicates the action. It distinguishes from sibling tools like drive_read_file and drive_search, which serve different purposes.

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 suggests using this tool before searching to discover project files, providing clear context. It does not explicitly mention when not to use it or alternative tools, but the guidance is sufficient for the tool's simplicity.

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

drive_read_fileA

Read the text content of a Drive file by its id (from drive_search).

Handles Google Docs, Sheets and Slides (exported to text/CSV) as well as PDF, Word (.docx), Excel (.xlsx) and PowerPoint (.pptx) files. Long files are truncated to max_chars; raise it to read more.

ParametersJSON Schema

Name	Required	Description	Default
`file_id`	Yes
`max_chars`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

Discloses truncation behavior and supported file formats. No annotations exist, so description carries the burden. Lacks details on permissions, failure modes, or read-only nature.

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, front-loaded with purpose. Every sentence provides essential info with no redundancy.

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 output schema exists, description doesn't need return values. Covers file types, truncation, and ID origin. Could mention plain text output or CSV for Sheets, but it's still effective.

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 has 0% description coverage. Description adds meaning: file_id is 'from drive_search', max_chars default is 20000 and adjustable. Both parameters are explained 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?

Clear verb+resource: 'Read the text content of a Drive file by its id'. Explicitly distinguishes from siblings like drive_search (finds files) and gmail tools.

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?

Tells when to use: 'Handles Google Docs, Sheets and Slides ... PDF, Word, Excel, PowerPoint'. Provides guidance on max_chars for truncation. Could be more explicit about when not to use, but sibling context clarifies.

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

drive_searchA

Search Google Drive (your files and shared drives) and list matches.

Filter by words in the file name, words found inside the file content (full-text), and/or file_type. Valid file_type values: doc, sheet, slides, pdf, folder. With NO filters, returns your most recently modified files. Set include_shared_drives=False to limit to your own Drive. Returns id, name, type, owner and last-modified time. Use the id with drive_read_file to read the contents.

ParametersJSON Schema

Name	Required	Description	Default
`name`	No
`content`	No
`file_type`	No
`include_shared_drives`	No
`max_results`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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 that it returns id, name, type, owner, and last-modified time. It also explains the scope (own Drive vs. shared drives via include_shared_drives). It does not mention permission requirements, rate limits, or potential performance impacts of full-text search, but overall provides sufficient transparency for a search 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?

The description is a single, well-structured paragraph. It begins with the core purpose, followed by filtering details, default behavior, parameter guidance, return format, and chaining to another tool. Every sentence adds value, with no redundancy or 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?

Given the input schema complexity (5 parameters, all optional) and the presence of an output schema (not shown but referenced), the description provides all necessary context. It covers filtering, default behavior, return fields, valid file types, and chaining. The only minor gap is an explicit mention of max_results, but its default and purpose are inferable.

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 input schema has 5 parameters with no descriptions (0% coverage). The description explains the purpose of name, content, file_type, and include_shared_drives parameters, and lists valid file_type values ('doc, sheet, slides, pdf, folder'). It covers max_results implicitly by mentioning 'most recently modified files' and default behavior, but does not explicitly describe the parameter. Overall, it adds significant 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?

The description clearly states that the tool searches Google Drive files and shared drives, listing matches with filtering options. It distinguishes itself from siblings: drive_list_shared_drives focuses on listing shared drives, drive_read_file reads content using the returned id, and gmail tools are unrelated. The verb 'Search' plus resource 'Google Drive' and scope 'your files and shared drives' make the purpose specific and unambiguous.

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 explains when to use the tool: for searching by file name, content, or type, and mentions default behavior (most recently modified files). It also directs using the id with drive_read_file for reading contents. However, it does not explicitly state when not to use this tool or list alternatives, though siblings like drive_list_shared_drives are implicitly distinguished.

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

gmail_read_emailA

Read one full email by its id (from gmail_search).

Returns headers, the plain-text body, and the names of any attachments.

ParametersJSON Schema

Name	Required	Description	Default
`message_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description bears the full burden. It discloses the return contents but does not mention side effects, error handling, or permissions. For a read operation, it is adequate but not exhaustive.

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 extremely concise, with two sentences that front-load the core functionality and return value. No unnecessary words.

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 a single parameter, no annotations, and an output schema, the description explains the return structure. It lacks details on potential errors or limitations but covers the essential information for a simple read tool.

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?

Only one parameter (message_id) exists, and schema description coverage is 0%. The description adds context that the id comes from gmail_search, but does not specify format or constraints, leaving room for ambiguity.

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 tool reads a full email by its id, specifying what is returned (headers, body, attachment names). It also mentions the id comes from gmail_search, distinguishing it from sibling tools.

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 using gmail_search first to obtain the message_id, providing clear context for when to use this tool. However, it does not explicitly state when not to use it or mention alternative tools.

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

gmail_searchA

Search your Gmail and return a compact list of matching emails.

Filter by any combination of: a free-text keyword (matches anywhere), a sender email/name, words in the subject, and a date range. Dates use dd.mm.yyyy (e.g. 31.12.2026). 'after' means on/after that day, 'before' means before that day. With NO filters, returns your most recent emails. Returns id, from, subject, date and a short snippet for each hit. Use the id with gmail_read_email to read the full message.

ParametersJSON Schema

Name	Required	Description	Default
`keyword`	No
`sender`	No
`subject`	No
`after`	No
`before`	No
`unread_only`	No
`max_results`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

No annotations present, so description covers all behavioral traits: returns specific fields (id, from, subject, date, snippet), date range meanings (after=on/after, before=before day), and default behavior with no filters. Mentions max_results indirectly via default, but does not disclose rate limits or pagination.

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?

Four sentences, front-loaded with purpose, followed by filtering details, date format, and mention of sibling tool. No redundant or irrelevant content.

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?

Despite no annotations and many parameters, the description sufficiently explains search behavior, input combinations, return fields, and link to gmail_read_email. Output schema exists, so return format details are covered.

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 has 7 parameters with 0% description coverage. Description covers keyword, sender, subject, after, before (5/7) but omits unread_only and max_results. While it gives context for most parameters, two are left undocumented, requiring compensation that is not fully provided.

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 the tool searches Gmail and returns a compact list. It identifies the specific verb 'Search' and resource 'your Gmail', and distinguishes from the sibling gmail_read_email by mentioning it can be used with the returned ids.

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?

Explains when to use filters and that no filters returns recent emails. Provides date format and semantics. Could explicitly mention when not to use, but alternatives (gmail_read_email) are referenced for reading full messages.

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.

5 tool updatesv0.1.0Jun 18, 2026
- First observeddrive_list_shared_drives
- First observeddrive_read_file
- First observeddrive_search
- First observedgmail_read_email
- First observedgmail_search

Deploy Server

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

TDQS

A4.2/5.0

Scored 2026-06-18 14:25 across 5 tools

Disambiguation5/5

Tools are clearly separated by service prefix (drive_ vs gmail_) and have distinct purposes: listing drives, searching and reading files, searching and reading emails. No overlap in functionality.

Naming Consistency4/5

All tools follow a service_verb[_object] pattern with underscores, but some use a bare verb (drive_search, gmail_search) while others include an object (drive_list_shared_drives, drive_read_file, gmail_read_email). Slight inconsistency but the pattern is predictable.

Tool Count5/5

With 5 tools covering two Google services, the count is well-scoped. Each tool serves a clear purpose and there is no bloat or deficiency for the apparent scope.

Completeness3/5

The server covers search and read operations for both Drive and Gmail, but lacks any write or update capabilities (e.g., create, delete, send). This is a notable gap that may require additional tools for full lifecycle coverage.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24
thoughtsOAuth
ai.thoughtbox.api
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Cloud Storage Finance
2
ORANO MCP Server
io.github.infotik
Read-only MCP server exposing a user ORANO library to their own AI agent.
Note Taking Knowledge & Memory Search
1
saagarpatel.dev Portfolio A
io.github.saagpatel
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Search Documentation Access
82

Related MCP Servers

Gmail MCP Server
Email Search
jlg-formation
A
license
Not graded
quality
B
maintenance
Read-only MCP server for Gmail that enables searching threads, reading messages, and listing labels without any write access.
Updated 3 months ago (2026-06-21 11:05 UTC)
81
MIT
google-workspace-mcp
Calendar Management Email Cloud Storage
Remenby31
A
license
Not graded
quality
B
maintenance
A single-tool MCP server for Google Calendar, Gmail, and Drive, designed for LLM context efficiency with compact output and multi-account support.
Updated 3 months ago (2026-06-23 08:13 UTC)
1,091
MIT
gmail-research-mcp
Email Research & Data
bajor
F
license
Not graded
quality
B
maintenance
A read-only Gmail MCP server that searches email, fetches complete threads, and stores them as local Markdown and JSON for offline analysis by other agents.
Updated a month ago (2026-07-30 18:54 UTC)
1
-
MailMesh MCP
Email Communication
culpen90
F
license
Not graded
quality
B
maintenance
A private, single-user MCP server that unifies Gmail, Microsoft 365/Outlook, and IMAP mailboxes for LLMs to search and read emails live, without storing or caching mailbox contents.
Updated a month ago (2026-08-14 15:24 UTC)
-