gmail-mcp-imap

Server Quality Checklist

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

Latest release: v1.0.3
Disambiguation4/5
Most tools target a distinct resource and action, but the five get_*_emails category tools are very similar in shape and could be mistaken for one another without reading the category name closely. download_attachment and save_attachment also overlap as two ways to fetch the same attachment.
Naming Consistency4/5
The dominant verb_noun pattern is clear and consistent, but there are minor deviations: get_emails_by_label uses a prepositional structure, get_email_content is singular while other retrievers are plural, and mark_as_read/mark_as_unread differ slightly from the simpler verb_noun style used elsewhere.
Tool Count3/5
19 tools is on the heavy side for an MCP server and includes reducible duplication: five category getters could be one parameterized tool, and download_attachment/save_attachment serve nearly the same need with different output handling. The remaining tools are relevant, but the set feels padded.
Completeness4/5
The core Gmail lifecycle is covered: retrieve, search, read, send, reply, flag, star, delete, label, and attachments. Missing operations like remove_label, create_label, or draft management are notable but not critical gaps for a full Gmail surface.
Average 3.6/5 across 19 of 19 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It only says 'Reply to an existing email' without stating whether this sends the reply immediately, creates a draft, requires authentication, modifies the original email, or how threading and attachments are handled.
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 one short, front-loaded sentence with no filler. It is efficient and easy to parse, though it sacrifices behavioral context that would have made it more useful.
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?
With no annotations and no output schema, the description needs to supply behavioral and selection context, but it does not. The agent is left to infer what 'reply' means operationally and how it differs from send_email, despite the schema covering the parameters well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are fully described in the input schema, including the nuance about mailbox and UID uniqueness. The description adds no additional parameter meaning, but with 100% schema coverage the baseline of 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 states a specific verb and resource: 'Reply' to 'an existing email'. This clearly communicates the core operation and, at a basic level, distinguishes it from composing a new email via send_email. However, it does not name the sibling alternative explicitly or add scope details.
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 explicit guidance on when to use this tool versus send_email or other siblings. The phrase 'existing email' implies a precondition, but the description never states when to prefer this tool, what inputs are prerequisites, or how it differs from related tools in the sibling list.
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 disclosing behavior, but it only restates the basic download-and-save action. It does not mention whether an existing file is overwritten, whether directories are created, what happens if the attachment is missing, or what the operation returns.
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 a single efficient sentence with the action front-loaded and no filler. It is appropriately compact, though it is lean enough that other dimensions have to compensate for missing context.
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?
For a file-writing tool with no annotations and no output schema, the description is too thin to be complete. It omits return behavior, filesystem side-effect details, and any relation to sibling tools, so an agent lacks important context 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 description coverage is 100% and each parameter already has a meaningful description, so the baseline is 3. The description adds no new parameter-level detail beyond echoing the existence of a file path, which keeps it at that baseline.
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 identifies a specific action (download an email attachment) and an output destination (save to a file path), so an agent can broadly understand what the tool does. It does not explicitly distinguish this from the sibling download_attachment, leaving some ambiguity about which tool to choose.
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 gives no guidance on when to prefer save_attachment over download_attachment, list_attachments, or other email tools, and it states no prerequisites or exclusions. The only usage signal is the verb phrase itself, which is not enough for routing among highly similar siblings.
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 the action but does not say whether the label replaces existing labels, whether the label must already exist, or what side effects or errors might occur. This is too opaque for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero filler. Every word contributes to stating the operation clearly, making it easy to parse quickly.
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 schema covers parameter semantics, including the mailbox caveat, but the description lacks usage guidelines and behavioral details. For a simple labeled action this is minimally viable, but it leaves gaps around when to use it and what the operation actually does beyond the literal statement.
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 input schema already documents all three parameters. The description adds no additional meaning about uid, label, or mailbox beyond what the schema states, which meets the baseline but does not exceed it.
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 identifies a specific verb and resource ('Apply a label to an email'), making the operation clear at a glance. It does not explicitly differentiate from siblings like list_labels or get_emails_by_label, but the action semantics are distinct enough that an agent can infer which tool to use.
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 given on when to use this tool versus alternatives such as star_email or mark_as_read. The only contextual clue about mailbox requirements appears in the input schema, not the description, leaving selection criteria entirely to the agent's inference.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the operation mutates an email's starred state, but it does not mention idempotence, default behavior, required mailbox context, error conditions, or what response to expect.
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 short sentence with no filler and is appropriately sized for a simple toggle operation. It 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers all parameter semantics, and the operation itself is simple, so the minimal description is mostly adequate. However, with no annotations and no output schema, the description still lacks guidance on when to choose this tool over siblings and what behavior or response to expect after calling it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description adds no parameter-level meaning beyond what the schema provides, which 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 states a clear verb and resource: it stars or unstars an email, which is unambiguous and matches the tool name. It does not explicitly differentiate from sibling tools, but no other sibling is a star operation, so the purpose is still clear.
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 about when to use this tool versus alternatives like apply_label, mark_as_read, or mark_as_unread. The description implies the tool is used to toggle the starred state, but it does not state conditions, prerequisites, or 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, the description carries the full burden of behavioral disclosure. It states that the tool sends an email, but does not disclose side effects, delivery semantics, authentication requirements, whether sending is immediate, or what response to expect. This is minimal coverage for an action with real external effects.
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. 'Send a new email' immediately states the action and object, and the attachment qualifier is the only extra detail. It is concise without being under-specified in structure, though other dimensions capture the lack of depth.
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?
This is a 7-parameter tool with a nested attachments object, no output schema, and no annotations. The description does not explain return values, required permissions, or when to prefer this over reply_to_email. The schema covers fields well, but the description leaves important operational context missing.
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 parameters are already well documented in the schema. The description only adds 'optional attachments,' which duplicates existing schema information rather than adding new semantic meaning. The baseline of 3 is appropriate because the schema carries the weight.
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 and resource: 'Send a new email with optional attachments.' This clearly identifies the action and distinguishes it from sibling tools like reply_to_email, since it explicitly says 'new email.' It gives the agent enough to know what the tool does at a glance.
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 about when to use this tool versus alternatives such as reply_to_email or draft-related operations. There is no mention of context, prerequisites, or exclusions, so the agent must infer usage from the tool name alone.
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?
Annotations are absent, so the description carries the full behavioral burden. It discloses only the intended state change and nothing about idempotency, reversibility, permissions, or response behavior. This 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?
A single short sentence with no filler or redundant clauses. It states the verb and object clearly in the first few 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 mutation with complete schema coverage, the core invocation is clear. However, without annotations or an output schema, the description leaves side effects, return value, and failure behavior unspecified; adequate for a basic call, but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (uid and mailbox) with 100% coverage, and the mailbox description already explains UID uniqueness. The tool description adds no parameter-level semantics 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?
States a specific, unambiguous action ('Mark an email as read') and clearly contrasts with sibling mark_as_unread, star_email, and delete_email. An agent knows exactly what state change this performs.
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 when-to-use guidance is provided. It doesn't say to prefer this over mark_as_unread or explain the conditions under which it should be used; an agent must infer usage from the tool name and context.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and gives no information about side effects, whether the operation is reversible, whether it requires special permissions, idempotency, or what happens if the email is already unread.
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 a single, clear, front-loaded sentence with no filler. It is concise but slightly under-specified for behavioral transparency, so it does not earn a top score.
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 two-parameter mutation with no output schema, the description and schema combine to convey the core operation and the important mailbox caveat. However, because there are no annotations, missing behavioral details such as success confirmation, errors, and effects on mailbox state leave a moderate gap.
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%, including useful details like the mailbox default and the importance of mailbox for UIDs from get_emails_by_label. The description itself adds no parameter semantics, but the schema already documents both parameters well.
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 'Mark an email as unread' uses a specific verb and resource, and clearly identifies the state change being performed. It naturally distinguishes itself from the sibling mark_as_read by naming the opposite state.
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?
Usage is implied by the action itself: use this tool when an email should be marked unread. However, there is no explicit guidance about when not to use it, prerequisites, or how it differs from related actions like mark_as_read or star_email.
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 does disclose the non-obvious return format (Base64) and implies a read-only download. However, it does not mention error behavior, size limitations, authentication needs, or whether the email is modified.
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 with no wasted words. The first sentence states the action and output format, and the second states the intended use case. Both sentences earn their place.
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 core behavior and return format are covered, and the schema handles parameter semantics well. However, with no annotations and no output schema, the description could better address how this differs from save_attachment and what happens when an attachment is not found.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter, including the mailbox default and UID scoping, is documented in the schema. The description adds no additional parameter-level guidance beyond what the schema already 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (download) and resource (email attachment), and specifies the output format (Base64 encoded data). It does not explicitly differentiate this tool from the sibling save_attachment or list_attachments, but the core purpose is unambiguous.
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 phrase 'Use this to save attachments locally' gives a concrete use case, but it does not explain when not to use the tool or how it differs from the sibling save_attachment. Usage 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure, but it only says the tool retrieves full content. It does not mention side effects, authentication needs, response format, or limitations such as whether attachments are included. 'Full content' adds some meaning but leaves significant behavioral ambiguity.
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. Every word contributes to identifying the action and target, making it highly efficient for an agent to parse quickly.
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 operation is simple and the schema covers parameters well, but there is no output schema and no annotation to fill in behavior. 'Full content' is vague about what is returned, and no usage context or exclusions are provided. It is minimally adequate but leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains that uid comes from list results and mailbox defaults to INBOX, with a necessary caveat for get_emails_by_label. The tool description itself adds no parameter meaning beyond the schema, so the baseline 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 states a specific verb and resource: 'Get full content of a specific email by its UID.' This uniquely identifies the operation among siblings, none of which offer retrieval of individual email content by UID.
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?
Usage is only implied through 'by its UID' and the schema's note that UIDs come from email list results and are mailbox-scoped. The description does not explicitly say when to choose this tool over search_emails or get_emails_by_label, nor does it mention the mailbox caveat outside the parameter schema.
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 behavioral transparency burden. It discloses a key limitation: search covers subject and sender only, not body or other fields. However, it does not mention sorting, result shape, pagination behavior, or whether it searches across all mailboxes, which would be valuable 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, front-loaded sentence with zero filler. It states the core behavior and the most important scope limitation 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?
For a simple two-parameter search tool with no output schema, the description is reasonably complete: it states search targets and the fields searched. Yet it omits guidance on when to use this versus label-based or category-specific sibling tools, and does not clarify what a successful result looks like.
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%, with both 'query' and 'limit' already documented. The description repeats the query behavior already present in the schema and adds no new parameter-level detail, so the baseline of 3 applies.
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 identifies the operation ('Search emails'), the resource, and the key scope: 'searches in subject and sender'. It is not a tautology and distinguishes this from label-based or category-based retrieval, though it does not explicitly name a sibling alternative.
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 the user wants keyword-based email search over subject and sender. However, it does not explicitly state when not to use it or mention alternatives like get_emails_by_label or category-specific retrieval, leaving some ambiguity for an agent deciding between 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 provided, the description carries the burden of behavioral disclosure. It does reveal useful behaviors: supports date-filter paging and returns a `mailbox` field for chaining to UID-based tools. However, it does not explicitly state that the operation is read-only, does not mention result sorting/ordering, and does not describe error behavior (e.g., unknown label). These are meaningful gaps for a tool with no annotation safety hints.
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 long and front-loaded with the core purpose. Each sentence earns its place: the first defines the operation, the second explains paging, and the third links results to downstream tools. No filler or redundancy.
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 there is no output schema, the description should explain return values enough for an agent to use them. It highlights the `mailbox` field but does not mention whether results include a UID, message ID, or other fields needed by 'UID-based tools'. It also does not explain how to obtain valid label names (e.g., through `list_labels`). These omissions matter because the agent must correctly chain to `get_email_content` and similar 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 100% coverage of all four parameters, so the description's marginal contribution is limited. It does reinforce that after/before are used for paging and gives label examples, but the schema already documents the date formats and the paging use of `before`. No additional semantics are added for `limit` beyond what the schema states.
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+resource construction ('Get emails from a specific label or folder') and provides concrete examples such as 'Github' and '[Gmail]/Sent Mail', making the tool's purpose immediately clear. It distinguishes itself from category-based sibling tools by emphasizing arbitrary labels/folders, and the mention of passing `mailbox` to UID-based tools clarifies its role in the workflow.
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 gives useful context about paging with after/before date filters and how to use the result (`mailbox` field) with `get_email_content`, but it does not explicitly say when to choose this tool over siblings like `get_primary_emails`, `search_emails`, or `list_labels`. There is no 'when not to use' guidance or differentiation from alternative tools for the same objective.
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 burden of disclosing behavior. It does state the key side effect — moving an email to trash — which implies recoverability, but it does not mention whether the message is expunged, how repeated deletion is handled, or what response or errors to expect.
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 five-word sentence with no filler. It is clear, front-loaded, and every word contributes to the core meaning.
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 mutation tool with a fully documented schema, the description is largely complete: it names the operation, the target, and the destination. It could add a bit more behavioral context, but the schema already covers the mailbox default and required uid.
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 both uid and mailbox are already fully documented. The description adds no parameter-level meaning beyond the schema, which is acceptable given the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Move') and resource ('an email') and clearly communicates that the action is a soft delete to trash. This distinguishes it from other email action tools such as mark_as_read, apply_label, or send_email.
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 use case is implied: call this when an email should be removed from a mailbox and placed in trash. However, the description does not provide explicit when-to-use or when-not-to-use guidance, such as clarifying that this is not a permanent deletion or when the mailbox parameter is needed.
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 behavioral burden. It does convey that only Primary-category emails are returned, which is useful selection behavior. It does not describe sort order, pagination behavior, or return shape, but the operation is an obvious read and the schema documents limits.
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. Every word contributes to identifying the resource and its semantic meaning.
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-only list tool with fully documented optional parameters, the description is nearly complete. It lacks an explicit note about return format, but the absence of an output schema is partially mitigated by the obvious 'get emails' semantics and clear category definition.
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%, with all three parameters already documented including formats, defaults, and bounds. The description adds no parameter-specific detail, but none is needed because the schema already handles this dimension.
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 names a specific verb and resource: 'Get emails from Primary category,' and adds clarifying context with 'important conversations from real people.' This clearly distinguishes it from category-specific siblings like get_social_emails, get_promotions_emails, and get_updates_emails.
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 category label and 'important conversations from real people' imply when the tool should be used, and sibling names make the broader taxonomy clear. However, it does not explicitly state when not to use it or name alternatives, so routing 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.
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 for behavioral disclosure. It conveys a read operation via 'Get' and scopes it to the Updates category, which is helpful. However, it does not mention whether returned items are metadata versus full content, or describe ordering/pagination behavior beyond the schema-provided limit.
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 that front-loads the core action and resource, then adds clarifying examples. Every word earns its place, and it is neither padded nor underspecified.
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 no output schema and no annotations, so the description must shoulder more explanatory weight. It tells the agent what category of emails to fetch, but it does not describe return value shape or whether this returns summaries rather than full message content. Given the sibling get_email_content exists, this boundary is not fully addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and all three parameters (after, limit, before) already have meaningful descriptions. The tool description adds no additional parameter-level detail, which is acceptable given the schema's completeness, but it also does not enhance the agent's understanding 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 identifies the resource ('emails from Updates category') and the action ('Get'), with concrete examples like receipts and statements. It also differentiates from sibling category tools such as get_primary_emails and get_promotions_emails.
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 gives clear context for when to use the tool by scoping it to the Updates category and illustrating with transactional email examples. It does not explicitly state when not to use alternatives, but the category naming and examples make the intended use fairly unambiguous.
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 behavioral transparency burden. 'Get emails' indicates a read-only retrieval operation and the category scope is clear, but the description does not mention return format, ordering, pagination, or confirm there are no side effects. This is acceptable for a simple read tool but not rich behavioral disclosure.
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 efficient sentence with front-loaded verb and resource, followed by a useful parenthetical clarification. There is no filler or redundant information; every word adds value.
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 low-complexity read tool with three optional parameters and no required inputs, the description combined with the 100% schema coverage is largely complete. It explains what category of emails is fetched and the schema handles invocation details; only the absence of explicit return-format information keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters after, before, and limit are already fully documented with formats, constraints, and defaults. The description adds no parameter-level semantics, which is fine given the baseline of 3 for high 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 names a specific verb ('Get emails') and specific resource ('Forums category'), and further clarifies with examples ('mailing lists, discussion groups, online forums'). This clearly distinguishes it from sibling category getters like get_primary_emails or get_social_emails.
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 clearly establishes the intended context: retrieving emails from the Forums category. It implies the tool is the right choice when that specific category is desired, but it does not explicitly state exclusions or when to prefer a sibling tool like search_emails, so it stops short of a 5.
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. The verb 'Get' implies a read-only, non-destructive operation, but the description does not disclose potential side effects, rate limits, or whether emails are marked as read. This is minimally transparent 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?
A single, information-dense sentence that front-loads the core action and category, then provides concrete examples. Every word contributes; no filler or repetition.
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 filtered-list tool with three optional, fully described parameters, the description covers purpose and domain sufficiently. It doesn't specify the return payload shape, but the result is clearly 'emails' and sibling tools like get_email_content handle deeper retrieval. Could be slightly improved by noting whether returned items are summaries or full emails.
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%, with all three parameters (after, before, limit) already documented with formats and defaults. The description adds no parameter-level detail, so the baseline 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?
States a specific verb ('Get') and resource ('emails from Promotions category'), further clarifying with examples like marketing emails, deals, offers, and newsletters. This clearly differentiates it from sibling category tools such as get_primary_emails and get_social_emails.
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 clearly identifies the Promotions category, allowing an agent to select this tool over the other category-specific getters. It doesn't explicitly name alternatives or when not to use it, but the category naming provides sufficient routing context.
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 present, so the description carries the disclosure burden. It adds useful content-type context by specifying notifications from social networks, but it does not describe return shape, ordering, pagination behavior, or whether the operation has any side effects. 'Get' implies read-only, but the description does not state it.
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 sentence with no filler. It front-loads the category, then adds clarifying examples. Every word contributes to tool selection.
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 low-complexity tool with three optional, well-documented parameters, the description supplies the essential selection context and the schema handles parameter details. It does not explicitly state the exact return format, but the sibling set and the simple nature of the tool make this a moderate rather than critical gap.
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 documents all three parameters with descriptions, defaults, and constraints, and schema coverage is 100%. The description adds no parameter-specific semantics beyond what the schema 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 names a specific verb and resource: 'Get emails from Social category.' The examples 'Facebook, Twitter, LinkedIn' clarify exactly what kind of content is included, and the category label clearly separates it from sibling tools like get_primary_emails and get_forums_emails.
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 gives clear context for when this tool is relevant: when the user wants social-network notification emails. It does not explicitly exclude alternatives or compare itself to search_emails/get_email_content, so it stops short of full routing guidance.
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 behavioral burden. It does disclose the key trait that content is not downloaded, which is important for an agent deciding between listing and downloading. However, it does not mention return shape, side effects, permissions, or whether metadata like filenames and sizes are included.
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. The parenthetical adds a necessary distinction and every word earns its place.
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 two-parameter, list-only tool with no nested objects, the description plus full schema coverage is nearly sufficient. The only gap is that no output schema exists and the description does not specify what attachment metadata is returned, but this is a minor omission for such a simple listing operation.
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 uid and mailbox are already fully documented. The description itself adds no additional parameter-level meaning, but the schema already carries the load, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('all attachments in an email'), and the scope boundary ('without downloading content'). This distinguishes it from download_attachment and save_attachment without needing to inspect their schemas.
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 parenthetical gives a clear context: use this tool when you need to see what attachments exist without retrieving their contents. It implies the alternative of downloading/saving attachments for actual content, though it does not explicitly name those sibling tools or give exclusion criteria.
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 must convey behavioral expectations. 'List' clearly indicates a read-only operation with no destructive side effects, and 'all' sets an expectation of complete label/folder enumeration. It does not mention response format or system labels, but for a simple read-only tool the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words. It states exactly what the tool does 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?
For a zero-parameter tool without an output schema, the description adequately communicates the return concept: all Gmail labels and folders. It falls slightly short of 5 by not mentioning whether system labels are included, the response shape, or how the results relate to sibling tools like get_emails_by_label.
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, and the schema is fully covered as an empty object. Since there is nothing for the description to add about parameter usage, the baseline score of 4 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 clear verb ('List') and specifies the resource ('all Gmail labels and folders'). It fully describes the tool's function and is easily distinguished from sibling email- and label-manipulation tools.
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 such as get_emails_by_label. The description does not mention prerequisites, exclusions, or the natural workflow of first listing labels and then using them to filter emails.
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-imap MCP server](https://glama.ai/mcp/servers/suhail-ak-2/gmail-mcp-imap/badges/card.svg)](https://glama.ai/mcp/servers/suhail-ak-2/gmail-mcp-imap)

Score Badge

Copy to your README.md:

[![gmail-mcp-imap MCP server](https://glama.ai/mcp/servers/suhail-ak-2/gmail-mcp-imap/badges/score.svg)](https://glama.ai/mcp/servers/suhail-ak-2/gmail-mcp-imap)

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/suhail-ak-2/gmail-mcp-imap'

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