Google Workspace MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct action and service (Docs vs. Gmail), with no overlapping purposes. Operations are clearly separated (e.g., draft_email vs. send_new_email, get_google_doc_metadata vs. read_google_doc).
Naming Consistency5/5
All tools follow a consistent verb_noun pattern (e.g., create_google_doc, draft_email, get_email_draft). No mixing of conventions or vague verbs.
Tool Count5/5
9 tools cover core operations for two distinct services (Docs and Gmail). The count is well-scoped, neither too few nor excessive for the stated purpose.
Completeness3/5
Core CRUD operations are present for Docs (create, read, append, metadata) but missing update and delete. Gmail covers drafting and sending but lacks listing drafts, deleting, or searching. Notable gaps but not severely incomplete.
Average 3.9/5 across 9 of 9 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only states the main action and return values. It omits behavioral traits such as whether the operation is read-only, if authentication is required, error behavior (e.g., missing draft_id), or any side effects. The description minimally adds value beyond the name.
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 three sentences: one for purpose, one for argument, one for returns. Every sentence is necessary and clearly structured. It is front-loaded with the core action. No wasted words.
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 retrieval tool with one parameter and no output schema, the description covers the essential purpose and parameter. However, it lacks context about error handling, prerequisites (e.g., existing draft), or more detailed return structure. It is minimally complete but could be enriched with typical usage notes.
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?
The input schema has 0% description coverage, so the description must compensate. It provides a basic meaning for 'draft_id' ('The ID of the draft to retrieve'), which adds value over the schema's bare property name. However, no additional context like format, source, or constraints is given. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Retrieve an existing email draft from Gmail', specifying the resource (email drafts) and the operation. However, it does not explicitly differentiate from sibling tools like 'draft_email' or 'update_email_draft', which reduces clarity purpose.
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. It does not mention prerequisites, context, or exclusions. For example, it does not indicate that this tool should be used only after a draft has been created via 'draft_email'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It only states the action without disclosing behavior like authentication requirements, error handling if draft doesn't exist, or side effects like marking the draft as sent.
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 concise and well-structured with a brief overview and explicit Args/Returns section. It is not verbose, though it could include more detail without sacrificing conciseness.
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 (one required parameter, no output schema, no annotations), the description covers the essential purpose and parameter. However, it lacks context on prerequisites, errors, or relationship to sibling tools, which would help 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?
The description adds meaning for the single parameter 'draft_id' by stating 'The ID of the draft to send,' which goes beyond the schema's empty description. However, it could provide more detail on how to obtain the ID.
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 'Send an existing email draft via Gmail,' which specifies the verb (send) and resource (existing draft). It distinguishes from sibling tools like draft_email (create) and send_new_email (compose and send).
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 when to use this tool (when you have a draft ID to send) but provides no explicit guidance on when not to use it or alternatives such as send_new_email. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It does not disclose side effects, authentication needs, or behavior on duplicate titles. It only mentions return types, lacking depth for a mutation 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 very concise with a clear Args and Returns structure. Every sentence adds value without 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 the tool's simplicity (2 params, no output schema), the description adequately explains the return value (ID, title, URL) and parameter roles. However, it lacks error handling details or usage context for edge cases.
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 0%, but the description explains both parameters: 'title' as the document title and 'content' as optional initial text. This adds meaning beyond the schema's type and required fields.
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 'Create a new Google Document,' which is a specific verb+resource pair, and it distinguishes from sibling tools like 'read_google_doc' and 'append_to_google_doc' by focusing on creation.
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 vs alternatives like 'append_to_google_doc' or 'draft_email'. The description lacks context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that content is added without overwriting and lists return values. With no annotations, the description carries full burden; it adequately describes the mutation behavior but lacks details on auth, rate limits, or error conditions.
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?
Concise with a clear main sentence, then sections for behavior, args, and returns. No fluff, front-loaded purpose.
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 no output schema, description includes return values. Covers core behavior and parameters. Could mention error scenarios or permissions, but overall adequate for a simple append 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?
Schema coverage is 0%, so description compensates minimally. It explains document_id as the ID and content as text, but no additional details like format, length limits, or constraints. This is basic, not rich.
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?
Clearly states 'Append content to the end of an existing Google Document.' The verb 'append' and resource are specific, and the action is distinct from siblings like create_google_doc and read_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?
Implied usage: use when you want to append to an existing doc. No explicit guidance on when not to use or compare with alternatives. The sibling list provides context but no direct exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it extracts text preserving paragraph structure, and returns doc ID, title, content, and URL. However, with no annotations, it does not cover auth requirements, rate limits, or read-only nature beyond the verb 'Read'.
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?
Straightforward three sentences: purpose, extraction detail, and Args/Returns section. Front-loaded with clear verb and resource. 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?
For a simple read tool with one parameter and no annotations or output schema, description adequately covers usage and return values. Could mention error handling or permissions, but overall complete enough for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'document_id' is described with a helpfultip on where to find it ('found in the document URL'), adding meaning beyond the schema which only has a title. Schema coverage is 0%, but description compensates fully.
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 'Read the full content of a Google Document,' using a specific verb and resource. It distinguishes from sibling tools like append_to_google_doc and get_google_doc_metadata by explicitly focusing on reading full content.
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 to read document content) but no explicit guidance on when to use vs alternatives like get_google_doc_metadata. Does not mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses it is a read-only operation that retrieves specific metadata fields. Does not mention auth or errors, but for a simple read, the behavioral traits are sufficiently clear.
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?
Concise and well-structured: short paragraph followed by Args and Returns sections. Every sentence adds value, no filler.
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?
For a simple tool with one parameter and no output schema, the description covers purpose, return fields, and what it does not do. Lacks error handling or prerequisites, but overall complete enough for effective use.
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 (document_id) with schema description coverage 0%. Description adds 'The ID of the Google Document' which is minimal but confirms its purpose. Lacks format or example, but baseline score of 3 is appropriate given the schema provides type and required info.
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?
Clearly states it gets metadata for a Google Doc, lists specific metadata (title, revision ID, URL, page size), and explicitly distinguishes from reading full content, differentiating it from sibling read_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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly tells when to use (when only metadata needed) and when not (full content needed) by stating 'without reading the full content'. Does not explicitly list sibling alternatives but the contrast with read_google_doc is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey behavior. It clearly states the action and return value (Draft ID, message ID, summary). Does not mention side effects, authentication, or error handling, but the tool is straightforward and non-destructive.
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?
Concise and well-structured: one-line purpose, bulleted parameter list, then return description. No fluff, every sentence adds value. Front-loaded with the most important 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?
For a 6-parameter tool with no output schema or annotations, the description covers all parameters and return fields. Lacks error conditions or prerequisites, but is otherwise complete for a simple draft creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining each parameter, including format (comma-separated for 'to'), optionality (cc, bcc, body_type), and default values. Adds significant meaning beyond schema titles and types.
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?
Starts with 'Create a new email draft in Gmail.' Clearly states verb (create), resource (email draft), and context (Gmail). Distinguishes from siblings like 'send_new_email' and 'get_email_draft' by focusing on draft creation.
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 guidance on when to use versus alternatives. The purpose is implied by the tool name and description, but there is no mention of when not to use or which sibling tool to prefer for sending vs. drafting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses immediate sending behavior, return details (message ID and thread details or error). Lacks authentication or rate limit info, but sufficient for common email sending.
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?
Concise opening, followed by a behavioral note, then structured args list, ending with returns. No extraneous text. Could be slightly more compact, but well-organized.
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?
Covers purpose, parameters, and return for a 6-param tool with no output schema. Does not explain error details in depth, but 'error information' suffices. No mention of attachments or throttling, but reasonable for the complexity.
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, so description adds significant value: explains comma-separated for multiple recipients, default values, and body_type options ('plain'/'html'). All parameters are meaningfully explained.
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 'Send an email directly via Gmail' and distinguishes from sibling tools by noting it sends immediately without creating a draft first. The verb 'send' and resource 'email' are specific.
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?
Description explicitly says 'without creating a draft first', contrasting with draft-related siblings. However, it does not provide explicit when-not-to-use guidance or list alternatives beyond the draft distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description carries burden. Discloses preservation of unchanged fields, a key behavioral trait. Lacks details on permissions or concurrency, but adequate for a simple update 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?
Concise with a one-line summary, usage hint, then clean parameter list. Every sentence adds value, no waste.
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?
Covers all 7 parameters with clear defaults and behavior. Mentions return value. Lacks preconditions (e.g., draft must exist) but acceptable for a simple tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides thorough parameter explanations (e.g., 'to: New recipient(s), or leave empty to keep existing'), adding meaning well beyond the schema's titles.
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 starts with a clear verb+resource ('Update an existing email draft in Gmail') and distinguishes from siblings like 'draft_email' and 'send_existing_draft' by implying it modifies an existing draft.
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?
Explicitly states 'Only provide the fields you want to change — unchanged fields will be preserved', guiding partial updates. Does not explicitly mention when not to use it, but the context with siblings makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![MCP-Server---Gmail-and-Doc MCP server](https://glama.ai/mcp/servers/risvan1605/MCP-Server---Gmail-and-Doc/badges/card.svg)](https://glama.ai/mcp/servers/risvan1605/MCP-Server---Gmail-and-Doc)

Score Badge

Copy to your README.md:

[![MCP-Server---Gmail-and-Doc MCP server](https://glama.ai/mcp/servers/risvan1605/MCP-Server---Gmail-and-Doc/badges/score.svg)](https://glama.ai/mcp/servers/risvan1605/MCP-Server---Gmail-and-Doc)

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/risvan1605/MCP-Server---Gmail-and-Doc'

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