gmail-mcp-server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
Multiple tools have overlapping purposes: list_emails and search_emails both return message lists with similar fields, read_email and read_email_with_privacy both read a single email, and download_attachment/download_attachment_safe/validate_attachment all handle attachment retrieval with safety. The descriptions help distinguish them, but the boundaries are still unclear and could cause misselection.
Naming Consistency4/5
Most tools follow a consistent verb_noun snake_case pattern (e.g., read_email, list_emails, send_email, get_profile). However, a few tools have irregular modifiers like '_with_safety', '_safe', '_local', and '_with_privacy', which breaks the uniformity slightly but does not create chaos.
Tool Count3/5
18 tools falls in the heavy range and feels slightly bloated due to redundancy. For instance, list_emails and search_emails overlap, and the attachment safety pipeline has three distinct tools that could be consolidated. Each tool has a purpose, but the count could be trimmed without losing capability.
Completeness3/5
Core Gmail workflows (read, search, send, reply, delete, labels) are covered, but there are significant gaps: create_draft has no way to send or update drafts, and get_labels exists but there are no tools to create or delete labels. This leaves workflows with dead ends, such as creating a draft that cannot be sent via the same server.
Average 3.7/5 across 18 of 18 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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, the description carries full responsibility for behavioral disclosure. It fails to mention that sending is an irreversible side effect, requires an authenticated session, may have rate limits, or that emails can include HTML and attachments. The bare phrase 'Send an email' reveals no behavioral traits.
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, front-loaded sentence with no extraneous content. It is appropriately concise for the tool's purpose, though its brevity limits detail in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (supports HTML, attachments, multiple recipients) and the absence of both annotations and an output schema, the description is insufficiently complete. It does not explain side effects, authentication prerequisites, or error behavior, leaving significant gaps for safe invocation.
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 provides 100% coverage with clear descriptions for all 7 parameters (to, cc, bcc, subject, body, isHtml, attachments). The description adds no additional parameter meaning beyond the schema, so it meets the baseline for high schema coverage.
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 tool sends an email via an authenticated Gmail account, using the verb 'send' and the resource 'email.' It is specific but does not explicitly differentiate from sibling tools like reply_to_email or create_draft, so it misses the full distinction criterion.
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. The description does not mention exclusions, such as using create_draft for drafts or reply_to_email for replies, and only offers a vague authentication context. This leaves usage decisions entirely to the agent.
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 of behavioral disclosure. It states that the tool returns base64-encoded data and MIME type, which is useful, but it does not clarify whether this operation is read-only, whether any safety checks are performed, or whether there are rate limits or size restrictions. Given the existence of a 'safe' variant, the lack of safety context is a notable omission.
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 two sentences long, front-loaded with the main action, and contains no fluff. Every word contributes value, and the return format is included without extraneous 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?
For a simple download function with two parameters and no output schema, the description states the purpose and return format adequately. However, it lacks any mention of how to obtain the required IDs (relying on schema hints), and it does not address the safety-sensitive nature of attachments, especially with a sibling 'safe' variant. This leaves the description slightly incomplete in context.
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 already has 100% coverage, describing both parameters clearly. The description adds no additional semantic meaning beyond what the schema provides, so the baseline score of 3 is appropriate. It does not clarify formats, constraints, or relationships beyond the schema.
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 verb ('Download') and resource ('a specific attachment from a Gmail message'), making the purpose unmistakable. It also specifies the return format (base64 data and MIME type). However, it does not explicitly distinguish from the sibling tool 'download_attachment_safe', which likely has a related but safer behavior, so it doesn't fully earn a 5.
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?
There is no guidance on when to use this tool versus its alternatives, such as 'download_attachment_safe' or 'list_attachments_with_safety'. The schema hints at needing an ID from 'read_email', but the description itself provides no context about prerequisites, exclusions, or choice criteria.
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?
With no annotations, the description carries the full burden. It discloses that the tool returns decoded body content and headers, which is useful. However, it does not disclose potential privacy risks, authentication requirements, or whether any transformation (besides decoding) occurs. The read operation appears safe from the name, but the description adds only moderate behavioral context.
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, clear, front-loaded sentence with no unnecessary words. It states the action ('Read'), object ('email'), scope ('full content'), and qualifiers ('by message ID', 'including headers and decoded body') efficiently.
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 with one parameter and no output schema, so the description covers the core functionality. However, given the existence of read_email_with_privacy and other siblings, the description could be more complete by clarifying when the plain read is appropriate versus the privacy-safe version. It also doesn't indicate potential sensitivity of the returned content, which is relevant context.
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 parameter description already explains that messageId is a Gmail message ID from list_emails or search_emails. The description adds no new parameter-level meaning beyond repeating the message ID requirement. Baseline 3 is appropriate given complete schema coverage.
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 tool reads a specific email's full content by message ID, including headers and decoded body. This distinguishes it from list_emails and search_emails, though it does not explicitly differentiate from the sibling read_email_with_privacy.
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 explicit guidance on when to use this tool versus read_email_with_privacy or other alternatives. It omits any mention of privacy-sensitive content or scenarios where the privacy variant might be preferred. The only implied usage is that a message ID is needed, which is already given in the schema.
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, the description carries the full burden of behavioral disclosure. It reveals the label-based mechanism but does not mention side effects, idempotency, permissions, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence that efficiently communicates the tool's purpose without unnecessary words or 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 one-parameter tool, the description adequately explains the core operation. Lacking an output schema or behavioral notes is a minor gap, but the low complexity makes the description sufficient.
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% for the single parameter messageId, and the schema already describes it as 'The Gmail message ID'. The description adds no additional parameter meaning, aligning with the baseline for high schema coverage.
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 (mark as unread) and the mechanism (adding the UNREAD label), distinguishing it from sibling tools like mark_as_read and set_labels.
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. The description only states the action without context, exclusions, or references to similar tools.
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?
With no annotations, the description carries the full burden. It discloses that processing is local and includes a deterministic fallback, which is useful. However, it does not state whether the operation is read-only, has side effects, or what the output format is.
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 sentence with no redundant words. It front-loads the primary action and appends a parenthetical with technical context, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema and annotations, so the description should clarify return behavior and limitations. It vaguely references an 'orchestrator with deterministic fallback' but does not explain what the tool returns or any edge cases, leaving the agent with incomplete understanding for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described in the input schema. The tool description adds no parameter-specific information beyond what the schema already provides, so the baseline score of 3 applies.
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 redacts sensitive content from provided text, using a specific verb and resource. It distinguishes itself from email-oriented sibling tools by focusing on generic text processing and a local privacy pipeline.
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 explicit guidance on when to use this tool versus alternatives. The description implies it is for redacting text, but lacks any mention of prerequisites, exclusions, or comparison with sibling tools like read_email_with_privacy.
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?
Without annotations, the description must carry the full burden of behavioral disclosure. It does add context by stating that the tool provides a 'policy-based safety assessment for each file,' which indicates the output includes safety evaluations. However, it does not explicitly state whether the operation is read-only, describe any side effects, or clarify the nature of the policy. This is adequate but not fully transparent for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence: 'List attachments for a message and provide policy-based safety assessment for each file.' It is front-loaded with the main action, contains no redundant information, and every phrase adds 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?
The tool has a simple input schema (one parameter) but no output schema or annotations. The description conveys the core purpose but does not detail the return structure or behavior when no attachments exist. It is minimally complete for a simple tool but leaves gaps regarding output details and edge cases.
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 provides a full description for the only parameter ('The Gmail message ID containing attachments'), achieving 100% schema description coverage. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
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's function: 'List attachments for a message and provide policy-based safety assessment for each file.' This specifies a concrete action (list) and resource (attachments for a message), and distinguishes from siblings like download_attachment_safe or validate_attachment by emphasizing listing plus safety assessment.
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 explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or comparisons with sibling tools such as download_attachment_safe or validate_attachment. The intended use is only implied by the tool's name and description.
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?
With no annotations, the description carries the full burden. It discloses that validation is local and lists the safety criteria, but omits the return format, error behavior, and whether any side effects occur.
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 concise sentence that front-loads the action and criteria. 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 validation tool, the purpose and criteria are clear, but without an output schema or annotation, the return value and behavior on failure are missing, making it slightly incomplete.
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 parameters are already well documented. The description adds no additional meaning beyond naming the attachment being validated.
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 (validate) and specific resource (one attachment against local safety policy), enumerating criteria (size, MIME type, extension, filename). This distinguishes it from sibling tools like download_attachment or list_attachments_with_safety.
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. It does not mention prerequisites, when not to use, or alternatives like list_attachments_with_safety or download_attachment_safe.
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?
With no annotations, the description carries the full burden. It discloses that it blocks risky files and enforces policy checks, which is useful behavioral info. However, it does not disclose the return format, size limits, or error behavior. It says 'before returning data' but does not specify what data. While the safety behavior is disclosed, important operational details remain missing.
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 sentence, front-loaded with the main action, and every word adds value. It is concise without being terse.
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 has a low-complexity footprint (2 params, no output schema), but it sits among closely related siblings (`download_attachment`, `validate_attachment`) and the description only vaguely distinguishes it. It does not explain the return value shape or the exact policy checks, leaving some ambiguity for an agent deciding between 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?
The input schema already provides full descriptions for both required parameters (messageId and attachmentId), and the description adds no additional parameter-specific context. Per calibration, schemas with >80% coverage get a baseline 3; the description does not elevate 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 uses a specific verb ('download') and resource ('one validated attachment'), and the phrase 'Safely' plus 'Blocks risky files' clearly distinguishes it from the plain `download_attachment` sibling. It clearly states what the tool does.
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 the tool is the safe/validated alternative to `download_attachment`, but it does not explicitly state when to use it versus `validate_attachment` or `list_attachments_with_safety`. It only implies safety context without naming alternatives or providing 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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns sender, subject, date, and snippet for each message, which is helpful. However, it does not mention default behaviors (e.g., default INBOX label, maxResults limits) or any side effects. The read-only nature is implied but not explicitly stated.
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 two sentences, front-loaded with the core action ('List emails from Gmail') and quickly presents filtering and return information. Every word earns its place with no redundancy or 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 tool with 3 optional, fully documented parameters and no output schema, the description adequately covers the purpose, filtering options, and return format. The main gap is the lack of guidance on when to use this tool versus the sibling 'search_emails', which would improve contextual completeness.
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 description coverage is 100%, so the baseline is 3. The description adds value by naming the return fields (sender, subject, date, snippet), which are not present in the schema. It also reinforces the filtering semantics of labelIds and query, though this is largely redundant with the schema.
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 ('List emails'), the target system ('Gmail'), and the scope ('filter by labels and/or a search query'). It also specifies the return fields (sender, subject, date, snippet). However, it does not explicitly distinguish itself from the sibling tool 'search_emails', which may perform a similar function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for listing emails with optional filters, providing context for typical use. However, it offers no explicit guidance on when to prefer this tool over alternatives like 'search_emails', nor does it mention any exclusions or use cases to avoid.
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 two behavioral traits (setting Reply-To headers, preserving the thread) beyond what annotations provide (none). However, it omits that this tool sends the email (vs. drafting) and does not mention other potential side effects like authentication or irreversible changes. With no annotations, more disclosure would be expected.
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: the first states the core purpose, the second adds key behavioral details. No filler, perfectly front-loaded and efficiently written.
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 reply tool, the description covers the main intent and two behaviors, but lacks explicit confirmation that the email is actually sent (critical given send_email and create_draft siblings). With no output schema or annotations, the agent may not know the full side effects or whether a draft is created instead. More context on sending behavior 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?
The input schema provides 100% coverage of parameter descriptions, so the baseline is 3. The tool description adds no extra parameter semantics; it only indirectly references messageId via 'thread' but does not explain parameter relationships or formatting beyond 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?
Clearly states the action ('Reply to an existing email thread') and distinguishes this from sending a new email or creating a draft. The mention of 'automatically sets Reply-To headers and preserves the thread' adds specificity beyond mere naming.
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 primary use case (replying to an existing thread) but does not explicitly contrast with sibling tools like send_email or create_draft. It gives clear context but lacks explicit when-not-to-use guidance or alternative tool names.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the key behavior that the email is not sent, but it omits additional context such as authentication requirements, what is returned (e.g., draft ID), or whether the draft is saved to the user's drafts folder. For a simple creation tool, 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 sentence that is to the point, free of redundancy, and front-loads the essential information. Every word adds value: the action (create), the object (draft email), and the qualifier (without sending).
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 simplicity of the tool and the complete schema coverage, the description is mostly complete. It could mention that the draft is saved, but the lack of an output schema and the non-destructive nature of the action make this a minor gap. The presence of sibling tools also provides additional context for the agent.
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 100% description coverage for all 7 parameters, with each property having a clear explanation. The tool description itself adds no parameter-specific details beyond what the schema provides, so the baseline 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 ('Create') with a clear resource ('a draft email in Gmail') and explicitly states 'without sending it,' which distinguishes it from the sibling tool send_email. It fully defines the tool's scope and action.
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 'without sending it' clearly implies that this tool is for preparing drafts rather than delivering emails, which provides a clear usage context. However, it does not explicitly name alternative tools (like send_email) or state when not to use this tool, so it lacks the strongest level of guidance.
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 are provided, so the description carries the full burden of behavioral disclosure. It clearly states the default action (move to Trash) and the optional permanent delete being 'irreversible', which is critical for a destructive operation. Missing minor details like permission requirements, but the key safety context is covered.
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 two concise sentences, leading with the primary action and then the optional parameter. No wasted words, information is front-loaded and easy to parse.
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 two-parameter tool with no output schema, the description covers the essential behavior and the key parameter nuance. It does not explain the return value, but that is not critical for a delete operation. Overall, it is sufficiently complete for the tool's complexity.
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 already describes both parameters (messageId and permanent) with full coverage. The description adds the 'irreversible' nuance for permanent, but otherwise restates what the schema provides. Baseline 3 is appropriate since the schema does the heavy lifting.
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's function: 'Move an email to Trash' with an optional permanent delete. This is a specific verb+resource combination that distinguishes it from siblings like read_email or mark_as_read.
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 makes it obvious when to use this tool (for deleting emails) but does not explicitly contrast it with alternatives or mention any prerequisites. For a straightforward delete tool, the usage is implied by the clear action, but explicit guidance is missing.
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?
With no annotations provided, the description carries the full burden. It discloses that only redacted subject/snippet/body fields are returned and that a local privacy pipeline is used, adding value. However, it does not mention potential side effects, prerequisites, or error behavior, which is a gap for a privacy-sensitive 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 one concise sentence with no redundant words. It front-loads the action ('Read one email') and efficiently conveys scope and method.
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 one-parameter tool, the description adequately covers purpose, return content, and processing method. It does not specify exact output format, but that is acceptable given no output schema and the low complexity.
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% for the single parameter 'messageId', so the description adds no further parameter semantics. Baseline 3 is appropriate since the schema already fully documents the 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 tool reads one email and returns privacy-redacted fields. It distinguishes itself from sibling 'read_email' by explicitly mentioning the privacy-redaction and local pipeline, making its purpose specific and unique.
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 this tool is for when privacy-redacted email content is needed, contrasting with the plain 'read_email' sibling. However, it does not explicitly name alternatives or state when not to use it, but the context is clear enough.
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?
The description indicates a read-only search and lists return fields, but with no annotations provided, it does not disclose limitations such as pagination, rate limits, or authorization requirements. The return info is useful but the disclosure is not extensive.
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 sentence that front-loads the verb and resource, stating what the tool does and what it returns without any redundancy or irrelevant detail.
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 simplicity of a 2-param tool with no output schema or annotations, the description covers the core functionality and return format. However, it lacks explicit confirmation of read-only nature and any potential side effects or limitations, so it is not fully 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?
The schema describes query and maxResults, but the description adds meaning by explaining the query uses Gmail syntax and specifies the returned fields (sender, subject, date, snippet), which goes beyond the schema's basic type 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 it searches Gmail using standard Gmail search syntax and lists the return fields (sender, subject, date, snippet). This distinguishes it from sibling tools like list_emails, which likely lists without search syntax.
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 search queries with Gmail syntax but does not explicitly compare to alternatives like list_emails or provide when-not-to-use guidance. The context is clear but there are no exclusions or explicit alternative recommendations.
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?
With no annotations provided, the description carries the full burden. It does disclose the return fields (label IDs, names, message counts) and notes both system and user labels, which is useful. However, it does not explicitly state read-only behavior, pagination, limits, or authentication requirements, leaving some behavioral aspects undisclosed.
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 sentence that is direct and front-loaded. It states the action, the resource, examples, and the return payload without any 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?
The tool is simple with no parameters and no output schema. The description fully covers what it returns and the scope of labels (system and user), which is sufficient for an agent to invoke it confidently. There are no missing prerequisites or hidden side effects.
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 zero parameters, so the baseline is 4. The description adds meaningful context by specifying that all labels are returned, eliminating ambiguity about what the tool covers. No parameter documentation is needed since the schema is empty.
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 'List' and identifies the resource as 'Gmail labels', clearly distinguishing it from sibling tools like set_labels. It further clarifies the scope by including both system labels (INBOX, SENT) and user-created labels.
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 use when you need to see all labels and their IDs/names/counts, but it does not explicitly contrast with alternatives or state when not to use it. There is no mention of sibling tools or exclusions, so guidance is implied rather than explicit.
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 the full burden. It transparently discloses the exact behavior: removing the UNREAD label. It does not mention side effects like handling already-read messages or permissions, but the core mutation is clearly stated. This is a good level of transparency for a simple 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, front-loaded sentence with no filler or redundant information. Every word earns its place, and it directly states the action and mechanism.
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 simple nature of the tool (one parameter, no output schema), the description is complete. It fully specifies what the tool does and the mechanism, making it sufficient for an agent to select and invoke correctly. No additional context is needed for this level of complexity.
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 clear description of messageId. The tool description adds no additional parameter context beyond what the schema provides. Per the rubric, a baseline of 3 is appropriate when the schema fully documents 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 tool's action: 'Mark an email as read by removing the UNREAD label.' It specifies a distinct verb and resource, and differentiates itself from sibling tools like mark_as_unread by explicitly mentioning the UNREAD label removal mechanism.
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 context: use when you want to mark an email as read. However, it does not explicitly state when not to use it or mention alternatives like set_labels. It's not misleading, but the guidance is minimal and inferred from the name and description.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It states the core operation ('Add and/or remove labels') and implies mutation, but it does not disclose potential side effects, error conditions for invalid IDs, or any required permissions. The reference to get_labels hints at validity concerns, but lacks depth.
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 two sentences, with the first sentence stating the purpose and the second providing a direct usage hint. Every word earns its place; it is appropriately sized and front-loaded with the main action.
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 (3 params, no output schema, no annotations), the description is largely complete. It covers the purpose, the prerequisite for valid IDs, and the operation. However, it could mention whether both add and remove can be performed in a single call (though 'and/or' implies yes) and any consequences of invalid IDs, which would make it fully self-contained.
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 baseline is 3. The description adds minimal semantic value beyond the schema: it explains that the tool adds and/or removes labels, which maps to addLabelIds and removeLabelIds, but it does not elaborate on parameter formats or examples beyond what the schema already provides.
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's function: 'Add and/or remove labels on an email.' It uses a specific verb (add/remove) and resource (labels on an email), and it is easily distinguished from sibling tools like get_labels, which retrieves labels rather than modifying them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use get_labels to obtain valid label IDs.' This instructs the agent to use a specific alternative for a prerequisite action, thereby clarifying when to use set_labels (label modification) and when not to (obtaining IDs). This directly addresses usage context and alternatives.
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 provided, the description carries the full burden of behavioral disclosure. It implicitly communicates a read-only, non-destructive operation through the verb 'Get', and explicitly notes the authentication requirement ('authenticated'). It also discloses the exact return values, which is the main behavioral output. It lacks explicit statements about side effects or rate limits, but the simplicity of the operation makes this acceptable.
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 with no filler. The first sentence states the action and outputs; the second gives a practical use case. Information is front-loaded and every word 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?
Given the tool's simplicity (no parameters, no output schema), the description fully covers what the agent needs: what the tool does, what it returns, and a use case. It is contextually complete for the tool's scope.
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 tool has zero parameters, so the baseline is 4. The description adds value by specifying the return fields, giving the agent a clear expectation of the output even without an output 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 the specific verb ('Get'), the resource ('authenticated Gmail user profile'), and the exact fields returned (email address, total message count, thread count). It distinguishes itself from sibling email tools by focusing on account-level profile data rather than message operations.
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 'Useful to verify the connection' provides a clear use case and context for when to invoke this tool. While it doesn't explicitly exclude alternative tools or list when not to use it, the description makes its purpose evident enough that an agent can decide appropriately.
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:

[![gmail-mcp-server MCP server](https://glama.ai/mcp/servers/enoch-sit/gmail-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/enoch-sit/gmail-mcp-server)

Score Badge

Copy to your README.md:

[![gmail-mcp-server MCP server](https://glama.ai/mcp/servers/enoch-sit/gmail-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/enoch-sit/gmail-mcp-server)

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/enoch-sit/gmail-mcp-server'

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